Say I have a class Person that has instance variables age, weight, and height, and another class Fruit that has instance variables sugarContent and texture. The Person class has no methods save setters and getters, while the Fruit class has both setters and getters and logic methods like calculateSweetness. Is the Fruit class the type of class that is better practice than the Person class. What I mean by this is that the Person class seems like it doesn’t have much purpose; it exists solely to organize data, while the Fruit class organizes data and actually contains methods for logic.
3
If your person is actually not doing anything, then there is no need to have any actions on it. It is possible to have classes which only collects data and then there will be classes which operates on this data. In your case, it may be possible that you do not have any action on single person, but there may be action on group of persons, like CalculateAverageHeight(). In this case it makes sense to have only Person without action and then have another class (may be friend) which works on this.
2
It is difficult to come with a rule saying all classes must have some logic. In general classes without any logic are considered to be AnemicDomainModel.
Even then, it is better to organize data if the related information is getting large. For example in this case you may still need a collection of Person than many unrelated collections.
6
The DataTransferObject is a good example of a class that has no logic, only data. That’s its purpose, though; it’s explicitly an exception to the general rule that all classes should implement the business logic that affects their internal state. Having a class whose internal state is changed by external logic is often a design smell. It’s not always wrong, but it’s almost always something that you should consider refactoring.
Reverse the question, look at the other end. If you have a collection of information that obviously belongs together, should you keep it apart just because there are no methods which you could add to that class? Should you be forced to invent arbitrary methods just to justify the class?
Models are no end to themselves – you should add functionalities to a class when you really need them in your program, not on guessing that you will need them probably in the future. So its natural that at one point in time you have classes with no “real” methods, and later, when you determine that it makes sense to add methods to the class, you do exactly that. The quality of a model is not measured by “do I have methods here and no methods there” – the quality is measured by “do I have all the methods my application actually needs in there”.
For example, when your application in version 1.0 needs something like calculateSweetness for a Fruit, but does no operations on a Person except getting and setting the attributes, then your model should exactly reflect that by not having any logic in the class Person. In version 2.0, it may make sense to add some logic to a Person too, so when you are at that point, add the methods in question.
I think this depend on the language and how you are using the language.
In the trivial case some languages insist on everything being in a class, so e.g. collections of constants have to go into a class which then may or may not have any logic, in other languages they might end up in a namespace instead.
In multi-paradigm languages it can also depend on what paradigm you want your design to adhere to. Borrowing the example of CalculateAverageHeight(), as is it probably should reside in a PersonCollection class, however that presupposes an OOP solution. in a more Functional design you might use a higher order function with a generic collection, e.g. in C#
List<Person> personList = GetListOfPeople();
personlist.Average(p => p.Height);
and then the logic is not in PersonCollection or even statically in Person. Indeed higher order functions and generic data types in general mean you are more likely to end up with objects that are just bags of data, as the logic is operating at a higher level of abstraction then your specific data model.
It sounds like what you are talking about is a POD (plain old data). Different languages can represent these in different ways – it could be a class with public members for instance, or a struct with only public members in C++.
Organising data is a perfectly valid reason for a class to exist – it can often make code cleaner and easier to read. std::pair in C++’s STL is a good example of a structure that exists solely to organise data – simply a struct that holds two values of any type named first and second. Probably one the most useful classes in the entire STL (in my opinion anyways 🙂 )