Design and Architecture

Re: Dilemma on exposing methods in interface based programming

22-Apr-12 23:11

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

VallarasuS24-Apr-12 5:12

VallarasuS

24-Apr-12 5:12

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!!

Regards Vallarasu S | FSharpMe.blogspot.com

Re: Dilemma on exposing methods in interface based programming

jschell28-Apr-12 7:52

Re: Dilemma on exposing methods in interface based programming

28-Apr-12 7:52

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.

SSEAR29-Apr-12 20:53

Re: Dilemma on exposing methods in interface based programming

29-Apr-12 20:53

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?

jschell30-Apr-12 8:00

Re: Dilemma on exposing methods in interface based programming

30-Apr-12 8:00

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"

SSEAR1-May-12 20:28

Re: Dilemma on exposing methods in interface based programming

1-May-12 20:28

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?

jschell2-May-12 10:57

Re: Dilemma on exposing methods in interface based programming

2-May-12 10:57

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.

BobJanova30-Apr-12 4:06

BobJanova

30-Apr-12 4:06

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.

Re: Dilemma on exposing methods in interface based programming

SSEAR1-May-12 21:01

Re: Dilemma on exposing methods in interface based programming

1-May-12 21:01

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.

jschell2-May-12 11:07

When we will stop programming?!

2-May-12 11:07

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.

Hasan Al-Halabi8-Apr-12 0:25

8-Apr-12 0:25

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 Frown | :(

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

Eddy Vluggen8-Apr-12 0:30

8-Apr-12 0:30

Hasan Al-Halabi wrote:
So when we will see something like this?

It is called "Microsoft Access".

Bastard Programmer from Hell Suspicious | :suss:

Hasan Al-Halabi8-Apr-12 1:14

8-Apr-12 1:14

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.

Eddy Vluggen8-Apr-12 1:39

8-Apr-12 1:39

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 Suspicious | :suss:

Hasan Al-Halabi8-Apr-12 3:25

8-Apr-12 3:25

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?

Eddy Vluggen8-Apr-12 8:37

8-Apr-12 8:37

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 Suspicious | :suss:

Hasan Al-Halabi9-Apr-12 11:52

9-Apr-12 11:52

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.

Hermaine18-Apr-12 21:24

Hermaine

18-Apr-12 21:24

That's great! Wink | ;)

hermaine...",)

Hermaine18-Apr-12 21:23

Hermaine

18-Apr-12 21:23

huh?.. really?.. how come?

hermaine...",)

Eddy Vluggen19-Apr-12 6:50

19-Apr-12 6:50

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 Smile | :)

Bastard Programmer from Hell Suspicious | :suss:

Pete O'Hanlon8-Apr-12 2:25

Pete O'Hanlon

8-Apr-12 2:25

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.

*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington

"Mind bleach! Send me mind bleach!" - Nagy Vilmos

My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility

Hasan Al-Halabi8-Apr-12 3:23

8-Apr-12 3:23

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.