Return to Answer

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, e.g. in C#

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.

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.

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 e.g. Linq, to do

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.

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, e.g. in C#

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.

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 e.g. Linq, to do

personlist.Average(p => p.Height);

and then the logic is not in Person even statically. Indeed higher order functions 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.

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 e.g. Linq, to do

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.