I just start learning what is Dependency Injection and InversionOfControll is. But I cant get one thing. The interface injection is onle when I define some interface where describe method what need to be realized. And that method gets instance of some class as parameter, and then In class what implements interface just describe body of this method ?
An interface is only a contract that defines what public members a class should implement. It does not control the actual implementation - you need a concrete class to do that.
// This is only a contract that defines what members
// all concrete types must implement.
public interface ISomeType
{
void DoSomething();
}
// This class implements the interface. Therefore, it must
// have all of the methods the contract specifies. In some
// languages, this can be done implicitly just by adding the
// member, but it usually must be public.
public class SomeType : ISomeType
{
public void DoSomething()
{
Console.WriteLine("Hello World");
}
}
When you make a class implement an interface it implicitly means that instances of the class can be cast to the interface type.
ISomeType x = new SomeType();
Dependency Injection takes advantage of this behavior. You typically define both the interface type and the concrete implementation together in a mapping.
container.For<ISomeType>().Use<SomeType>();
Then when a service is declared to take ISomeType as a constructor argument, the map is used to determine which concrete type to create an instance of.
public class SomeService : ISomeService
{
private readonly ISomeType someType;
public SomeService(ISomeType someType)
{
if (someType == null) throw new ArgumentNullException("someType");
this.someType = someType;
}
}
The recommended way is to allow the DI container to do this implicitly when your entire object graph is composed (in the Composition Root), but it is possible also to do it explicitly (and it makes a better example):
ISomeService = container.GetInstance<ISomeService>();
Assuming that the container was configured to map ISomeService to SomeService (like I showed before with ISomeType), this one line of code will create an instance of SomeService and automatically inject an instance of SomeType into its constructor.
It is difficult to see the point in a simple example, though. Dependency Injection is meant for complex applications with many types. It simplifies things when the application is complex, but when the application is simple it has a tendency to make things more complex.
Related
In my flutter project, I have the following abstract class.
abstract class Storage {
static method1{}
static method2{}
...
}
Then I define other classes that extend to Storage but each child class implements some of the methods defined (with empty body) in the Storage class.
class StorageA{
static method1{ print("1") }
}
class StorageB{
static method2{ print("2") }
}
My goal is to be able to call any of these static method by using the Storage namespace, however, I want to invoke the overridden methods in the child classes. For example, when I call Storage.method1 it should print 1. This is a very simplified example but I normally have bunch of methods and I want to group these methods into different classes that extend to Storage. But at the same time i want to access all the overridden methods with Storage namespace. Currently when I do Storage.method1 compiler picks up the function defined in Storage because it has an empty body. If i remove the body and turn it into function declaration, then I can't define the function as static. So, how can I reach my goal here?
Is combining everything into a single Storage class and defining the methods as static the only solution here?
I'm using the Mixin pattern as illustrated below. Why does Typescript require you to provide stand-in properties for private properties of the mixin class in the target class (A)? It perfectly makes sense for the public properties, but for private properties it unnecessarily crufts up the target class with details of the internal implementation of the mixin class by requiring them to be stubbed-out in the target class. Seems like the Typescript transpiler should be able to not require this.
class Mixin {
private foo:string;
}
class A implements Mixin {
// stand-in properties, typescript requires even
// private properties to be stubbed-out
foo:string;
}
Private members contribute to the structure of a type in TypeScript, so if you don't implement them you are not compatible with the type. This actually makes it impossible to match a type structurally in TypeScript if it has a private member, because you are either:
a. Failing to provide the type
or
b. Providing a separate implementation of the private member
So you can only extend a type with a private member, not implement it.
With this in mind, you are better off not using private members with mixins. Provide the ghost-members in the implementation class and keep your fingers crossed that if mixins gain some traction the ghosting will become unnecessary (see TypeScript mixins part one).
In C++ I can make interface and class declarations. However, in contrast to C# the interface here is very likely to be a class so why is it there ?
interface Interface {
};
And
class Class {
};
As has been mentioned in comments, standard C++ does not support an "interface" construct directly. This is an extension from some vendors.
Other languages do (e.g Java).
The equivalent in standard C++ is an abstract base class, which does not have data members.
class SomeInterface
{
public:
virtual ~SomeInterface() = 0;
virtual void SomeAction(int flag) = 0;
};
Inheriting from such a class forces the derived class to override/implement all virtual functions, otherwise they cannot be instantiated.
Generally speaking, an abstract base class without data members can often get away without having non-trivial constructors (since the class has no members to initialise).
Unlike other languages that do support an interface construct, the abstract base class permits;
Having data members in the base class. (In which case constructors, destructors, assignment operators, etc may need to be defined to manage those members)
Having some members pure virtual and some not
Providing implementations of pure virtual methods (which must be explicitly overridden by derived class, but the base class version can be called)
I have a custom deferred binder (rebind implementation) that instantiates objects. I would like to have some dependencies (#Inject annotated setter methods) within the instance returned by GWT.create() fulfilled by GIN. Is this possible?
So, given code such as:
Foo foo = GWT.create(Foo.class);
if foo's final implementation has:
#Inject
public void setBar(Bar bar) {
...
}
how do I get bar injected into the returned foo instance automatically by GIN?
Your Ginjector can have methods added to it for the purpose of injecting objects created in some other way. These must take one argument, and should specify the most specific type possible. For example, if MyViewImpl extends BaseView, and both types have dependencies to inject, but you declare
void injectBaseView(BaseView view);
in your ginjector, only the fields/setters declared on BaseView will be dealt with.
EDIT: Also, if no binding is declared, GWT.create will be used to create an instance, so you can have your cake and eat it to. One exception to that as far as I can recall, is when you want to GWT.create one type, but return another (see RPC interfaces for an example).
I would like to pass an interface to a method signature which takes Object as its parameter, so I wonder about this question
public Stream GetViewStream(string viewName, object model, ControllerContext context)
instead of object I shall like to pass an interface Imodel, without modifying the signature. Is there a base class for interfaces?
Also in the new mvc2 is there a way to avoid controllercontext altogether?
I'd only answer the first question - Why there's no common base interface for all interfaces ?
First of all, there's no common pre-defined base interface for all interfaces, unlike the System.Object case. Explaining this can get very interesting.
Let us assume, you could have a common interface for all interfaces in the system. That means, all interfaces will need to force their implementations to provide implementation-details for that common base interface. In general, interface are used to give specific special behaviors to their concrete implementation classes. Obviously you only want to define an interface when you only know what to do and don't know HOW to do that. So, if you let there be a common base interface for all interface and force the implementations to expect them to provide details of how to do it - why would you want to do it ? What common task each class should do that varies from one another ?
Lets look at the other side of the coin, why we have System.object as base class of any .Net type - It is simple it gives you some methods that have COMMON implementation for any .Net type and for those methods that it might vary from type-to-type they have made it virtual ex: .ToString()
There's possibly no assumption of any
system-wide interface method which is
virtual/abstract to all its
implementations.
One common practice of using Interface is say, defining a particular behavior to any type. Like I'd have an interface IFlyable which will give Fly() to all types that implement IFlyable. This way I can play with any Flyable object regardless of its inheritance hierarchy coming into picture. I can write a method like this..
public void FlyTheObject(IFlyable flyingObject)
{
flyginObject.Fly();
}
It does not demand anything from the object but the implementation of the Fly() method.
EDIT
Additionally, All interfaces will resolve to Object because interfaces cannot be instantiated. The object is always of a concrete class that can be instantiated. This class may or may not implement your interface but as we know, any .Net type is ultimately based to System.Object, so you will be able to take the instance into an object type regardless of the fact if it implements a particular interface or not.
No, there is no base class for interfaces. Nor there is base interface for interfaces.
As for your second question (and partly first one) - what are actually you trying to do?
There is no base class for interfaces, but you can pass any interface variable e.g:
private IEnumerable<int> myInterfaceVariable = new List<int>();
to your method because by definition anything that is stored in that variable must be an instance of a class that inherits from the interface - therefore it must be an object.
The following compiles fine:
public class InterfaceAsObject
{
private IEnumerable<int> myInterfaceVariable = new List<int>();
private void CallDoSomething()
{
DoSomething(myInterfaceVariable);
}
private void DoSomething(object input)
{
}
}
Re 1, there is no base interface, but if I understand you correctly, you can achieve what I think you want by just passing your object that implements IModel via the model parameter and cast (and check!) the parameter to IModel. I use 'as' and check for null.
If you don't need total flexibility, a better way of doing this is to define the interface that the model parameter must support. If the specific objects support derived interfaces (e.g. IDerivedModel : IModel) this will work too.
Look up a text-book on polymorphism.