Objects Without Behaviour

Question

I have a question related to general OOP than specific to a language. I was trying out a simple application (in java) and I was trying to model it like a real world scenario. Wh

Answer 1

Short answer:

is it a bad oo practice to have such objects

Not necessarily, but it depends on the context.

Longer answer:

I have a question related to general OOP than specific to a language. I was trying out a simple application (in java) and I was trying to model it like a real world scenario.

There really isn't any rule stating that you should. In fact, I know of quite a few people who frown upon that statement, Uncle Bob Martin for one. It's more about modelling business processes than it is to model "real world scenarios". I've tried that in the past, and found there's no - or almost no - benefit to get from rigidly trying to model everything as it is in the real world. If anything, I think it makes your application more complex, and the more complex software becomes, the harder it becomes to maintain.

While re-factoring I realized that I came up with a simple object that just has one member and an overridden equals and hashcode.

Might be okay, as @Arseny already said, the ValueObject is a well-known way of working, although I usually don't end up with a lot of them when I write code. If more than a few of your objects doesn't have any behaviour, this might be an indication of a so-called Anemic Domain Model, which you have to be careful for (more complexity at no apparent benefit).

You can find out if you're "doing it wrong" (with variable values of "wrong", of course): just see what the collaborators are doing with your ValueObject, and see if there's anything there that resembles a calculation which actually belongs to the object itself.

However, if this is one of the few objects that doesn't contain any behaviour: well, yeah, that happens and you probably don't have to worry about it. We'd have to see some code to be conclusive in our anwers though.

Answer 2

No it is not bad. There is Value Object pattern witch widely used and DTO pattern as well.

Answer 3

Normally, it would be considered a smell to have an object with no behaviour. The reason being that if it doesn't have any behaviour, then it isn't an object. When desiging your class you should be asking things like, "what is the class responsible for?". If it doesn't have any behaviour then this is a difficult questions to answer.

Rare exceptions to this being something like the Null Object pattern.

http://en.wikipedia.org/wiki/Null_Object_pattern

I may be that the member of your class should actually be a member of another class. It may also be that your class has some functionality that you haven't discovered yet. It may also be that you are putting too much importance on the concept when a primitive type would do.

There are a number of techniques for designing OO systems, here is one of the original: http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card

Answer 4

For this case, no, because that's the only way to redefine the behavior of an object in a hashing data structure in Java.

For other cases there may be better and worse methods of doing things depending on whether they make sense, for example, if I want to change the order of objects in a queue, I'd prefer to implement a custom Comparator rather than inherit and override a compareTo method, especially if my new comparison routine is not "natural" for the objects.

Every design pattern has some cases that it's appropriate for and others that it's inappropriate for.