OO is supposed to be about modularisation right? Separating your concerns and all.
Suppose I told you there were two major areas of your code that were deeply intertwined. Each is intimately connected to the other and it was almost impossible to tell where one started and the other began, yet the two were really very different.
Doesn’t sound very modular, does it? Practically the antithesis of good OO practice.
Suppose I now told you those two areas were “behaviour” and “data”.
Don’t mind me. Just thinking out loud…
I think behavior is just another variety of data.
I also think a long stream of text easily fails in making this distinction.
If an alien from an advanced civilisation landed on this planet and was asked to invent something that was as “non-modular” as possible, would it look like what we call OO?
I suppose OOP’s patch for this paradox is the MVC design pattern. The model connects as little logic to the data as possible, leaving the controller to manage the rest (though balance of code weight between model and controller is subjective; maybe your point is a good indication of where the weight should predominately be).
Part of where OO fits the problem domain nicely is where you have a bunch of entities that have naturally identifiable information as well as operations on that information. This means the coupling is already there in the conceptual space.
If you can’t tell your data from your behavior, you’re probably in the wrong field.
Oh, come now.
Why should that be true?
My mother couldn’t separate the data from the behavior in anything more than a spreadsheet.
That doesn’t mean we shouldn’t be working our asses off to figure out how to present this stuff so that she could.
In Scheme, behavior is data. What does this have to do with David’s post? Absolutely nothing.
To the point, one thing I’ve learned from Haskell type classes is that the OO concept of an interface is limited because it misses a critical point – sometimes a complete interface needs include a way to create data when you don’t already have data of the right type. That can be done in OO, but you end up with two types: the type for the data and the type for the “factory” to create the data. So now you have two tightly coupled types when conceptually you should only need one.