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

[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*******@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

[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******@onlin e.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.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

[Joanna Carter \(TeamB\)]

"Josema" <Je******@ocu.o rg> a écrit dans le message de news:
38************* *************** **...icrosof t.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 WhateverTheRegi strationIsFor x;

public Registration(Pr ofile profile, WhateverTheRegi strationIsFor x)
{
...
}

public void Modify()
{
if (profile.GetTyp e().IsAssignabl eFrom(typeof(Us er)))
{
// edit User
}
else
{
// edit Business
}
}
}

class Register
{
public void Add(Registratio n registration)
{
...
}

public void Delete(Registra tion 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