But there is a totally different sort of objects .... objects that are (mostly) data containers.

There is a call for this type of object, but I think they are (or rather, should be) far rarer than they tend to be in many code bases. I think this comes about because people, and the texts/courses they learn from, tend to start their design process from the bottom and work up.

Data has no purpose in isolation of the code that manipulates it. That is, at some point in the application, there is code that instantiates and populates one or more of these "data container" objects and then operates upon the data encapsulated. That code is (should be) the methods for that data.

But that code often doesn't lend itself--because of other data dependencies; or code structural requirements--to being pushed down into the data object class as methods, so the objects becomes data only. Devoid of methods beyond constructors, destructors and accessors. And the result is that you've created a class to hold the data and access it and nothing more. But if you lifted the data within the container to the level where it is actually manipulated, then you'd save an entire layer of pure overhead.

That is to say, at level X of the application, instead of storing a reference to an object--a blessed hash in Perl terms; a 'blessed' struct in C++ terms--as a my/auto variable and accessing it contents through methods. You store the hash or struct in a my/auto variable at that level and access it contents directly. And you save the overhead method lookup and subroutine calls; and inconvenience of method call syntax to access the data.

Ie. Instead of:

{ ## some block at some level
    my obj = Class->new( initX, initY );
    
    obj->setZ( obj->getX() + obj->getY() );
}
[download]

You have:

{ ## some block at some level
    my %hash = ( X => initX, Y => initY, Z => 0 );
 
    $hash{Z} = $hash{X} + $hash{Y};
}
[download]

Now someone will say, but what if you have two (or more) places in you code where you need this object. by inlining it you are promoting C&P reuse. And my response is that if these are the same (type of) object, then the manipulations (above represented by: o.z = o.x + O.y) will be the same, and so that code should be a method. The response will be that maybe in the other place, they need to be multiplied, not added. At which point, I say that they are not the same (type of) object, despite that they both have X,Y & Z components. And so, they shoudl not be merged into a single class.

Now that example is all far too abstract and trivial to make for a good case for my position. But it does demonstrate a point that if you design from the bottom up, attributes first, you will often conflate distinct objects because they are superficially similar in their internal data structure. They both have X, Y & Z components. But of you operate top down--then you probably wouldn't encapsulate such trivial data in the first place:)--but if you did then the object in one place would have an Add() method, and the other a Multiply() method. And you would not therefore conflate the two types.

Sure, you can probably get away with creating a hybrid class that has both methods. But then you have this complicated class that does more than either usage requires and so won't spot that actually they are two different classes each of which is actually only used in one place. And definitely won;t spot that actually, they are each so simple that they can each be lifted into their call site thereby making the code both simpler and more efficient.

Again, Ill say that this example is too trivial to make for a convincing argument. So, I'd ask you to outline one of these "data only objects" and its use. Preferably a real world example you have kicking around. Then I could attempt to make my case more strongly; and give you the opportunity to counter based upon real world usage rather than trivial abstract examples.

One of us might convince the other :)