advice about Interfaces

[Josema]

Hi,

Im starting develop a portal, and i never used interfaces in the past.

As any portal will be possible register (add), delete, modify a user.
In this portal also will be possible register(add) , delete, modify
bussiness...
I have a class called user, and another called bussiness...

Yesterday i was reading about the using of the interfaces and gives to me an
idea, but i dont know if its a good way to do:

the theme is, make 3 interfaces IRegistrable, IModifiable, IRemovable

and implement this three into the two classes, User, and Bussiness.

Inside each Interface a method following this:

IRegistrable with a method called Register()
IModifiable with a method called Modify()
IRemovable with a method called Remove()

Any advice about it?
--------
Thanks
Regards.
Josema

[Joanna Carter \(TeamB\)]

"Josema" <Je******@ocu.o rg> a écrit dans le message de news:
D9************* *************** **...icrosof t.com...

the theme is, make 3 interfaces IRegistrable, IModifiable, IRemovable

and implement this three into the two classes, User, and Bussiness.

Inside each Interface a method following this:

IRegistrable with a method called Register()
IModifiable with a method called Modify()
IRemovable with a method called Remove()

But this means that you are adding the Register, Modify and Remove behaviour
to the classes, not to the Portal.

If you are thinking of having differing implementations behind the Portal,
then declaring an interface IPortal with your three methods would be
worthwhile, but apart from that, I cannot see too much point.

Joanna

--
Joanna Carter
Consultant Software Engineer

[Josema]

Hi Joanna, i dont understand when you talk about the behaviour of the
classes... I thought that if two objects has the same operations (object
person, and object bussiness can be registered, modified, removed, etc...),
could be good to make some interfaces to implement inside of them...

I dont understand if the person and the bussiness can be for instance,
registered, i dont see the relation with the portal, the portal cant be
registered....

Could you explain it a little?

Sorry for my not understanding im newbie in the using of the interfaces...

Kind Regards.
Josema.

"Joanna Carter (TeamB)" wrote:

"Josema" <Je******@ocu.o rg> a écrit dans le message de news:
D9************* *************** **...icrosof t.com...

the theme is, make 3 interfaces IRegistrable, IModifiable, IRemovable

and implement this three into the two classes, User, and Bussiness.

Inside each Interface a method following this:

IRegistrable with a method called Register()
IModifiable with a method called Modify()
IRemovable with a method called Remove()

But this means that you are adding the Register, Modify and Remove behaviour
to the classes, not to the Portal.

If you are thinking of having differing implementations behind the Portal,
then declaring an interface IPortal with your three methods would be
worthwhile, but apart from that, I cannot see too much point.

Joanna

--
Joanna Carter
Consultant Software Engineer

[Joanna Carter \(TeamB\)]

"Josema" <Je******@ocu.o rg> a écrit dans le message de news:
C1************* *************** **...icrosof t.com...

Hi Joanna, i dont understand when you talk about the behaviour of the
classes... I thought that if two objects has the same operations (object
person, and object bussiness can be registered, modified, removed, etc...), could be good to make some interfaces to implement inside of them...

I dont understand if the person and the bussiness can be for instance,
registered, i dont see the relation with the portal, the portal cant be
registered....
I assume from your posting address that your own language would possibly be
Spanish ?

Does that mean that I couold change your method names to :

Register - Save or Store
Modify - Change or Update
Remove - Delete

....and that these methods are for storing and retrieving objects from some
kind of database or file ?

If that is the case, then you don't want to put these methods in the objects
that you are going to do these things to; they really belong in what you
call a Portal.

Your Portal should be able to examine the objects passed to it without
having to change those objects. In .NET that means you can use reflection to
read/write values from/to the objects.

So, you just need to add the methods to your Portal like this :

interface IPortal
{
void Register(object obj);
void Modify(object obj);
void Remove(object obj);
}

Which would be used like this :

{
IPortal portal = new DatabasePortal( ); // or whatever type you want to use
...
Person person = new Person();
...
portal.Register (person)
...
}

Declaring an interface for the Portal now allows you to change the class
that you use to Register, Modify, and Remove objects.

But there is no advantage in declaring the interfaces as you suggest and
using them on the objects to be passed to the Portal.
Sorry for my not understanding im newbie in the using of the interfaces...

And I think you are trying to use them in the wrong place and for the wrong
reason :-)

Joanna

--
Joanna Carter
Consultant Software Engineer

