|
Recently I fell in love with dependency injection and interface based programming. Though, as a beginner, I couldn’t grasp all the advantages of this methodology, I greatly influenced in the discipline we can bring into the project to handle the army of objects.
What I learned that by using interface based programming, components are expose their functionalities only though an interface. At first I designed as like below.
namespace Component1
{
public interface Interface1
{
void Func();
}
public class Class1 : Interface1
{
public void Func() { }
}
public static class IOContainer
{
public static void Register<TInterface, TConcrete>() { }
public static TInterface Resolve<TInterface>() { }
}
}
One drawback I found here that someone can directly create objects of Class1 and use its functions. This will break the essence of interface based programming. So I redesigned it like below.
namespace Component1
{
public interface Interface1
{
void Func();
}
internal class Class1 : Interface1
{
public void Func() { }
}
public static class IOContainer
{
internal static void Register<TInterface, TConcrete>() { }
public static void Register()
{
Register<Interface1, Class1>();
}
public static TInterface Resolve<TInterface>() { }
}
}
This will work fine. So no one can access the implementations from outside the assembly. They have to call Register function and Resolve function to create objects. The component will use only in one discipline. But I fell I lost flexibility. Outsider can't determine which class should resolve at run time. Both methods have their own advantages and disadvantages. Kindly help me to choose a suitable method.
Thanks in advance,
Thomas
|
|
|
|
|
Explicit implementation might help!? Do i make sense here?!
public class Foo : ILazy
{
void ILazy.Sleep()
{
}
}
public interface ILazy
{
void Sleep();
}
var foo = new Foo();
((ILazy)foo).Sleep();
Hope it helps!!
|
|
|
|
|
Keep in mind that all things should be done in moderation.
Not everything needs interfaces and there is very seldom a need to "protect" code from users. In a very large number of cases code that is using other code will always directly create other classes, because it is expedient and no other requirements exist.
However to solve a 'creation' problem one uses a Factory Pattern. This of course supposes that there is a problem in the first place.
|
|
|
|
|
jschell wrote: Not everything needs interfaces and there is very seldom a need to "protect" code from users. In a very large number of cases code that is using other code will always directly create other classes, because it is expedient and no other requirements exist.
Though I agree with you that not all the code are need not protected, still i have to implement interfaces in core areas. This is because the reason to implement interfaces is to develop extendable, maintainable and testable code.
jschell wrote: However to solve a 'creation' problem one uses a Factory Pattern. This of course supposes that there is a problem in the first place.
I didnt get this. Can you please explain it?
|
|
|
|
|
SSEAR wrote: develop extendable, maintainable and testable code.
Those are feel good subjective terms, especially the first two.
One can create code using interfaces that meet none of those.
SSEAR wrote: Can you please explain it?
Google the following term with the quotes
"Factory Pattern"
|
|
|
|
|
jschell wrote: Those are feel good subjective terms, especially the first two.
One can create code using interfaces that meet none of those.
So you think dependency injection does not solve these issues?
|
|
|
|
|
SSEAR wrote: So you think dependency injection does not solve these issues?
First one can write code using dependency injection which fails all of the issues you listed.
Second the terms you posted are almost always used subjectively, in that there are no objective measurements in place to verify success or failure.
|
|
|
|
|
I don't understand what the problem with allowing users to create instances of their classes directly is. (Users in this case meaning users of the framework; that could well be you as well.)
The important thing about interface based programming is that the core code, including the dependency injection mechanism if you want such a thing, deal with the interfaces. Methods in your core logic should take and return interfaces, not concrete subclasses; this makes them easily mockable and re-usable. But there's no reason to try to prevent someone from declaring a Class1 which implements one of the public interfaces and creating it directly; sometimes that's actually what you need in a specific case.
You should advise your users (again, that might be yourself or other team members) that generally it's better to use the interfaces and get a resolved instance from the container, but that should be 'enforced' with coder discipline, not a technical solution.
A final point is that it is essentially impossible to provide an extensible container, which allows registration of arbitrary classes, and also to prevent people instantiating those classes directly, because the container needs to use a constructor to resolve a request. You could require that a factory class is passed instead, but that's abstraction for the sake of it, and if it's a user specified factory, they can just call the factory method directly anyway.
|
|
|
|
|
BobJanova wrote: I don't understand what the problem with allowing users to create instances of their classes directly is. (Users in this case meaning users of the framework; that could well be you as well.)
Last month I developed a Microsoft Exchange Server wrapper component. Interfaces will expose methods and there is a wrapper class to resolve the implementation using an IOC container. That was for an old version of exchange server. I uploaded the code to the code database. Few days later the Exchange Server upgraded and there was a requirement to implement the new API. So I created new classes for the newer version and also changed the wrapper class to register new classes with IOC container. But some developers from other projects directly access the classes of old version so that they lost the new changes. As you said I can advise them to follow this discipline. But I feel it is a burden for me. I have to spend my precious time to watch them. Hope you understand my situation.
|
|
|
|
|
SSEAR wrote: Hope you understand my situation.
I certainly don't.
Some problem involving X occured some time ago. What X is is irrelevant. How long ago is irrelevant. From that some less than ideal situation occurred.
The causes for that are one or more of the following.
1. You failed to implement all of the known functionality.
2. You failed to design for known future uses.
3. Other uses failed to use your design (and thus implementation) correctly.
4. New features were needed.
Obviously 1/2 are your fault.
3 is not something that you fix with code, but instead fix it with process (humans interacting with other humans in a defined way with the goal of reducing future problems.)
4 is a benefit of software development since it insures that there will always be jobs.
modified 3-May-12 14:20pm.
|
|
|
|
|
Programmers are writing codes for a very long time now. When our computers will have the ability to write the code of the solutions by its own.
I hope we can reach the point where the user will set in the front of the computer, and tell him that I need a software to do, 1,2,3,4. And the computer generate the application for him directly without going though the whole SDLC!.
I think this could be soon specially in the business solutions, where the user should fill a list of business rules and the computer do the rest for him. This is something close to the application builders. But there is nothing in the market yet encapsulate what I am thinking of 
So when we will see something like this?
--
Hasan Al-Halabi
Chief Operation Officer "COO"
What's Next! for Business Solutions
Queen Rania Str. Building 313, 4th Floor, Office 409
P.O.Box: 143882
Amman 11814, Jordan
Mob: 962 7 97958819
Tel: 962 6 5334478
hasanhalabi@whats-nxt.com
http://www.whats-nxt.com
|
|
|
|
|
Hasan Al-Halabi wrote: So when we will see something like this?
It is called "Microsoft Access".
Bastard Programmer from Hell 
|
|
|
|
|
NO, I am not talking about this level, I am talking about another advance level. In MS Access, the user have to design the database, and then it will create the forms. But it does not allow workflows as example.
I am talking about a software asking the user about the business rules he want by wizard, the user should not be aware about databases to create his app. Just the business rules as business rules as processes.
--
Hasan Al-Halabi
Chief Operation Officer "COO"
What's Next! for Business Solutions
Queen Rania Str. Building 313, 4th Floor, Office 409
P.O.Box: 143882
Amman 11814, Jordan
Mob: 962 7 97958819
Tel: 962 6 5334478
hasanhalabi@whats-nxt.com
http://www.whats-nxt.com
|
|
|
|
|
Three out of five companies that I worked for had an application that could generate LOB-apps from "models". The most advanced of them used plain English as the language to create these models (based on NIAM).
No, doesn't mean that we'll stop programming, on the contrary; it creates new needs.
Bastard Programmer from Hell
|
|
|
|
|
Eddy Vluggen wrote: The most advanced of them used plain English as the language to create these models
Does these applications generate a code to compile, or directly transform the rules into application?
--
Hasan Al-Halabi
Chief Operation Officer "COO"
What's Next! for Business Solutions
Queen Rania Str. Building 313, 4th Floor, Office 409
P.O.Box: 143882
Amman 11814, Jordan
Mob: 962 7 97958819
Tel: 962 6 5334478
hasanhalabi@whats-nxt.com
http://www.whats-nxt.com
|
|
|
|
|
Hasan Al-Halabi wrote: Does these applications generate a code to compile, or directly transform the rules into application?
"Interpret" the rules. The company before that had an app that generated a database, and used reflection to generate a UI on the fly. Whether you generate code that get's compiled on the fly, compiled in advance, or is interpreted- is merely a technicality. The hard part is translating the input into something useable.
Are you looking for something specific, or just curious to what's out there?
Bastard Programmer from Hell
|
|
|
|
|
Eddy Vluggen wrote: Are you looking for something specific, or just curious to what's out there?
Neither any of these, actually I am curious whether such a thing is worth to initiate an open source community for it or not.
--
Hasan Al-Halabi
Chief Operation Officer "COO"
What's Next! for Business Solutions
Queen Rania Str. Building 313, 4th Floor, Office 409
P.O.Box: 143882
Amman 11814, Jordan
Mob: 962 7 97958819
Tel: 962 6 5334478
hasanhalabi@whats-nxt.com
http://www.whats-nxt.com
|
|
|
|
|
That's great! 
hermaine...",)
|
|
|
|
|
huh?.. really?.. how come?
hermaine...",)
|
|
|
|
|
Hermaine wrote: huh?.. really?.. how come?
Our productivity increases continually. I didn't get less work when Delphi 3 or VB6 were introduced. On the contrary, platforms keep expanding.
The tools we use become better, and, if all is well, we too, extend our knowledge. In the meantime there's ever more people interacting with computers, in ways that they didn't before, giving them new idea's for us to work on.
We're programmers. Even if we develop something to automate our daily job, we'd just have more time to program other stuff. It's what we do 
Bastard Programmer from Hell
|
|
|
|
|
I worked on an application like this over 15 years ago. The problem with them is twofold. First, they only really effectively work in a very narrow domain, ones with a well defined business problem. A bigger issue, though, is that users often don't know what they want out of an application. They may know what they want out of their little bit, totally ignoring the other users of a system.
|
|
|
|
|
Pete O'Hanlon wrote: I worked on an application like this over 15 years ago
I know that the idea is not new, but after all of these years, we should think in building one that solve the problems you are talking about. If the user himself does not know what he want, there are a lot of consultant working on let people know what they want. About the narrow domain, I am sure that the technology now is a lot better than 15 years ago. I think the open source community should take a lead in such a thing.
--
Hasan Al-Halabi
Chief Operation Officer "COO"
What's Next! for Business Solutions
Queen Rania Str. Building 313, 4th Floor, Office 409
P.O.Box: 143882
Amman 11814, Jordan
Mob: 962 7 97958819
Tel: 962 6 5334478
hasanhalabi@whats-nxt.com
http://www.whats-nxt.com
|
|
|
|
|
Fly at it. Why don't you start it off? I will watch with interest, precisely because I know how complicated it is.
|
|
|
|
|
We are trying to realize similar idea in one of our products.
We already have developed GUI prototyping tool (called GUI Machine), that allows to creat interactive high-fidelity prototypes and thus to describe GUI and interface logic without coding. Now we working for UML-modeling tool. UML allows to describe the business logic and all aspects of the system. Soon we will integrate these tools (prototyping and UML-modeling) into 1 solution. With it you can creat prototype and UML-model for a complete description of the system (without coding) and our solution will generate code or even a complete application.
I hope, we will be able to realize it.
|
|
|
|
|
seems like something far far away tho.. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
