Should methods be part of your persisted entities?

Question

We are coding a small game and have a Player class. This Player class has certain properties which you would persist in a database like Id, Level, Health.

We would like a Player to be able to kill another Player. For this we need a method which reduces the Health of the Player.

To accomplish this do we:

• Create a method on the Player entity called DealDamage(Player to)?
• Create a separate class which we do not persist in the database called WorldObject with a method DealDamage(WorldObject to) which is inherited by the Player class? The list of methods might become very large at a point. In which application layer do we put this class?
• Create a separate class which we do not persist in the database called DamageController with a method DealDamage(Player from, Player to) and split up the logic across different controllers? This will probably become confusing?
• ...

The thought of not having methods on persisted entities seems attractive to me since it sounds like you are splitting up the business logic from the data layer logic. But can and should it be done?

Answer 1

While there are some schools of thought about Object orientation which insist in combining data entities with logic to align classes with physical entities, this is by no means a guideline that you should follow unless you truly believe it's the best solution to your particular problem (That approach may naturally lend itself to some problems, but frequently causes more problems than it solves if just followed blindly). There are other schools of thought which emphasise clean separation of concerns, and prioritise 'SOLID Principles' instead.

Physical entities as classes is a valid outlook on class design, but is also extremely constraining and only provides a narrow perspective which doesn't resolve issues about how classes might interact with each other, how to test them, or what happens when behavioural logic could involve multiple physical entities. Nor does it necessarily consider the way that software naturally changes and evolves over time as its requirements change or issues are discovered in the original implementation.

It's important to keep in mind the goals of object orientation rather than treating it as a set of rules to be followed. Broadly, the goals are about grouping logically-related behaviour (methods) into classes, keeping clean separation between different unrelated classes/behaviour. The extent to which you decide to do that is up to you, but you can often make a lot of decisions based on whether something 'feels' helpful in the way you structure your program.

If something doesn't feel helpful, or it seems counter-productive, or leads to code which feels 'messy' and unnecessarily complex, then that should be enough reason not to do it. Instead consider the practical implications such as whether it makes your code easier to unit-test or whether the rationale for your code structure would be immediately obvious to other developers who are trying to reason over your code. Consider principles such as KISS, DRY and YAGNI.

It seems extremely unlikely that any core business/application logic would ever need to care about the specifics of CRUD operations relating to a data store, so it would seem rather odd to have the DealDamage method in the same class as a Save or Read method; plain common-sense dictates that these things should probably be unrelated.

For example, your DealDamage method probably isn't going to behave differently if the data happens to be stored in a SQL database compared with being stored in a Flat file or NoSQL store, so from a logical/semantic point of view it makes sense to keep them separated. Furthermore, if your DealDamage method does behave differently depending on those things, it might be an indicator of a possible problem in your design, or a problem with the way your requirements are specified.

There's absolutely nothing wrong in Object-oriented programming with creating plain 'entity' models whose purpose is merely to hold data which has been retrieved from a database. Nor is there anything wrong with creating stateless behavioural classes which have no data of their own and operate entirely on those entity models, in fact such a design is fairly typical in a Layered Architecture, and even necessary if you happen to be building a system based on a Microservices Architecture.

Naturally, it depends upon your requirements as to whether you need or would benefit from one of those architectural styles. In general, any kind of very small or trivial app may not get much benefit from the clean separation of concerns that you'd get from a more complex design, and you can get code working fairly quickly with the Just Do It approach which tends to ignore any wider concerns about design/architecture or possible future change.

More complex designs are intended to solve a multitude of problems that people typically associate with larger systems whose requirements are more complex and ever changing. Particularly where the complexity of those systems would make them difficult to reliably test or change as a monolith. The separation between layers/modules/subsystems allows those different components to be developed in isolation, more easily reused by other systems, more flexible/scaleable to meet future requirements, and easier for other developers to reason about.

Answer 2

Lets coin some terms.

If you put your methods on the same object as your data then you are doing classic Object Orientated Programming (OOP). If you have no methods on your data objects and instead put them on Service classes, such as your DamageController, to which you pass the data objects then, this is often called Anaemic Domain Model (ADM).

Personally I find ADM an attractive approach for things like web services, worker processes or anything that's summed up as a business work flow.

If I have an Order object I might have a dozen different things you could do to it at different points in its lifecycle, but in any given program I am probably applying the same single process to a never ending stream of orders.

On the other hand, If I'm writing an Application where we have a number of persistent things such as a computer game with a dozen enemies on screen. I find OOP more attractive.

I will want to do several unpredictable things to the objects over their life cycle and in the code that does those things I might not have access to the service I would need. Its easier to put the Methods on the object. move the character, shoot its weapon, play the animation etc etc

However, I still want to avoid deep inheritance chains and this can be achieved by injecting the services into the Object and using composition ie.

public class Character
{
    private IPathFinder pathFinder;
    public void MoveTo(x,y)
    {
       var route = this.pathFinder.FindRouteTo(x,y);
       this.target = route.NextWaypoint();
    }
}

I'll still use a bit of Inheritance, such as Player : Character, Enemy : Character, but I have an option to prevent needing to go back too far.