[Clint (cmueller]

I think what he means is that if you use your method, the classes go
through the task of registering themselves, whereas if you use his
means (IPortal, for example), the Portal itself handles registration of
the users/businesses. In this case, You'd have something like:

PortalClass.Reg ister(User user);
PortalClass.Mod ify(User user);
PortalClass.Rem ove(User user);

PortalClass.Reg ister(Business business)...

You get the point. Here, if businesses and users use the same code for
adding, modifying and removing, it might be helpful to use an interface
or some kind of interface to define common properties needed for
business and users to be added, etc. Thats where I'd see the
IRemovable, IModifiable, IRegistrable existing. At the same time, if a
Business is just a User with some added functionality not related to
removing, adding, or modifying, you can create the business class with
User as a base class, then you'd only have the first three method
declarations above.

Clint

[Clint (cmueller]

I think what she means is that if you use your method, the classes go
through the task of registering themselves, whereas if you use her
means (IPortal, for example), the Portal itself handles registration of

the users/businesses. In this case, You'd have something like:
PortalClass.Reg ister(User user);
PortalClass.Mod ify(User user);
PortalClass.Rem ove(User user);
PortalClass.Reg ister(Business business)...
You get the point. Here, if businesses and users use the same code for
adding, modifying and removing, it might be helpful to use an interface

or some kind of interface to define common properties needed for
business and users to be added, etc. Thats where I'd see the
IRemovable, IModifiable, IRegistrable existing. At the same time, if a
Business is just a User with some added functionality not related to
removing, adding, or modifying, you can create the business class with
User as a base class, then you'd only have the first three method
declarations above.

Clint

[Nick Malik [Microsoft]]

Hello Joanna,

With all due respect, I don't agree with your advice this time. Josema:
Please read this post... there's some advice for you at the end.

"Joanna Carter (TeamB)" <jo*****@nospam forme.com> wrote

you don't want to put these methods in the objects
that you are going to do these things to; they really belong in what you
call a Portal.
There is nothing wrong with placing these operations within the object
themselves. Using AOP and TDD, I would do the same thing. The design is
smaller and more testable if you make an object responsible for its own
registration and storage, as long as the downstream needs of the object are
declared somewhere (either in the constructor or in the "Register" method).

Therefore, the portal would provide an interface
'IRegistrationM anager' with methods 'LookupExisting ', and 'RegisterNew' for
example.

The objects could implement an Interface for IRegisterable as:
interface IRegisterable
{
void PerformRegister (IRegistrationM anager RegMgr);
}

Then when the object is created, it can be created completely seperately
from the functions of the portal. Attaching it to the portal simply means
that the calling code passes the portal object in to the registration method
of the child object. You could create a factory method that returns
different RegistrationMan ager objects from the portal depending on a
variable that varies independently, like registration mechanism, or contract
policy, etc.

Your Portal should be able to examine the objects passed to it without
having to change those objects. In .NET that means you can use reflection
to
read/write values from/to the objects.
Reflection is a useful mechanism for some things. However, it is not a
panacea, and it is more expensive that simple pattern techniques like the
one I explained above that generate the same amount of loose coupling.


So, you just need to add the methods to your Portal like this :

interface IPortal
{
void Register(object obj);
void Modify(object obj);
void Remove(object obj);
}

Which would be used like this :

{
IPortal portal = new DatabasePortal( ); // or whatever type you want to
use
...
Person person = new Person();
...
portal.Register (person)
...
}

I would agree only if the .Register methods were polymorphically declared
within the DatabasePortal class allowing the call portal.Register (person) to
bind to a Register method that specifically binds people... and even then, I
would consider this form of coupling to be a little too tight for me.
But there is no advantage in declaring the interfaces as you suggest and
using them on the objects to be passed to the Portal.
And I think you are trying to use them in the wrong place and for the
wrong
reason :-)

And, the crux of the matter, I am concerned about these statements. You
imply that the proposed use would never be right, and I believe I've shown
that there are cases where this approach, with serious refinement, can yeild
fruit.

I think the OP is starting to stumble upon some intermediate patterns
without understanding the basic patterns first, so the description isn't
altogether collected in his or her mind.

To Josema: NOW is the time for you to read "Design Patterns Explained" by
Shalloway and Trott. Do not toss out interfaces or jump into the crutch of
using reflection until you understand how to perform Commonality -
Variability Analysis. You need to have a good idea of what methods should
be coupled together in your interfaces, and more importantly, what variation
you are attempting to encapsulate. Joanna is not wrong... you may not be
encapsulating the most sensible things. While we disagree about the
application of the methods you are using, I agree with her that you need to
approach Interfaces with an understanding of the underlying reasons for
encapsulating things... something that I'm not sure you've really got your
arms around yet.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

[Joanna Carter \(TeamB\)]

"Nick Malik [Microsoft]" <ni*******@hotm ail.nospam.com> a écrit dans le
message de news: Mq************* *******@comcast .com...

Hello Joanna,
Hi Nick

Josema, please follow this discussion, and you will see that both Nick and I
are trying to understand your ideas and that we both have valid
interpretations . It has to be up to you to help us to help you by deciding
what you really need to know about.
With all due respect, I don't agree with your advice this time.
No problem, there are at least two schools of thought on this issue; we
obviously attended both :-)
There is nothing wrong with placing these operations within the object
themselves. Using AOP and TDD, I would do the same thing. The design is
smaller and more testable if you make an object responsible for its own
registration and storage, as long as the downstream needs of the object are declared somewhere (either in the constructor or in the "Register" method).

