Sure. The question comes down to encapsulating construction, and is more
targeted at strongly typed languages like Java. However, there are reasons
to take these ideas (and the underlying reason for them) into account in our
CF code. First, consider this Java code:
user = new User();
Obviously, this creates a new instance of a User. The use of the new keyword
guarantees this. The constructor is run on the User class, and I get an
instance back.
Now imagine I have done this in 1000 places in my code. And now I figure out
that this needs to change. For example, maybe I have two kinds of users,
RegisteredUser and UnregisteredUser. hmmm....now I'm in trouble. Becuase
using the new keyword has shackled me. There is no way for me to get back an
instance of anything other than the User class everywhere in my code. I'm
going to have to go through and manually change (or run refactoring tools
on, or run search and replace no) my code, maybe to try and change it to
user = new RegisteredUser() or user = new UnregisteredUser().
That's still a pretty bad solution though. What about
user = UserFactory.createUser('registered') or user = UserFactory.createUser
('unregistered')
OK I think you can see that what we're doing is morphing from one class to
multiple classes via a factory. The real point being, when I create a class
directly using the new keyword, I have lost all control over what happens.
There is no way for me to get back anything other than the class name next
to the new keyword. Instead, from the beginning, I could have done this with
absolutely no extra work:
user = User.getInstance()
Ah! Now my OBJECT controls the new keyword. IT can decide what to do. My
calling code is not shackled to just User any more. And while it is not a
silver bullet (i.e. if, later, I need to pass a value to decide what kind of
user to return), it gets us most of the way to where we want to be (a
factory). And it costs nothing but marking the constructor private and
creating a static method to return an instance. It takes 5 seconds.
Further, another huge but unappreciated benefit of encapsulating
construction has to do with coupling. When an object both creates and uses
an object, it is more tightly coupled to that object. This is because it not
only has to know the TYPE of the object (so that it can create it), but it
is coupled to the API of the object (so that it can use it). This isn't good
and there is an easy way around it: separate object use from object
creation. When you do this, you reduce coupling. This is because the factory
object that creates the class is coupled to the TYPE (it has to know which
one to create), but is NOT coupled to the API of the object because it
doesn't use it. Which means that I can change the API of the object(s) being
created and have no impact on the factory at all. Conversely, the object
USING the new object is coupled to the API, but is not coupled to the TYPE.
As long as the API is consistent, a factory can pass any object it wants to
into the "using" object. The point is, I've very carefully defined what will
have to be modified if a change needed. If I need to add a new type, I
modify or extend ONLY the factory. If I need to change the API, I modify
ONLY the "using" object(s). And you can see that if I don't separate object
use from creation, I have to change the object every time there is either a
TYPE added or removed, OR an API change. The worst of both worlds.
Anyway this was a long email and covered a couple of ideas so hopefully they
all make sense. The basic idea is to separate object use from creation by
using factories. CF doesn't have the New keyword but it does have
CreateObject. And while we have more control over CreateObject (it could
return anything), I still prefer to wrap that up into a factory, even if the
factory does nothing but call create object and return an instance, such as
user = getFactory().getInstance('user').
Brian
On 10/5/07, Sam Larbi <[EMAIL PROTECTED]> wrote:
>
>
>
> On 10/4/07, Brian Kotek <[EMAIL PROTECTED]> wrote:
> >
> > ]when you make the constructor private (which, in Java, is almost always
> > a smart design decision because it allows you to encapsulate the creation of
> > the object and maintain control over what happens during instantiation).
>
>
>
>
> Would you mind explaining that some more? In particular, what about
> making a constructor private prevents or impedes those goals?
>
> Have I taken it out of context? (I did not re-read the entire thread, so
> please forgive if that is the case)
>
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
