Too many injections

[Donaldson, John (GEO)]

I've been fairly strict about injecting dependencies in my current work.
It works nicely and I have few integration problems because each item knows what it wants and what it's responsibilities are.
So far so good.

But I'm getting situations where some classes have 3 or 4 dependencies.
This seems like a bit of a smell developing.

The places where it happens are the classes that build a complex object tree out of entities stored in the data layer.
For the sake of discussion let's say a Person has a House, a Car and some Pets.
We'll have a PersonFinder class with a Find method that returns a Person object complete with its House, Car and Pets.
We'll have a PersonGateway to retrieve a person from storage, a HouseGateway to retrieve a House and so on.

But this means that PersonFInder has dependencies on PersonGateway, HouseGateway, CarGateway and PetGateway.

This seems to violate the SRP, doesn't it? And it's a pain to mock all those dependencies (or fake them or whatever).

Am I doing something wrong?
However I think of restructuring this, the "Person assembler" class has to have its hands on all those dependencies.

John D.


[Non-text portions of this message have been removed]

[Carlo Bottiglieri]

Hello,
unless PersonFinder also creates PersonGateway and the others I see no
obvious breach of SRP in PersonFinder. It seems to have just one
responsibility : assembling Person. Correct?
Also, all those gateways are all used together I believe? Thus
PersonFinder should have an high cohesion, calling a set of quite
homogeneous gateways.

About stubbing I would use an object mother* to get a fully stubbed
PersonFinder in most tests that require it. Besides I would not expect
too many tests to rely on a stubbed PersonFinder, unless the
initialization logic is getting sprinkled around in multiple "scripts"
calling finders everywhere; maybe that's a growing smell?

If I were to point out a potential breach of SRP, just guessing of
course, what about Person itself? If PersonFinder has to build such a
rich object as a Person, perhaps Person has too many responsibilities?
Which would cause it to have a nice, heterogeneous set of dependencies
such as Car, Home and Pets.
My pain threshold is in fact around 5 dependencies, but it may be that
you'll find Person to have some responsibilities unrelated to a subset
of its dependencies?

Just probing.

* http://martinfowler.com/bliki/ObjectMother.html

On Sat, Oct 17, 2009 at 6:19 PM, Donaldson, John (GEO)
<john.m.donaldson@...> wrote:

> I've been fairly strict about injecting dependencies in my current work.
> It works nicely and I have few integration problems because each item knows what it wants and what it's responsibilities are.
> So far so good.
>
> But I'm getting situations where some classes have 3 or 4 dependencies.
> This seems like a bit of a smell developing.
>
> The places where it happens are the classes that build a complex object tree out of entities stored in the data layer.
> For the sake of discussion let's say a Person has a House, a Car and some Pets.
> We'll have a PersonFinder class with a Find method that returns a Person object complete with its House, Car and Pets.
> We'll have a PersonGateway to retrieve a person from storage, a HouseGateway to retrieve a House and so on.
>
> But this means that PersonFInder has dependencies on PersonGateway, HouseGateway, CarGateway and PetGateway.
>
> This seems to violate the SRP, doesn't it? And it's a pain to mock all those dependencies (or fake them or whatever).
>
> Am I doing something wrong?
> However I think of restructuring this, the "Person assembler" class has to have its hands on all those dependencies.
>
> John D.
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Alan Baljeu]

True or false: Main() inevitably depends on everything.  I think it's true.

Since (if?) that's the case, you can either have Main connect all the
hundreds of independent classes, or else you have Main use connector
classes.  These connector classes must depend on several concrete
classes.  I don't see a way out, unless you do a chaining configuration
where the dependencies are limited to 2 per class.

Given this, I advise making your connector code dirt simple:
Person p = new Person;
Car c = new Car;
House h = new House(p, c, new Cat());
h.GoNuts();

I'd be delighted if somebody can demonstrate that there's a better way,
but I think that's the reality.  

 Alan Baljeu





________________________________
From: "Donaldson, John (GEO)" <john.m.donaldson@...>
To: "testdrivendevelopment@..." <testdrivendevelopment@...>
Sent: Sat, October 17, 2009 12:19:45 PM
Subject: [TDD] Too many injections

 
I've been fairly strict about injecting dependencies in my current work.
It works nicely and I have few integration problems because each item knows what it wants and what it's responsibilities are.
So far so good.