My main objection to this approach is that you are tying Portal behaviour to
'business' classes, thereby making it impossible to use these classes
anywhere that doesn't have a Portal concept without carrying the Portal
baggage with it.

I would agree that your suggestion is not 'wrong', just that I prefer to
keep business classes free of anything for which they need not be directly
responsible.

Having said that, it is not totally clear what Josema is actually trying to
achieve, as the original post could be interpreted in more than one way, and
addressed by more than one pattern or solution; I chose the OPF-like
solution :-)

I also think that the language Josema is using indicates persistence like
operations, when you think of Spanish words for those concepts. (??)
Reflection is a useful mechanism for some things. However, it is not a
panacea, and it is more expensive that simple pattern techniques like the
one I explained above that generate the same amount of loose coupling.
I certainly don't like to use reflection more than absolutely necessary,
preferring to implement things like the Visitor pattern for persistence
frameworks, etc.
I would agree only if the .Register methods were polymorphically declared
within the DatabasePortal class allowing the call portal.Register (person) to bind to a Register method that specifically binds people... and even then, I would consider this form of coupling to be a little too tight for me.
IMO, this is where compromise between absolute type safety and generic
mechanisms has to be evaluated for each scenario.
And, the crux of the matter, I am concerned about these statements. You
imply that the proposed use would never be right, and I believe I've shown
that there are cases where this approach, with serious refinement, can yeild fruit.
Certainly, it was never my intention to imply right or wrong, but to
demonstrate one aspect. Thanks for helping open up the discussion with other
POVs.
I think the OP is starting to stumble upon some intermediate patterns
without understanding the basic patterns first, so the description isn't
altogether collected in his or her mind.

Agreed.

Josema, please help us to help you by answering our doubts and clarifying
what it is you really want to do. :-))

Joanna

--
Joanna Carter (TeamB)

Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker

[Christian Gross]

Clint (cm******@onlin e.nospam) wrote:

I think what he means is that if you use your method, the classes go
through the task of registering themselves, whereas if you use his
means (IPortal, for example), the Portal itself handles registration of
the users/businesses. In this case, You'd have something like:

PortalClass.Reg ister(User user);
PortalClass.Mod ify(User user);
PortalClass.Rem ove(User user);

PortalClass.Reg ister(Business business)...

Hmm, here is something similar to what we were debating about in the
speaker room of a conference lately.

Consider the registration defined above and the registration defined
below from another posting.

*****
Therefore, the portal would provide an interface
'IRegistrationM anager' with methods 'LookupExisting ', and 'RegisterNew' for
example.

The objects could implement an Interface for IRegisterable as:
interface IRegisterable
{
void PerformRegister (IRegistrationM anager RegMgr);
}

*****
Our discussion in the past was related to graphics and who paints whom.
This is a very similar argument in who registers whom.

My conclusion is that there is no definite argument to either as both
have their advantages and disadvantages.

For example while it sounds good that objects are responsible for
themselves it does make for more complicated objects as they are
responsible for many many things increasing the size of the object.

On the other hand having a portal class creates a central location for
referencing thus potentially making it hard to update the Portal class.

Any insights on this issue, in either direction?

Christian Gross

[Clint (cmueller]

Not offhand. Really, I've aloways just gone under the presumption of
"What Makes Sense" (tm). In this case, as Nick above mentioned and I
agree with, there's no real right or wrong, it just depends on your
philosophy.

Personally, I think I'd go under the rule of the Portal controlling
everything that happens to it - when something is added and removed. In
the case of modifications, that has to deal with changing the object
directly, so that would be a method within the User or Business classes
themselves.