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) said:
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.
--