But I'm getting situations where some classes have 3 or 4 dependencies.
This seems like a bit of a smell developing.

The places where it happens are the classes that build a complex object tree out of entities stored in the data layer.
For the sake of discussion let's say a Person has a House, a Car and some Pets.
We'll have a PersonFinder class with a Find method that returns a Person object complete with its House, Car and Pets.
We'll have a PersonGateway to retrieve a person from storage, a HouseGateway to retrieve a House and so on.

But this means that PersonFInder has dependencies on PersonGateway, HouseGateway, CarGateway and PetGateway.

This seems to violate the SRP, doesn't it? And it's a pain to mock all those dependencies (or fake them or whatever).

Am I doing something wrong?
However I think of restructuring this, the "Person assembler" class has to have its hands on all those dependencies.

John D.

[Non-text portions of this message have been removed]


   


      __________________________________________________________________
Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com

[Non-text portions of this message have been removed]

[Rick Mugridge]

Hi John,

3 or 4 dependencies don't seem bad to me. Some objects are just very
connected and there's nothing you can do about it. Of course, it's worth
taking a second look to see that your central object isn't due for
mitosis.  I'd be looking very closely if there were 5 or 6, as that may
be telling me something about either the need for mitosis or the way
I've conceived the roles.

Note that sometimes I'll inject the same object in twice to fulfill
different interfaces (roles).

Cheers, Rick

Donaldson, John (GEO) wrote:

>  
>
> I've been fairly strict about injecting dependencies in my current work.
> It works nicely and I have few integration problems because each item
> knows what it wants and what it's responsibilities are.
> So far so good.
>
> But I'm getting situations where some classes have 3 or 4 dependencies.
> This seems like a bit of a smell developing.
>
> The places where it happens are the classes that build a complex
> object tree out of entities stored in the data layer.
> For the sake of discussion let's say a Person has a House, a Car and
> some Pets.
> We'll have a PersonFinder class with a Find method that returns a
> Person object complete with its House, Car and Pets.
> We'll have a PersonGateway to retrieve a person from storage, a
> HouseGateway to retrieve a House and so on.
>
> But this means that PersonFInder has dependencies on PersonGateway,
> HouseGateway, CarGateway and PetGateway.
>
> This seems to violate the SRP, doesn't it? And it's a pain to mock all
> those dependencies (or fake them or whatever).
>
> Am I doing something wrong?
> However I think of restructuring this, the "Person assembler" class
> has to have its hands on all those dependencies.
>
> John D.
>
> [Non-text portions of this message have been removed]
>
>

[Non-text portions of this message have been removed]

[Manuel Klimek]

Hi John,

Apart from 3-4 dependencies not being bad, in your case you have some choice
as to on what abstraction level to couple, and I probably wouldn't do it on
the Person level, but one up. Why not have a class Belongings (probably a
bad name...).Belongings takes a Person and the *Gateways to the belongings
and has one method to return each belonging. This way the Person stays
lightweight (I imagine you will need a person without all of its belongings
a few times), and on the same abstraction level as the other stuff. Now if
you do that, you just shift the dependencies into Belongings, and it is
similar to the PersonAssembler you proposed in the first place, but it's
another option.

Cheers,
/Manuel


On Sat, Oct 17, 2009 at 6:19 PM, Donaldson, John (GEO) <
john.m.donaldson@...> wrote:

>
>
> I've been fairly strict about injecting dependencies in my current work.
> It works nicely and I have few integration problems because each item knows
> what it wants and what it's responsibilities are.
> So far so good.
>
> But I'm getting situations where some classes have 3 or 4 dependencies.
> This seems like a bit of a smell developing.
>
> The places where it happens are the classes that build a complex object
> tree out of entities stored in the data layer.
> For the sake of discussion let's say a Person has a House, a Car and some
> Pets.
> We'll have a PersonFinder class with a Find method that returns a Person
> object complete with its House, Car and Pets.
> We'll have a PersonGateway to retrieve a person from storage, a
> HouseGateway to retrieve a House and so on.
>
> But this means that PersonFInder has dependencies on PersonGateway,
> HouseGateway, CarGateway and PetGateway.
>
> This seems to violate the SRP, doesn't it? And it's a pain to mock all
> those dependencies (or fake them or whatever).
>
> Am I doing something wrong?
> However I think of restructuring this, the "Person assembler" class has to
> have its hands on all those dependencies.
>
> John D.
>
> [Non-text portions of this message have been removed]
>
>  
>

