We are implementing IoC/DI in our application using NInject framework. We are having internal classes having internal methods. To implement IoC/DI, we have to extract interfaces. But if we are having only internal methods in an internal class, we can't extract interface for that class.
So is there a way to implement IoC/DI in such cases (internal class having only internal methods) or should we change our internal methods to public methods. Kindly suggest. Thanks
If your class is already internal then there is absolutely not difference between internal and public methods. public methods of internal classes are only internally visible.
If you stay with injecting concrete classes though you loose all the advantages of DI. So yes you should extract (internal) interfaces and inject the interfaces. This requires that the configuration code has access to the classes by either beeing in the same assembly of the assembly must be declased as friend assembly. Futhermore, you have to configure Ninject to allow none public classes. See NinjectSettings.
The only thing that you really need to make public is the interface (not the concrete implementation).
You can use an abstract factory or (easier) Ninject to map the public interface to the internal concrete; thus your client code just has to request an instance of "a thing" that implements the interface and your factory / container will return the implementation.
You should read up on Dependency Inversion Principle as well as it goes hand-in-hand with this.
You could use InternalsVisibleTo attribute in AssemblyInfo.cs file like this
[assembly: InternalsVisibleTo("Assembly_That_Should_Access_The_Internal_Class")]
Related
I've read what the annotation says but I'm kinda dumb, so couldn't understand propertly
Identifies injectable constructors, methods, and fields. May apply to static as well as instance members. An injectable member may have any access modifier (private, package-private, protected, public). Constructors are injected first, followed by fields, and then methods. Fields and methods in superclasses are injected before those in subclasses. Ordering of injection among fields and among methods in the same class is not specified.
Can you explain me what is #Inject for? If it is possible with a real life analogy with something less abstract
#Inject is a Java annotation for describing the dependencies of a class that is part of Java EE (now called Jakarta EE). It is part of CDI (Contexts and Dependency Injection) which is a standard dependency injection framework included in Java EE 6 and higher.
The most notorious feature of CDI is that it allows you to inject dependencies in client classes. What do I mean by dependencies? It is basically what your class needs to do whatever it needs to do.
Let me give you an example so that it is easier to understand. Imagine that you have a class NotificationService that is supposed to send notifications to people in different formats (in this case, email and sms). For this, you would most probably like to delegate the actual act of sending the notifications to specialized classes capable of handling each format (let's assume EmailSender and SmsSender). What #Inject allows you to do is to define injection points in the NotificationService class. In the example below, #Inject instructs CDI to inject an EmailSender and SmsSender implementation objects via the constructor.
public class NotificationService {
private EmailSender emailSender;
private SmsSender smsSender;
#Inject
public NotificationService(EmailSender emailSender, SmsSender smsSender) {
this.emailSender = emailSender;
this.smsSender = smsSender;
}
}
It is also possible to inject an instance of a class in fields (field injection) and setters (setter injection), not only as depicted above in constructors.
One of the most famous JVM frameworks taking advantage of this dependency injection concept is Spring.
I included a library I'd like to use, but in accessing to one of its classes I get the error message,
"Cannot access '<init>': it is private in [class name]
Is there something I can do to rectify this on my side, or am I just stuck to not use the package?
The error means the constructor is private. Given your comment, I'm assuming you're using a library. If this is the case, you'll have to find a different way to initialize it. Some libraries have factories or builders for classes, so look up any applicable documentation (if it is a library or framework). Others also use the singleton pattern, or other forms of initialization where you, the developer, don't use the constructor directly.
If, however, it is your code, remove private from the constructor(s). If it's internal and you're trying to access it outside the module, remove internal. Remember, the default accessibility is public. Alternatively, you can use the builder pattern, factory pattern, or anything similar yourself if you want to keep the constructor private or internal.
I came across this issue when trying to extend a sealed class in another file. Without seeing the library code it is hard to know if that is also what you are attempting to do.
The sealed classes have the following unique features:
A sealed class can have subclasses, but all of them must be declared in the same file as the sealed class itself.
A sealed class is abstract by itself, it cannot be instantiated directly and can have abstract members.
Sealed classes are not allowed to have non-private constructors (their constructors are private by default).
Classes that extend subclasses of a sealed class (indirect inheritors) can be placed anywhere, not necessarily in the same file.
For more info, have a read at https://www.ericdecanini.com/2019/10/14/kotlins-sealed-class-enums-on-steroids/
Hopefully, this will help others new to Kotlin who are also encountering this issue.
Class constructors are package-private by default. Just add the public keyword before declaring the constructor.
By default constructor is public so need to remove internal keyword.
I have been doing laravel since 4 months. I don't find a clear difference between facades and contracts as they both are set of interfaces. Why would i use facades instead of contracts or contracts instead of facades?
The question whether to use Facade or Contract boils down how you want to resolve your classes and if you want to use interfaces.
Facade
A facade is a class and not an interface (here is an example facade).
A facade is only used to load a class from service container more convenient
The class that is going to be loaded is determent in the getFacadeAccessor() method of the facade class.
Example:
// Without facade - resolving from service container
app('some_service')->methodName();
// Do the same through facade:
someService::methodName();
Contract
A contract is an interface (here is an example)
A contract is used to load a class from service container more convenient AND as an interface
The class that is going to be loaded is determined in the service container, see Binding Interfaces To Implementations
Example: Assuming that class some_service implements interface Illuminate\Contracts\Config\Repository:
// resolving class directly from service container
app('some_service')->methodName();
// resolve through binding from contract
app('Illuminate\Contracts\Config\Repository')->methodName();
I am new to WCF; I have an abstract class that in my WCF service.
I am referencing that WCF service from another application that invokes it: I have it added as a Service Reference in my Visual Studio project.
I managed to serialize the derived classes using the ServiceKnownType attribute, but I cannot manage to make the base class automatically abstract in the service reference code.
Any ideas?
I'm not sure whether this is something that will work in your case, but you can't (with the normal Add Service Reference tool) directly generate abstract classes.
However, all generated classes are partial, so if you know the namespace, all that's required to make it abstract is a new file with;
namespace whatever.the.service.reference.namespace.is {
abstract partial class MyClass { }
}
...and the class will be marked abstract.
I am just starting out with DI & unit testing and have hit a snag which I am sure is a no brainer for those more experienced devs :
I have a class called MessageManager which receives data and saves it to a db. Within the same assembly (project in Visual Studio) I have created a repository interface with all the methods needed to access the db.
The concrete implementation of this interface is in a separate assembly called DataAccess.
So DataAccess needs a project reference to MessageManager to know about the repository interface.
And MessageManager needs a project reference to DataAccess so that the client of MessageManager can inject a concrete implementation of the repository interface.
This is of courser not allowed
I could move the interface into the data access assembly but I believe the repository interface is meant to reside in the same assembly as the client that uses it
So what have I done wrong?
You should separate your interface out of either assembly. Putting the interface along with the consumer or the implementor defeats the purpose of having the interface.
The purpose of the interface is to allow you to inject any object that implements that interface, whether or not it's the same assembly that your DataAccess object belongs to. On the other hand you need to allow MessageManager to consume that interface without the need to consume any concrete implementation.
Put your interface in another project, and problem is solved.
You only have two choices: add an assembly to hold the interface or move the interface into the DataAccess assembly. Even if you're developing an architecture where the DataAccess class may someday be replaced by another implementor (even in another assembly) of the repository interface, there's no reason to exclude it from the DataAccess assembly.
Are you using an Inversion of Control Container? If so, the answer is simple.
Assembly A contains:
MessageManager
IRepository
ContainerA (add MessageManager)
Assembly B contains (and ref's AssemblyA):
Repository implements IRepository
ContainerB extends ContainerA (add Repository)
Assembly C (or B) would start the app/ask the container for MessageManager which would know how to resolve MessageManager and the IRepository.
I think you should move the repository interface over to the DataAccess assembly. Then DataAccess has no need to reference MessageManager anymore.
However, it remains hard to say since I know next to nothing about your architecture...
Frequently you can solve circular reference issues by using setter injection instead of constructor injection.
In pseudo-code:
Foo f = new Foo();
Bar b = new Bar();
f.setBar(b);
b.setFoo(f);
Dependency inversion is in play:
High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
The abstraction that the classes in the DatAccess assembly depend upon needs to be in a separate assembly from the DataAccess classes and the concrete implementation of that abstration (MessageManager).
Yes that is more assemblies. Personally that's not a big deal for me. I don't see a big downside in extra assemblies.
You could leave the structure as you currently have it (without the dependency from MessageManager to DataAccess that causes the problem) and then have MessageManager dynamically load the concrete implementation required at runtime using the System.Reflection.Assembly class.