Where should my method go

Question

I have a class that represents a row in a table. I want to add a function that manipulate the data in the row. Where should I add the function?

1) inside the class because it is related to the class 2) outside the class in a separate helper class?

In the past I would have always picked number 1. I am starting to think that number 2 is a better answer, because it separates out logic into its own encapsulated class and reduces complexity of the data class. I am thinking the data class should be left as bare as possible and just contain data members with absolutely no logic.

What is the most agile/best way to do this?

Answer 1

it depends on if you prefer more of an "active record", or a "repository". I'm not sure there is really a right answer, just what makes sense in your codebase. I would also consider the design of the rest of the code in how you design this as consistency is just as important as good design.

Answer 2

In a pure MVC sense, Number 2 is your best bet. Create a data model and leave it as is free from all implementation logic. This will allow you to potentially re-use the model across applications. The Controller can then house the application-specific implementation logic that manipulates the data.

Answer 3

Depends on what the function is. The point of a class is to encapsulate functions and data, generally.

If the function is specific to the type of data held in the row class, and the row class is general, then you could subclass from the row and stick the function there.

a helper class is useful for breaking down the complexity of a class, but you should make sure the role of the helper vs the class are clearly defined such that future maintenance doesn't muddy that contract.

Answer 4

The correct answer is "it depends"; "manipulat[ing] the data in the row" can justify either answer.

In terms of separation of concerns, you need to identify what abstraction this function manipulates. Is it the abstraction of a row in the database? Put it in that class. Is it the object in your data model that is implemented in terms of a row in the database? Put it in that class.

More generally speaking, you should put functions at the level of abstraction to which they apply, which is very much dependent on your overall design.

Answer 5

The Single Responsibility Principle has been stated as "There should only be one reason for an object to change." With your option 1, there are two reasons the object could change: you could change what data is stored in the object, or you could change to a different database system (e.g. mySQL to PostgrSQL).

Of course, like everything, it's a trade-off. There's some benefit to having all the code in one place. If it's unlikely that you'll switch to a different RDBMS in the future, then combining everything into one class might be a good call.

But if you do anticipate switching to a different database in the future -- or even supporting multiple database backends -- then you'll probably be better off putting persistence in a separate class.