Constructor usage

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

Re: Constructor usage

Larry Garfield 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?

Hi Larry,

In the Java world a huge reason is because Classes have to be able to be
instantiated with no arguments in order to reverse engineered w/ JAXB so
that the classes can be used for web services (and wsdl's created etc).
Thus most of them have no arguments.

Personally I also find it good practise to instantiate with no arguments
and then set the state of the instance by calling setters.

A nice way around it is to create static methods which instantiate the
class w/ a protected or private constructor.

class Foo
{
private $a;

private function __construct() {}

public function setA( $a )
{
$this->a = $a;
}

public static function instantiateWithASet( $a )
{
$temp = new self;
$temp->setA( $a );
return $temp;
}
}

it's almost overloading lol.

Regards!

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Constructor usage

--00c09f80173a4ed5a20483738bb6
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Apr 4, 2010 at 6:36 PM, Larry Garfield 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

--00c09f80173a4ed5a20483738bb6--

Re: Constructor usage

On Sun, Apr 04, 2010 at 05:36:23PM -0500, Larry Garfield 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?

One problem I have with "parameterless constructors" is this: When you
rely on setters to shape your object rather than the constructor, your
other methods cannot assume the object is in proper shape to be usable.
There's no guarantee the programmer won't forget one of the vital
setters. So each method in the object must test to ensure the object can
actually be used properly. This isn't a deal-breaker, but it seems like
an awfully unnecessary piece of additional code which must be replicated
in each method. (Naturally, this is moot where the class doesn't depend
on any outside objects or parameters to operate.)

By the way, I've found this to be a problem in C++ as well. I personally
prefer not to have to pass parameters to a constructor, but even in C++,
doing so seems a simpler solution than relying on the programmer to
remember to call the proper setters.

I've found that many of my classes require other classes in order to
operate. Moreover, they must be instantiated in the proper order, or
things fall apart. So I took the step of creating my own "dependency
injection instantiator" class which handles all this for me. Classes
with dependencies typically are specified so that the requisite objects
are passed to the constructor (the simplest way). Each class which is
managed by the DII is registered first, with whatever parameter or
object dependencies needed. Then the DII's "instantiate()" method is
called as needed for each object. The DII class handles instantiating
objects in the proper order and with the proper dependencies. The
programmer's job is made much simpler.

Paul

--
Paul M. Foster

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Constructor usage

On Sunday 04 April 2010 09:21:28 pm Paul M Foster wrote:

> > 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?
>
> One problem I have with "parameterless constructors" is this: When you
> rely on setters to shape your object rather than the constructor, your
> other methods cannot assume the object is in proper shape to be usable.
> There's no guarantee the programmer won't forget one of the vital
> setters. So each method in the object must test to ensure the object can
> actually be used properly. This isn't a deal-breaker, but it seems like
> an awfully unnecessary piece of additional code which must be replicated
> in each method. (Naturally, this is moot where the class doesn't depend
> on any outside objects or parameters to operate.)

Yeah, I tend toward using constructors for injection for the same reason: That
way I always know for sure that if I have an object, it's "complete". I defer
most object instantiation to factories anyway, so in practice it's not a huge
issue for me.

> I've found that many of my classes require other classes in order to
> operate. Moreover, they must be instantiated in the proper order, or
> things fall apart. So I took the step of creating my own "dependency
> injection instantiator" class which handles all this for me. Classes
> with dependencies typically are specified so that the requisite objects
> are passed to the constructor (the simplest way). Each class which is
> managed by the DII is registered first, with whatever parameter or
> object dependencies needed. Then the DII's "instantiate()" method is
> called as needed for each object. The DII class handles instantiating
> objects in the proper order and with the proper dependencies. The
> programmer's job is made much simpler.
>
> Paul

Sounds overly complicated, but whatever works. :-) In my experience so far I
find that a well-designed factory is sufficient, but it may not be in larger or
more involved OO frameworks than I've used to date.

--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Constructor usage

On Sun, 04 Apr 2010 17:46:19 -0600, Nathan Rixham
wrote:

> Larry Garfield 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?
>

Other than theoretical reasons, one practical reason to have getters and
setters is to make live easier for IDE's.

I never thought the above two are in conflict. Usually parameterized
constructors are provided along with getters and setters - each is used
for good reasons.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php