Schauderhaft

I don´t agree with you on the first problem: lots of ctor arguments need not be a sign of multiple responsibilities. In fact it can be a sign of exactly 1 responsibility. And I´d even argue this should be the only reason for a ctor dependency argument:

An object depending on others should have as its responsibility only “integration”, i.e. wiring together its dependencies to form a whole.

If that´s really the only responsibility of an object then it´s only dependent on the syntax/form of the injected objects. It does not have a clue as to what they are doing. Therefore it´s no problem to be dependent on many objects. Like a DI container is dependent on many objects.

(This is a more roundabout statement than what I really mean. But I leave it at that to make it a bit more thought provoking

I agree with using constructor injection wherever possible and was mostly influenced to use it by the teachings of Misko Hevery: http://misko.hevery.com/2008/11/11/clean-code-talks-dependency-injection/

What usually bugs me is, that when using the Spring XML configuration you can only express the constructor arguments as ordered list instead of expressing them as named properties. Constructor dependencies become much nicer to use when using annotations (Spring or Guice) to express the binding, but that is a whole other discussion in itself.

In a perfect world you should not have any object instantiation in your business logic and have the DI layer create and inject those dependencies. The only exception are pure data objects (Holders, DTOs,..) which you still have to instantiate in your code.

If you were there in mid 2003, this was called type-3 IoC by PicoContainer. Hardly any news though.

The more I think about it, the less the whole IoC/DI feels like a valid object oriented approach to me.. This leads back to good old structured programming of the 80′s on a straight wide road.

What I dislike in DI is exactly the “background magic” you start the post with, and the massive horde of singletons which usually come with it. The cake pattern (Scala) was a very surprising approach on the first look but now I think it’s actually a better idea than a DI framework (or manual DI, though it’s a kind of manual DI at the end).

Now that you mention whether OO is a good idea at all.. excellent question. The more I learn the very basics of Haskell, the more I actually question that too..

This path of learning reflects a kind of personal evolution though, so I consider this “time wasted well”. I really wonder where it ends.

Have you never seen the Static Builder Pattern from the Second Edition of Josh Bloch’s Effective Java? Better solution than your two listed here.

I agree with your conclusions though.

@Rob: So, does OOP work? And then which kind of OOP? The 1988 kind of OOP or the 1995 kind of OOP or the 2003 kind of OOP?

Obviously OOP has not been able to deliver on reuse as expected. And also obviously OOP has not saved us from heaps of technical debt and brownfield code.

So what exactly is good and worth to keep in OOP, what needs improvement, what needs to be shed?

@Rob: Objects have not done much above ordinary libraries in terms of reuse, I´d say. We were able to encapsulate code in DLLs and linker modules before OOP. In fact the much acclaimed VBX libraries which did so much for UI components back in the 1990s were just DLLs with a non-OOP interface (if I remember correctly).

And DSLs… I doubt we´ll see much use of them above SQL and RegEx. People have a hard time to come up with decend libraries/frameworks. How should they be able to sling their own DSL?

It would need a very generic DSL to find widespread use. A DSL to help with very fundamental stuff – which then probably would replace some of what OOP tried to deliver on so far.

A DSL for integrating functionality maybe. I´d be all for it Confine OOP 3GL code to small units which then are connected using a DSL.

@Rob: It´s sad you need to become personal and ask me to first learn something.

That´s especially sad since you yourself claim to know the truth. All´s well. DSL are about to solve our problems. We´re almost there. And on top: whatever happened in the 90s was bullshit.

On top: I just said that OOP did not deliver on reuse as much as it promised. Reuse through libraries is decades older. We never needed OOP for that. Modula delivered on reuse possibility as much as C++ did.

And I really doubt that OOP´s promise to make reuse easy through inheritance did a lot of good. How else do you explain the GoF statement in their 1995 (!) book: favor composition over inheritance?

As for anecdotal evidence: I´m doing team assessments on a regular basis, meaning around once a month. This means every month I see a different (!) team and ask them to solve a simple problem using their choice of tools and paradigms – which today means they use Java/C# and Eclipse/IntelliJ/VS.

And guess what: Those teams fail to deliver 90% of the times. They fail to deliver on time (which means within a timeframe of 2h). They fail to deliver on quality (which means their code looks like s***).

How come if all´s well in OOP land? Are those guys just dumb programmers? Well, let me tell you, they are – as you might expect – average.

Yes, this is not really an empiric study I´m talking about. But certainly it´s more than just anecdotal evidence given by people about themselves. I´m outside those teams, I don´t have stakes in their performance. So my point of view is pretty neutral. It´s diverse teams from all all kinds of business domains. It´s self taught programmers as well as guys with bachelor and masters degrees. They´re trying to make sense of OOP, patterns, principles, practices. So what I´m seeing is not state of the art, but state of the practice.

My conclusion for such pretty broad sampling: OOP does not deliver in a lot of ways. Things become better. DSLs might help. Fluent interfaces might help. But the very basic paradigm is making it hard for teams to deliver functionality and (!) evolovability. There´s work to do.

So maybe you want to sit down and do your homework and gather some data yourself instead of just reading blogs and stuff from people who are above average and highly motivated.

@Ralf, wow, your conclusions are all wrong. I said whatever happened in the 90s was bullshit? No, I said VB and its DLL components failed to deliver (do those words sound familiar?). Lot of great stuff happened in the 90s. Half the 90s was the rise of Java. So try and control your very obvious inclination to paint every thing in only black and white.

As to the Gang of Four, what on earth is your point there. Notice the word choice there: FAVOR!! Something you cannot understand because you only like yes or no. Favor means use this when possible, otherwise use the other. Again, I just find this constant ‘I did inheritance once and it made a mess,’ baby talk. There are a lot of places where inheritance makes a lot of sense.

Did you happen to notice that tons of the DPs in Gang of Four use inheritance? Like builder with its Abstract and Concerte builders and Bridge with it’s 2 hierarchies (bound by a delegate)? Composite, Factory Method.. on and on….

Clearly your therapist has not helped much on your control issues.

Here’s my answer: e. it’s amusing. So you mock me for being outraged that a student who paid $150K doesn’t know basic things while you issue a decree that objects ought be abandoned because they are a tissue of lies. Ok, that makes sense. Kind of like ‘no one trained him on how to speak english then we dropped him into coursework where it was required and he did poorly. Time to abandon english.’

Maybe you would prefer to continue with a puppet where you can provide both voices.

I did notice that you didn’t address any of the issues I brought up with your theses, e.g. that the Go4 patterns are soaked in the bogie man inheritance. It’s ok, there are no good responses to contradictory facts.

I didn’t say you were clueless. You seem very educated, though, in a glowing dream of yesteryear. I just said go try some of the newer approaches before you conclude that there is no way to save objects.

You forgot all of the above. Clearly that is your response. I am not enraged. You are. You just think the veneer of politesse you are trying to coat your material with masks that. It doesn’t. (P/A)

@Oliver: I´m not talking about a factory. If a DI container functions like a factory then that´s fine with me. And I´m all for ctor injection.

However, I´m asking: What´s going on if a dependency tree looks like this:

DomainlogicRootClass
  DomainlogicClassA
    DomainlogicClassF
  DomainlogicClassB
    DomainlogicClassK
    DomainlogicClassL

On every level of this hierarchy domain logic resides. That´s how it´s usually done. That´s why IoC is used and a DI container is supposed to inject an instance of DomainlogicClassF into an instance of DomainlogicClassA etc. That´s what Jens ment, right?

Now, what I find highly problematic is that domain logic is spread vertically (!) over the hierarchy. That not only makes all non-leaf classes hard to test. It also violates the Single Responsibility Principle (SRP).

The purpose of all non-leaf classes is twofold: they are responsible for executing domain logic plus (!) they integrate lower level functionality.

This sure sounds normal, even inevitable. But at least inevitable it is not.

So what I´m saying is: If you´re serious about SOLID, then take SRP seriously, which means become eXtreme in comparison to its usual interpretation, do xSRP

Keep all non-leaf classes free of domain logic (or whatever concern we´re talking about). Do not let them add value in terms of fulfilling functional/non-functional requirements. No expressions, no control statements.

This will degenerate those classes. They´ll become pure integrators. But that´s ok. No, that´s even highly beneficial, I´d say.

Firstly, this makes all classes much easier to test. The need for mock objects is drastically reduced. I haven´t used a mock framework in months for my development.

Secondly, this makes it very easy to spot where functionality you need to change is located. It can only sit in one of the leaf classes.

Thirdly, all non-leaf classes become dispensable Since they don´t fulfill any function above integrating lower level objects into a whole, this can be done in a different and easier way. Think DSL if you like

I´ve been working along these lines for the past 2 years. And is has greatly simplyfied my coding. And it has much improved the readability of my programs.

PS: Just to anticipate a usual objection: I´m not talking about your grandfather´s procedural or structured programming (SP) here This is different at least in that SP never was that rigorous in terms of SP. Also this approach does not require you to give up on ADTs or encapsulation. Technical OOP is just fine – but it´s curbed.

@Jens: You see, that´s the point: A should not decide. A decision is part of the domain to which A belongs.

If you want to follow the SRP you have to choose:
-either A integrates B and C functionality
-or A contains business logic.

Or at least this decision has to be made for each method:

-either a method a of A integrates b and c
-or a implements domain logic – and the decision has to be made somewhere else.

@Jens: Pushing the logic into the leaves requires you to use continuations, e.g.

class A {
  B b;
  C c;
  ...
  doSomething() {
    decide(
      b.doSomething, 
      c.doSomething);
  }

  decide(Action onTrue, Action onFalse) {
    if (some condition)
      onTrue();
   else
     onFalse();
  }
}

This works fine in C# where Action is defined as


delegate void Action();


It´s a type safe function pointer.

See how doSomething() now only does the “wiring”? It is independent of the condition and also independent of how the decision is made, whether an if is used of some other means. As long as the basic structure of the decision (no input, two alternate paths to follow) stays the same, decide() does not need to change.

SLA just would push “some condition” into a function of its own. But this goes a step further. If even pushes down the decision itself. decide() is just a method with two out-flows. maybe they alternatively carry data. maybe under some circumstances processing continues down both paths. decide() does not care.

What would it take to convince you?
I guess: You need to see this applied to a larger code base.
And you need to experience the development process using this approach. Because that´s changing the way you approach solutions.

What do you do when you want to communicate between a View and it’s Controller/Producer? In that case you need the view injected in the presenter and otherwise.

With CDI/Weld you can inject the View in the Controller and otherwise without getting a cyclic dependency when you “lazy inject” at one side (http://stackoverflow.com/questions/8749073/better-way-to-pass-class-reference-to-an-injected-instance?answertab=active#tab-top)