Re: Dilemma on exposing methods in interface based programming - Design and Architecture Discussion Boards

First Prev Next

Re: Dilemma on exposing methods in interface based programming

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

jschell

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.

Re: Dilemma on exposing methods in interface based programming

SSEAR29-Apr-12 20:53

SSEAR

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?

Re: Dilemma on exposing methods in interface based programming

jschell30-Apr-12 8:00

jschell

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"

Re: Dilemma on exposing methods in interface based programming

SSEAR1-May-12 20:28

SSEAR

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?

Re: Dilemma on exposing methods in interface based programming

jschell2-May-12 10:57

jschell

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.

Re: Dilemma on exposing methods in interface based programming

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

SSEAR

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.

Re: Dilemma on exposing methods in interface based programming

jschell2-May-12 11:07

jschell

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.

When we will stop programming?!

Hasan Al-Halabi8-Apr-12 0:25

Hasan Al-Halabi

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