On Sun, Apr 4, 2010 at 6:36 PM, Larry Garfield <larry@xxxxxxxxxxxxxxxx>wrote:
> Hi folks. Somewhat philosophical question here.
>
> I have heard, although not confirmed, that the trend in the Java world in
> the
> past several years has been away from constructors. That is, rather than
> this:
>
> class Foo {
> public void Foo(Object a, Object b, Object c) {}
> }
>
> Foo f = new Foo(a, b, c);
>
> The preference is now for this:
>
> class Foo {
> public void setA(Object a) {}
> public void setB(Object b) {}
> public void setC(Object c) {}
> }
>
> Foo f = new Foo(a, b, c);
> f.setA(a);
> f.setB(b);
> f.setC(c);
>
> I suppose there is some logic there when working with factories, which you
> should be doing in general. However, I don't know if that makes the same
> degree of sense in PHP, even though the OO models are quite similar.
>
> So, I'll throw the question out. Who uses example 1 above vs. example 2
> when
> writing dependency-injection-based OOP? Why? What trade-offs have you
> encountered, and was it worth it?
>
> --Larry Garfield
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
That's an interesting question to ponder, Larry.
In some ways, working with a constructor requires a greater amount of
knowledge concerning the object.
Perhaps I'm the service that's responsible for injecting the appropriate DB
object. I don't care about the Auth object, nor do I care about Logging
object to be injected. I only care about providing the DB object. If the
Foo object implements an interface (e.g., setDBObject(DBObject dbo)), I can
be handed any object with the interface, and perform the injection, no
questions asked. The same technique can be carried out for the Auth object
and logging object. Carried out far enough, and you can work up a nice IoC
structure that doesn't even blink when you change the object by adding
another instance variable that is to be injected. I wouldn't have to touch
any *existing* code to accommodate these changes.
However, when you consider the constructor example, you have to interlace
your code in such a way that there's a point where you know:
- All of the objects that Foo expects in the constructor, and what the
order is.
- Which instance of each object to send for this particular instance of
Foo.
In this situation (where I'm using the constructor), I much more likely to
have to rework existing code to accommodate the changes in the object.
I do believe you are correct, there does seem to be a trend that way in Java
and C# (although some of C#'s syntactic sugar does offer a couple other
options.)
That said, I'll admit I've been leaning in the other way for the past year
since being exposed to some functional programming paradigms. I've actually
been using more constructors in C# and Java and PHP to create immutable
objects (private instance vars and private setters, but public getters.)
Although it does require more knowledge of the underlying object structure
in surrounding code, it also affords me immutability, which has it's own
merits.
Just my OPINIONS ;)
Adam
--
Nephtali: PHP web framework that functions beautifully
http://nephtaliproject.com
