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.org> a écrit dans le message de news:
D9**********************************@microsoft.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.org> a écrit dans le message de news:
D9**********************************@microsoft.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.org> a écrit dans le message de news:
C1**********************************@microsoft.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.Register(User user);
PortalClass.Modify(User user);
PortalClass.Remove(User user);

PortalClass.Register(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.Register(User user);
PortalClass.Modify(User user);
PortalClass.Remove(User user);
PortalClass.Register(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*****@nospamforme.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
'IRegistrationManager' with methods 'LookupExisting', and 'RegisterNew' for
example.

The objects could implement an Interface for IRegisterable as:
interface IRegisterable
{
void PerformRegister(IRegistrationManager 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 RegistrationManager 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*******@hotmail.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******@online.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.Register(User user);
PortalClass.Modify(User user);
PortalClass.Remove(User user);

PortalClass.Register(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
'IRegistrationManager' with methods 'LookupExisting', and 'RegisterNew' for
example.

The objects could implement an Interface for IRegisterable as:
interface IRegisterable
{
void PerformRegister(IRegistrationManager 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.

[Josema]

Hi Joanna, Nick, Clint and Christian...

First of all sorry for my later response....

I read all the messages, but i see that i have a low level of this :-), but
i will try to explain myself, what im trying to do.

As i say, i have two clases that are in two diferent .cs files, and are like
this:

- Class user: I would like to use this class user to register a user into
the portal, this user will fill some textboxes, and will click into a button.
Then i will add to the database this preregistration, and send an email to
the user to complete the registration....

- Class bussiness: This class will be very similar, a person will fill some
textboxes (about a bussiness), and will click into a button, then i will add
to the database this preregistration too, and send an email to the bussiness
to complete the registration.

As you see the two cases are similar, but the properties of fields of each
classes are very differents. User has username, password, email, nationality,
receiveinfo, etc...
Bussiness has Name of the bussiness, contactperson, password, address,
email, city, receiveinfo.

Both classes has to have three methods:

Add()
{
//add code
}
Modify()
{
add code
}
Delete()
{
add code
}

As you see could be good create an interface with this three methods, and
then implement this interfaces in both classes. Then add code for each method
in each class.

My real problem its that i dont know if this way to do this its a good way.
And if its a good way, i dont know what its the best name for this interface.

Joanna, when you say call to the interface IPortal, i dont understood, cause
for me the portal cant be registered, modified, or deleted. Maybe could be
good call to it IProfile. all the actions (add, delete, modify) are related
with the profile of a user or a bussiness, or anything than can be delete,
added, or modify...

Thanks a lot to all.
Kind Regards.
Josema.

"Joanna Carter (TeamB)" wrote:

"Nick Malik [Microsoft]" <ni*******@hotmail.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

[Josema]

Hi Joanna, Nick, Clint and Christian...

First of all sorry for my later response....

I read all the messages, but i see that i have a low level of this :-), but
i will try to explain myself, what im trying to do.

As i say, i have two clases that are in two diferent .cs files, and are like
this:

- Class user: I would like to use this class user to register a user into
the portal, this user will fill some textboxes, and will click into a button.
Then i will add to the database this preregistration, and send an email to
the user to complete the registration....

- Class bussiness: This class will be very similar, a person will fill some
textboxes (about a bussiness), and will click into a button, then i will add
to the database this preregistration too, and send an email to the bussiness
to complete the registration.

As you see the two cases are similar, but the properties of fields of each
classes are very differents. User has username, password, email, nationality,
receiveinfo, etc...
Bussiness has Name of the bussiness, contactperson, password, address,
email, city, receiveinfo.

Both classes has to have three methods:

Add()
{
//add code
}
Modify()
{
add code
}
Delete()
{
add code
}

As you see could be good create an interface with this three methods, and
then implement this interfaces in both classes. Then add code for each method
in each class.

My real problem its that i dont know if this way to do this its a good way.
And if its a good way, i dont know what its the best name for this interface.

Joanna, when you say call to the interface IPortal, i dont understood, cause
for me the portal cant be registered, modified, or deleted. Maybe could be
good call to it IProfile. all the actions (add, delete, modify) are related
with the profile of a user or a bussiness, or anything than can be delete,
added, or modify...

Thanks a lot to all.
Kind Regards.
Josema.


"Clint (cm******@online.nospam)" wrote:

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.Register(User user);
PortalClass.Modify(User user);
PortalClass.Remove(User user);
PortalClass.Register(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

[Joanna Carter \(TeamB\)]

"Josema" <Je******@ocu.org> a écrit dans le message de news:
38**********************************@microsoft.com...

- Class user: I would like to use this class user to register a user into
the portal, this user will fill some textboxes, and will click into a button. Then i will add to the database this preregistration, and send an email to
the user to complete the registration....
I have taken time to think about what you are really trying to do, so see
what you think of the following :-)

Naming a class 'User' indicates that you want this class to describe a User,
not things like registration, databases, etc.

From what you have said, you have at least two other classes involved in
this scenario, and they are the Register in which the Registrations are
kept, and the Registrations themselves.

Otherwise, how are you planning on coping with the same User being
registered more than once ?

The same applies to the Business class; this represents a Business and both
the User and the Business classes should be a separated from a Register
class, but linked to the Register by the use of a Registration class.
As you see the two cases are similar, but the properties of fields of each
classes are very differents. User has username, password, email, nationality, receiveinfo, etc...
Bussiness has Name of the bussiness, contactperson, password, address,
email, city, receiveinfo.

Both classes has to have three methods:

Add()
{
//add code
}
Modify()
{
add code
}
Delete()
{
add code
}
These methods do not belong in either of the USer or Business classes, they
are functionalities of the Register and Registration classes :

abstract class Profile
{
}

class User : Profile
{
}

class Business : Profile
{
}

class Registration
{
private Profile profile;

private WhateverTheRegistrationIsFor x;

public Registration(Profile profile, WhateverTheRegistrationIsFor x)
{
...
}

public void Modify()
{
if (profile.GetType().IsAssignableFrom(typeof(User)))
{
// edit User
}
else
{
// edit Business
}
}
}

class Register
{
public void Add(Registration registration)
{
...
}

public void Delete(Registration registration)
{
...
}
}
Joanna, when you say call to the interface IPortal, i dont understood, cause for me the portal cant be registered, modified, or deleted. Maybe could be
good call to it IProfile. all the actions (add, delete, modify) are

related

Methods like Add and Delete do not apply to the thing that is being added or
deleted, they apply to the container to/from which the things are being
added/deleted.

Does any of the above make anyh more sense ?

Joanna

--
Joanna Carter (TeamB)

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