I always thought: why people write this very long posts? Here you have it.
How do I design my objects? What is the set of constraints that dictate my design decisions? People talk about objects in very different contexts. A certain amount of confusion derives from not identifying the contexts for our objects.
First, kings of them all, there are business objects. My library is full of OO books that describe how to design these guys. We have patterns and anti-patterns. Everybody is out there promoting their own methodology. But if we go deep enough, the most important design task in creating them is assigning responsibilities. This concept is as old as OO itself; it finds its roots in CRC cards. But I digress. Once again, when you design your business objects you have to be very careful to assign responsibilities to the objects that have the right information to perform them.
It would be nice if this was all you have to code. A crazy bigot (like me) would think that all the rest is infrastructure (ala naked objects). But we live in the real world, so let's get down to it.
A second category of objects I often encounter are network objects. These are the guys you use to communicate data across tiers (logical, physical, webservices). They are usually quite dumb objects, not too much logic in them (if any), and your application creates them by filling their properties from the more noble business objects. Something along the line of the value object pattern. Is assigning responsibilities a very important task here? Heck no!! They don't even have methods!! The most important characteristic they have is bandwidth optimization; you want to retrieve a whole bunch of stuff in one single round trip. More often than not you sacrifice everything else (manageability, good design) to achieve that.
This is why I don't believe the quite common ideal of remoting your business objects. The set of constraints you use to design them is completely different (often opposite) to the constraints needed to go over the wire. When anything goes over the wire it becomes just data. Moreover not all of your business state needs to go on the network, but this is another story
Another common object category is database objects. There is a big debate if they are the same as business objects or not. I dont' want to go there, but If you want them to be the same you usually pragmatically sacrifice a bit of OO purity to make them more similar to the database tables (you don't want to fight your object relational mapping layer, you want to help it out). To say this in a more positive way, you design your domain model with an eye on how you are going to persist it. If, on the other end, you are willing to create a separate set of objects to represent data coming from the database, then the main constraint for these guys is the same as your database tables: normalization. This is not surprising as they are mirrors of your database. Again assigning responsibilities and being network friendly take the back seat in this case.
There are many other object categories I often found useful (i.e. façade objects). I don't want to discuss all of them here. Things are already boring as they are. The central point is that it is very hard to define generic guidelines that work well in all the different contexts. You got to think about your context first.
The funny thing is that I work in a place where we are supposed to design features that are generically interesting in all these scenarios. You use C# to code all of them. Oh well, design is the art of choosing trade offs