Comments on Mock Objects: Just when you thought it was safe to go back in th...

@Anonymous (perhaps you would like to leave a name...

2009-08-12T09:50:29.688+01:00

@Anonymous (perhaps you would like to leave a name?)

Nice to see that someone's still reading the old postings

If you look at the "rules" for which methods an object O may invoke, they're all attached to objects that are either internal to O or passed in to O. So, one reading is that O can only call external objects if they're passed in, which makes them explicit.

"One of the critical lessons from Demeter is ...

2009-08-11T18:22:06.558+01:00

"One of the critical lessons from Demeter is that objects should have explicit dependencies."

Really? I could not find any mention with similar meaning anywhere I looked:

http://en.wikipedia.org/wiki/Law_of_Demeter
http://www.ccs.neu.edu/home/lieber/LoD.html
http://www.ccs.neu.edu/research/demeter/papers/icse-04-keynote/ICSE2004.pdf
http://www.cmcrossroads.com/bradapp/docs/demeter-intro.html

What did I miss? Could you point out where I can find the source for that statement?

Sorry to post on this thread again and I'm a bit o...

2008-10-25T18:20:00.000+01:00

Sorry to post on this thread again and I'm a bit off topic here but I noticed Nat Pryce had posted on where/when he uses the LOD (http://c2.com/cgi/wiki?LawOfDemeter).

In particular I'm interested in the idea of having an exception for collections, am I right in thinking this is to avoid having boring pass throw methods in cases like customer.Orders.Add.

"I never cease to be amazed at the unexpected ways...

2008-01-20T20:09:00.000Z

"I never cease to be amazed at the unexpected ways I find code develops. At the gross level, separating layers is pretty obvious (although some people still argue). That's also where an IoC container might be appropriate."

Yeah agreed, between domain module/packages is another obvious example where the decoupling is useful.

"There are finer-grain levels too where these ideas still count, which is more what we're talking about here. Not every little feature, perhaps (that's another failure mode), but a lot more than many coders are used to."

I agree the ideas always count, but you need to find balance. I've certainly gone overboard on the decoupling approach and haven't found a lot of the loose coupling bought me anything. In a lot of cases a depdency on a concrete class isn't going to cause you any problems and you should just go for it.

@Colin. I never cease to be amazed at the unexpect...

2008-01-20T19:12:00.000Z

@Colin. I never cease to be amazed at the unexpected ways I find code develops. At the gross level, separating layers is pretty obvious (although some people still argue). That's also where an IoC container might be appropriate.

There are finer-grain levels too where these ideas still count, which is more what we're talking about here. Not every little feature, perhaps (that's another failure mode), but a lot more than many coders are used to.

@Nat. You just want a reference to Imperial Colleg...

2008-01-20T18:52:00.000Z

@Nat. You just want a reference to Imperial College in there. :)

"Well no—if you have enough foresight to know wher...

2008-01-20T18:49:00.000Z

"Well no—if you have enough foresight to know where those places are"

A lot of the time you have strong evidence though.

I certainly know that my data access or infrastructure code will change for different reasons and at a different pace from my business code so I decouple.

However I'm not at all worried about a domain class referencing directly a domain rule written for it. Customer referencing CustomerMustHaveAddressRule (directly or indirectly), don't mind that at all.

Correction: the earliest mention of CONIC in the a...

2008-01-20T17:13:00.000Z

Correction: the earliest mention of CONIC in the academic literature is 1981.

The idea behind DI: that of of clearly distinguish...

2008-01-20T17:11:00.000Z

The idea behind DI: that of of clearly distinguishing between an object (or component's) provided and required services and separating how peer objects are interrelated from their internal implementation details goes back further than the Law of Demeter. It was realised in the CONIC system [1] and perhaps in earlier systems too.

The idea has been given several names over the years. Dependency Injection is perhaps the worst, because it is so misleading.

[1] Kramer, J., Magee, J., Sloman, M.S., and Lister, A., CONIC: An Integrated Approach to Distributed Computer Control Systems, IEE Proceedings., 130, Pt. E, ( 1983), 1-10.

As everyone keeps saying, TypeMock is not limited ...

2008-01-20T15:18:00.000Z

As everyone keeps saying, TypeMock is not limited to working around the back. That's true but that's not what I, personally, am looking for.

I'm not sure what "DI for the sake of it" means. I use DI to introduce objects that need to talk to each other, so that each has a coherent set of responsibilities. I think about the relationships first and the dependencies derive from that. This is fundamental to the school of OO that I mostly follow, what Ralph Johnson is pleased to call the mystical view of OO.

It's not a tool issue. Many of my circle spent time in the Smalltalk mines, which is far more flexible than Ruby (wanna change the meaning of inheritance?), and the Demeter ideas applied then. In retrospect, many of us wish we'd used inheritance less and composition more.

To play devil's advocate for a second, Typemock wo...

2008-01-20T13:37:00.000Z

To play devil's advocate for a second, Typemock would help you exactly in the situation you posted above.
But I agree that DI is not dead. But perhaps it time to reconsider whether DI for the sake of DI is a bad thing, when tools allow testability even without it.
JMocking in Java and Typemock in .NET provide this ability, as well as ruby, where you can replace anything and everything.
Do you need DI in a language like ruby? where everything is replaceable?

Roy
(disclosure: I recently started working at Typemock)
ISerializable.com