--
http://klimek.box4.net


[Non-text portions of this message have been removed]

[ulu]

How about using events like GimmeAHouse etc? The "Assembler" object would raise these events, and some other object which is subscribed would provide respective instances through the event arguments. I'm not sure that's easier to test (unless you make the dependency optional, i.e., if there's no CarGateway available, let the person have no car), but it looks like less coupling.

Just another option to consider..

ulu

--- In testdrivendevelopment@..., "Donaldson, John (GEO)" <john.m.donaldson@...> wrote:

>
> I've been fairly strict about injecting dependencies in my current work.
> It works nicely and I have few integration problems because each item knows what it wants and what it's responsibilities are.
> So far so good.
>
> But I'm getting situations where some classes have 3 or 4 dependencies.
> This seems like a bit of a smell developing.
>
> The places where it happens are the classes that build a complex object tree out of entities stored in the data layer.
> For the sake of discussion let's say a Person has a House, a Car and some Pets.
> We'll have a PersonFinder class with a Find method that returns a Person object complete with its House, Car and Pets.
> We'll have a PersonGateway to retrieve a person from storage, a HouseGateway to retrieve a House and so on.
>
> But this means that PersonFInder has dependencies on PersonGateway, HouseGateway, CarGateway and PetGateway.
>
> This seems to violate the SRP, doesn't it? And it's a pain to mock all those dependencies (or fake them or whatever).
>
> Am I doing something wrong?
> However I think of restructuring this, the "Person assembler" class has to have its hands on all those dependencies.
>
> John D.
>
>
> [Non-text portions of this message have been removed]
>

[gutzofter]

@jon,

Reverse the dependencies. Your house is not the entity. The house is a collection of behaviors/strategies that the entities (person, pet, car)interact in. Each entity will take a house (is-a building).

Psuedo-code follows:

class Person {


PrepareToEat(building)
{
 building.Eat(this);
}
}

class House : Building {
{
Eat(person){
person.Cook();
person.Eat();
person.Clean();
}

class McDs : Building {
Eat(person) {
person.Eat();
}

Now because of the connection between these entities and strategies, there is another object here. It is some kind of controller / coordinator. It was always there it just happened to be implicit in the original house object. As the number of entities that the house managed it became more brittle to manage, especially in your tests.

PS: When I was into autonomous agents/a-life/dynamic systems, I remember reading that 2-3 connections between agents allowed for novel behavior. Less than 2 made for very static behavior. More than three led to chaos. IMHO 2-3 dependencies is enough for me.





--- In testdrivendevelopment@..., "Donaldson, John (GEO)" <john.m.donaldson@...> wrote:

>
> I've been fairly strict about injecting dependencies in my current work.
> It works nicely and I have few integration problems because each item knows what it wants and what it's responsibilities are.
> So far so good.
>
> But I'm getting situations where some classes have 3 or 4 dependencies.
> This seems like a bit of a smell developing.
>
> The places where it happens are the classes that build a complex object tree out of entities stored in the data layer.
> For the sake of discussion let's say a Person has a House, a Car and some Pets.
> We'll have a PersonFinder class with a Find method that returns a Person object complete with its House, Car and Pets.
> We'll have a PersonGateway to retrieve a person from storage, a HouseGateway to retrieve a House and so on.
>
> But this means that PersonFInder has dependencies on PersonGateway, HouseGateway, CarGateway and PetGateway.
>
> This seems to violate the SRP, doesn't it? And it's a pain to mock all those dependencies (or fake them or whatever).
>
> Am I doing something wrong?
> However I think of restructuring this, the "Person assembler" class has to have its hands on all those dependencies.
>
> John D.
>
>
> [Non-text portions of this message have been removed]
>

[William Rutiser]

gutzofter wrote:

>
>
>
>
>
>
> @jon,
>
> Reverse the dependencies. Your house is not the entity. The house is a collection of behaviors/strategies that the entities (person, pet, car)interact in. Each entity will take a house (is-a building).
>
> Psuedo-code follows:
>
> class Person {
>
>
> PrepareToEat(building)
> {
>  building.Eat(this);
> }
> }
>
> class House : Building {
> {
> Eat(person){
> person.Cook();
> person.Eat();
> person.Clean();
> }
>
> class McDs : Building {
> Eat(person) {
> person.Eat();
> }
>
> Now because of the connection between these entities and strategies, there is another object here. It is some kind of controller / coordinator. It was always there it just happened to be implicit in the original house object. As the number of entities that the house managed it became more brittle to manage, especially in your tests.
>
> PS: When I was into autonomous agents/a-life/dynamic systems, I remember reading that 2-3 connections between agents allowed for novel behavior. Less than 2 made for very static behavior. More than three led to chaos. IMHO 2-3 dependencies is enough for me.
>
>
>
>
>
> --- In testdrivendevelopment@..., "Donaldson, John (GEO)" <john.m.donaldson@...> wrote:
>  
>> I've been fairly strict about injecting dependencies in my current work.
>> It works nicely and I have few integration problems because each item knows what it wants and what it's responsibilities are.
>> So far so good.
>>
>> But I'm getting situations where some classes have 3 or 4 dependencies.
>> This seems like a bit of a smell developing.
>>
>> The places where it happens are the classes that build a complex object tree out of entities stored in the data layer.
>> For the sake of discussion let's say a Person has a House, a Car and some Pets.
>> We'll have a PersonFinder class with a Find method that returns a Person object complete with its House, Car and Pets.
>> We'll have a PersonGateway to retrieve a person from storage, a HouseGateway to retrieve a House and so on.
>>
>> But this means that PersonFInder has dependencies on PersonGateway, HouseGateway, CarGateway and PetGateway.
>>
>> This seems to violate the SRP, doesn't it? And it's a pain to mock all those dependencies (or fake them or whatever).
>>
>> Am I doing something wrong?
>> However I think of restructuring this, the "Person assembler" class has to have its hands on all those dependencies.
>>
>> John D.
>>
>>
>> [Non-text portions of this message have been removed]
>>
>>    

It may be that the Visitor pattern has a place here. It moves
dependencies into the class itself.

-- Bill

[ulu]

Is it just me, or does the line "building.Eat(person)" looks a bit scary?

ulu

--- In testdrivendevelopment@..., "gutzofter" <gutzofter@...> wrote:

>
>
>
>
>
>
>
>
>
> @jon,
>
> Reverse the dependencies. Your house is not the entity. The house is a collection of behaviors/strategies that the entities (person, pet, car)interact in. Each entity will take a house (is-a building).
>
> Psuedo-code follows:
>
> class Person {
>
>
> PrepareToEat(building)
> {
>  building.Eat(this);
> }
> }
>
> class House : Building {
> {
> Eat(person){
> person.Cook();
> person.Eat();
> person.Clean();
> }
>
> class McDs : Building {
> Eat(person) {
> person.Eat();
> }
>
> Now because of the connection between these entities and strategies, there is another object here. It is some kind of controller / coordinator. It was always there it just happened to be implicit in the original house object. As the number of entities that the house managed it became more brittle to manage, especially in your tests.
>
> PS: When I was into autonomous agents/a-life/dynamic systems, I remember reading that 2-3 connections between agents allowed for novel behavior. Less than 2 made for very static behavior. More than three led to chaos. IMHO 2-3 dependencies is enough for me.
>
>
>
>
>
> --- In testdrivendevelopment@..., "Donaldson, John (GEO)" <john.m.donaldson@> wrote:
> >
> > I've been fairly strict about injecting dependencies in my current work.
> > It works nicely and I have few integration problems because each item knows what it wants and what it's responsibilities are.
> > So far so good.
> >
> > But I'm getting situations where some classes have 3 or 4 dependencies.
> > This seems like a bit of a smell developing.
> >
> > The places where it happens are the classes that build a complex object tree out of entities stored in the data layer.
> > For the sake of discussion let's say a Person has a House, a Car and some Pets.
> > We'll have a PersonFinder class with a Find method that returns a Person object complete with its House, Car and Pets.
> > We'll have a PersonGateway to retrieve a person from storage, a HouseGateway to retrieve a House and so on.
> >
> > But this means that PersonFInder has dependencies on PersonGateway, HouseGateway, CarGateway and PetGateway.
> >
> > This seems to violate the SRP, doesn't it? And it's a pain to mock all those dependencies (or fake them or whatever).
> >
> > Am I doing something wrong?
> > However I think of restructuring this, the "Person assembler" class has to have its hands on all those dependencies.
> >
> > John D.
> >
> >
> > [Non-text portions of this message have been removed]
> >
>

[gutzofter]

What if procreation is involved. Just try and figure out those business rules ;)

--- In testdrivendevelopment@..., "uluhonolulu" <uluhonolulu@...> wrote:

>
> Is it just me, or does the line "building.Eat(person)" looks a bit scary?
>
> ulu
>
> --- In testdrivendevelopment@..., "gutzofter" <gutzofter@> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > @jon,
> >
> > Reverse the dependencies. Your house is not the entity. The house is a collection of behaviors/strategies that the entities (person, pet, car)interact in. Each entity will take a house (is-a building).
> >
> > Psuedo-code follows:
> >
> > class Person {
> >
> >
> > PrepareToEat(building)
> > {
> >  building.Eat(this);
> > }
> > }
> >
> > class House : Building {
> > {
> > Eat(person){
> > person.Cook();
> > person.Eat();
> > person.Clean();
> > }
> >
> > class McDs : Building {
> > Eat(person) {
> > person.Eat();
> > }
> >
> > Now because of the connection between these entities and strategies, there is another object here. It is some kind of controller / coordinator. It was always there it just happened to be implicit in the original house object. As the number of entities that the house managed it became more brittle to manage, especially in your tests.
> >
> > PS: When I was into autonomous agents/a-life/dynamic systems, I remember reading that 2-3 connections between agents allowed for novel behavior. Less than 2 made for very static behavior. More than three led to chaos. IMHO 2-3 dependencies is enough for me.
> >
> >
> >
> >
> >
> > --- In testdrivendevelopment@..., "Donaldson, John (GEO)" <john.m.donaldson@> wrote:
> > >
> > > I've been fairly strict about injecting dependencies in my current work.
> > > It works nicely and I have few integration problems because each item knows what it wants and what it's responsibilities are.
> > > So far so good.
> > >
> > > But I'm getting situations where some classes have 3 or 4 dependencies.
> > > This seems like a bit of a smell developing.
> > >
> > > The places where it happens are the classes that build a complex object tree out of entities stored in the data layer.
> > > For the sake of discussion let's say a Person has a House, a Car and some Pets.
> > > We'll have a PersonFinder class with a Find method that returns a Person object complete with its House, Car and Pets.
> > > We'll have a PersonGateway to retrieve a person from storage, a HouseGateway to retrieve a House and so on.
> > >
> > > But this means that PersonFInder has dependencies on PersonGateway, HouseGateway, CarGateway and PetGateway.
> > >
> > > This seems to violate the SRP, doesn't it? And it's a pain to mock all those dependencies (or fake them or whatever).
> > >
> > > Am I doing something wrong?
> > > However I think of restructuring this, the "Person assembler" class has to have its hands on all those dependencies.
> > >
> > > John D.
> > >
> > >
> > > [Non-text portions of this message have been removed]
> > >
> >
>

[Nat Pryce]

You don't say what language or persistence technology you're using. However,
when I see a Java system that follows that pattern it's often because the
system is not taking full advantage of the ORM library is.  With something
like JDO or JPA, a Java program would find the Person objects it wants to
play with and leave it up to the ORM to load/save the House, Car, Pets etc.
that the Person relates to when the ORM thinks best, as directed by cascade
and lazy loading declarations in the mapping.  So something wanting to load
Person objects from persistence storage would only have a single dependency
on the PersonFinder.

--Nat

2009/10/17 Donaldson, John (GEO) <john.m.donaldson@...>

>
>
> I've been fairly strict about injecting dependencies in my current work.
> It works nicely and I have few integration problems because each item knows
> what it wants and what it's responsibilities are.
> So far so good.
>
> But I'm getting situations where some classes have 3 or 4 dependencies.
> This seems like a bit of a smell developing.
>
> The places where it happens are the classes that build a complex object
> tree out of entities stored in the data layer.
> For the sake of discussion let's say a Person has a House, a Car and some
> Pets.
> We'll have a PersonFinder class with a Find method that returns a Person
> object complete with its House, Car and Pets.
> We'll have a PersonGateway to retrieve a person from storage, a
> HouseGateway to retrieve a House and so on.
>
> But this means that PersonFInder has dependencies on PersonGateway,
> HouseGateway, CarGateway and PetGateway.
>
> This seems to violate the SRP, doesn't it? And it's a pain to mock all
> those dependencies (or fake them or whatever).
>
> Am I doing something wrong?
> However I think of restructuring this, the "Person assembler" class has to
> have its hands on all those dependencies.
>
> John D.
>
> [Non-text portions of this message have been removed]
>
>  
>

--
http://www.natpryce.com


[Non-text portions of this message have been removed]

[Carlo Bottiglieri]

Hello,

On Mon, Oct 19, 2009 at 5:34 PM, Nat Pryce <nat.pryce@...> wrote:
[Snap]
> So something wanting to load
> Person objects from persistence storage would only have a single dependency
> on the PersonFinder.
>

Maybe I misinterpreted, but the way I read this :

>> But this means that PersonFInder has dependencies on PersonGateway,
>> HouseGateway, CarGateway and PetGateway.

Is that it's PersonFinder which has too many dependencies, not the
users of PersonFinder, which are happy, as they depend on just
PersonFinder already.
Did I miss something?

>>
>> This seems to violate the SRP, doesn't it? And it's a pain to mock all
>> those dependencies (or fake them or whatever).
>>
>> Am I doing something wrong?
>> However I think of restructuring this, the "Person assembler" class has to
>> have its hands on all those dependencies.
>>
>> John D.
>>
>> [Non-text portions of this message have been removed]
>>
>>
>>
>
>
>
> --
> http://www.natpryce.com
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Alan Baljeu]

I'm seeing a number of responses talking about ways a particular class can avoid having many dependencies.  I haven't seen however, a response to my assertion: Eventually something must have dependencies, and you really can't avoid them in the long run.

Am I wrong?  Or, if I'm right can you explain why it isn't a problem?



      __________________________________________________________________
Get the name you've always wanted @ymail.com or @rocketmail.com! Go to http://ca.promos.yahoo.com/jacko/

[Non-text portions of this message have been removed]

[gutzofter]

@alan,

You are correct! I think the question is not why we manage dependencies, but how.

--- In testdrivendevelopment@..., Alan Baljeu <alanbaljeu@...> wrote:

>
> I'm seeing a number of responses talking about ways a particular class can avoid having many dependencies.  I haven't seen however, a response to my assertion: Eventually something must have dependencies, and you really can't avoid them in the long run.
>
> Am I wrong?  Or, if I'm right can you explain why it isn't a problem?
>
>
>
>       __________________________________________________________________
> Get the name you've always wanted @ymail.com or @rocketmail.com! Go to http://ca.promos.yahoo.com/jacko/
>
> [Non-text portions of this message have been removed]
>

[Carlo Bottiglieri]

Something (almost everything, except the very leaves of the objects
composing a system, such as primitives) will have dependencies.
This does not mean that an object is forced to have <many>
dependencies. Nor that these dependencies should be concrete or
cyclic, or any other detrimental variations of a dependency graph.

I see no problem in a proper dependency graph at all, I'm thus forced
to turn the question around : why are dependencies a problem?


On Mon, Oct 19, 2009 at 7:36 PM, Alan Baljeu <alanbaljeu@...> wrote:

> I'm seeing a number of responses talking about ways a particular class can avoid having many dependencies.  I haven't seen however, a response to my assertion: Eventually something must have dependencies, and you really can't avoid them in the long run.
>
> Am I wrong?  Or, if I'm right can you explain why it isn't a problem?
>
>
>
>      __________________________________________________________________
> Get the name you've always wanted @ymail.com or @rocketmail.com! Go to http://ca.promos.yahoo.com/jacko/
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Donaldson, John (GEO)]

Nat,

I'm using c#.
I was trying to be strict about isolating each layer.
(I liked JB Rainsberger's "Integration Tests are a Scam" presentation).
At each layer there are a bunch of tests in which the next layer is mocked.
So, lots of dependency injection. And occasionally I'm injecting several dependencies.

So, it seemed to me I was starting to violate SRP.

Quite a few of the earlier replies - for which many thanks by the way - seemed to think it was not too serious and could be expected.

John D.

-----Original Message-----
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Nat Pryce
Sent: 19 October 2009 17:34
To: testdrivendevelopment@...
Subject: Re: [TDD] Too many injections

You don't say what language or persistence technology you're using. However,
when I see a Java system that follows that pattern it's often because the
system is not taking full advantage of the ORM library is.  With something
like JDO or JPA, a Java program would find the Person objects it wants to
play with and leave it up to the ORM to load/save the House, Car, Pets etc.
that the Person relates to when the ORM thinks best, as directed by cascade
and lazy loading declarations in the mapping.  So something wanting to load
Person objects from persistence storage would only have a single dependency
on the PersonFinder.

--Nat

2009/10/17 Donaldson, John (GEO) <john.m.donaldson@...>

>
>
> I've been fairly strict about injecting dependencies in my current work.
> It works nicely and I have few integration problems because each item knows
> what it wants and what it's responsibilities are.
> So far so good.
>
> But I'm getting situations where some classes have 3 or 4 dependencies.
> This seems like a bit of a smell developing.
>
> The places where it happens are the classes that build a complex object
> tree out of entities stored in the data layer.
> For the sake of discussion let's say a Person has a House, a Car and some
> Pets.
> We'll have a PersonFinder class with a Find method that returns a Person
> object complete with its House, Car and Pets.
> We'll have a PersonGateway to retrieve a person from storage, a
> HouseGateway to retrieve a House and so on.
>
> But this means that PersonFInder has dependencies on PersonGateway,
> HouseGateway, CarGateway and PetGateway.
>
> This seems to violate the SRP, doesn't it? And it's a pain to mock all
> those dependencies (or fake them or whatever).
>
> Am I doing something wrong?
> However I think of restructuring this, the "Person assembler" class has to
> have its hands on all those dependencies.
>
> John D.
>
> [Non-text portions of this message have been removed]
>
>  
>

--
http://www.natpryce.com


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

[Donaldson, John (GEO)]

Carlo,

Well, good question (just implied) "what's the definition of SRP". Uncle Bob has it as "one reason to change". From this perspective, each dependency introduces a "reason to change".

On the subject of object mother etc. Yes - in fact I just recently learned the builder pattern - very nice. And could build mock objects. Except with a mock, I have to feed in object instances, sometimes the same instance to two places, and I need to be able to verify at the end of the test. All of which means that it's messier than the normal mother/builder situation. But not impossible, and I am going in that direction.

John D.

-----Original Message-----
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Carlo Bottiglieri
Sent: 17 October 2009 19:05
To: testdrivendevelopment@...
Subject: Re: [TDD] Too many injections

Hello,
unless PersonFinder also creates PersonGateway and the others I see no
obvious breach of SRP in PersonFinder. It seems to have just one
responsibility : assembling Person. Correct?
Also, all those gateways are all used together I believe? Thus
PersonFinder should have an high cohesion, calling a set of quite
homogeneous gateways.

About stubbing I would use an object mother* to get a fully stubbed
PersonFinder in most tests that require it. Besides I would not expect
too many tests to rely on a stubbed PersonFinder, unless the
initialization logic is getting sprinkled around in multiple "scripts"
calling finders everywhere; maybe that's a growing smell?

If I were to point out a potential breach of SRP, just guessing of
course, what about Person itself? If PersonFinder has to build such a
rich object as a Person, perhaps Person has too many responsibilities?
Which would cause it to have a nice, heterogeneous set of dependencies
such as Car, Home and Pets.
My pain threshold is in fact around 5 dependencies, but it may be that
you'll find Person to have some responsibilities unrelated to a subset
of its dependencies?

Just probing.

* http://martinfowler.com/bliki/ObjectMother.html

On Sat, Oct 17, 2009 at 6:19 PM, Donaldson, John (GEO)
<john.m.donaldson@...> wrote:

> I've been fairly strict about injecting dependencies in my current work.
> It works nicely and I have few integration problems because each item knows what it wants and what it's responsibilities are.
> So far so good.
>
> But I'm getting situations where some classes have 3 or 4 dependencies.
> This seems like a bit of a smell developing.
>
> The places where it happens are the classes that build a complex object tree out of entities stored in the data layer.
> For the sake of discussion let's say a Person has a House, a Car and some Pets.
> We'll have a PersonFinder class with a Find method that returns a Person object complete with its House, Car and Pets.
> We'll have a PersonGateway to retrieve a person from storage, a HouseGateway to retrieve a House and so on.
>
> But this means that PersonFInder has dependencies on PersonGateway, HouseGateway, CarGateway and PetGateway.
>
> This seems to violate the SRP, doesn't it? And it's a pain to mock all those dependencies (or fake them or whatever).
>
> Am I doing something wrong?
> However I think of restructuring this, the "Person assembler" class has to have its hands on all those dependencies.
>
> John D.
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

------------------------------------

Yahoo! Groups Links

[Donaldson, John (GEO)]

Carlo,

Yes, maybe I didn't express this clearly. You use PersonFinder to get a Person. A PersonFinder has various dependencies which are injected - for example a HouseGateway. So, in some tests, I'll be injecting mocked versions of a HouseGateway.

John D.

-----Original Message-----
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Carlo Bottiglieri
Sent: 19 October 2009 17:40
To: testdrivendevelopment@...
Subject: Re: [TDD] Too many injections

Hello,

On Mon, Oct 19, 2009 at 5:34 PM, Nat Pryce <nat.pryce@...> wrote:
[Snap]
> So something wanting to load
> Person objects from persistence storage would only have a single dependency
> on the PersonFinder.
>

Maybe I misinterpreted, but the way I read this :

>> But this means that PersonFInder has dependencies on PersonGateway,
>> HouseGateway, CarGateway and PetGateway.

Is that it's PersonFinder which has too many dependencies, not the
users of PersonFinder, which are happy, as they depend on just
PersonFinder already.
Did I miss something?

>>
>> This seems to violate the SRP, doesn't it? And it's a pain to mock all
>> those dependencies (or fake them or whatever).
>>
>> Am I doing something wrong?
>> However I think of restructuring this, the "Person assembler" class has to
>> have its hands on all those dependencies.
>>
>> John D.
>>
>> [Non-text portions of this message have been removed]
>>
>>
>>
>
>
>
> --
> http://www.natpryce.com
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

------------------------------------

Yahoo! Groups Links

[Donaldson, John (GEO)]

Alan,

Yes, pretty much how I see it - you can push the dependency around, but you cannot get rid of it. In fact, the "assembler" has dependencies on all the things it assembles. It sounds stupid to say it like that - but I've been round and round trying to split it into things that only have, say, two dependencies. For example, could we imagine assembling HouseAndCar and then a Person might only depend on that? It doesn't sound right though.

John D.

-----Original Message-----
From: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Alan Baljeu
Sent: 19 October 2009 19:37
To: testdrivendevelopment@...
Subject: Re: [TDD] Too many injections

I'm seeing a number of responses talking about ways a particular class can avoid having many dependencies.  I haven't seen however, a response to my assertion: Eventually something must have dependencies, and you really can't avoid them in the long run.

Am I wrong?  Or, if I'm right can you explain why it isn't a problem?



      __________________________________________________________________
Get the name you've always wanted @ymail.com or @rocketmail.com! Go to http://ca.promos.yahoo.com/jacko/

[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links

[Alan Baljeu]

[[From: Carlo Bottiglieri <carlo.bottiglieri@...>
 
Something (almost everything, except the very leaves of the objects
composing a system, such as primitives) will have dependencies.
This does not mean that an object is forced to have <many>
dependencies. Nor that these dependencies should be concrete or
cyclic, or any other detrimental variations of a dependency graph.

I see no problem in a proper dependency graph at all, I'm thus forced
to turn the question around : why are dependencies a problem?
]]

I see.  Here's how I'm looking at this.  Notice that some of these classes have many concrete dependencies, and as far as I can tell, it's unavoidable.  I am _not_ confident that this is the best approach, but I don't know any better approach.

Concrete class Household depends on  abstract classes Pet, Car, Person
Car derives concrete classes BMW, TestCar.
Pet derives concrete classes Cat, TestCat.
HouseholdMaker depends on HouseHold, BMW, Cat, Executive.
HouseholdTester1 depends on Household, TestCar
HouseholdTester2 depends on Household, TestCat
Concrete class Neighbourhood depends on abstract class Dwelling (Household inherits this)
NeighbourhoodMaker depends on Neighbourhood, HouseholdMaker and consequently on a few more things.

Eventually these Makers get pretty dependent.  Then to make them testable, we could break up their behavior into independent, composable methods so we can make whatever portions of a neighbourhood we want, for an integration test.  But it still seems rather messy up here.

Alan


      __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!

http://www.flickr.com/gift/