Should entities have behavior or not?

Question

Should entities have behavior? or not?

Why or why not?

If not, does that violate Encapsulation?

Answer 1

Entities should not have behavior. They represent data and data itself is passive. I am currently working on a legacy project that has included behavior in entities and it is a nightmare, code that no one wants to touch.

You can read more on my blog post: Object-Oriented Anti-Pattern - Data Objects with Behavior .

[Preview] Object-Oriented Anti-Pattern - Data Objects with Behavior:

---

Attributes and Behavior

Objects are made up of attributes and behavior but Data Objects by definition represent only data and hence can have only attributes. Books, Movies, Files, even IO Streams do not have behavior. A book has a title but it does not know how to read. A movie has actors but it does not know how to play. A file has content but it does not know how to delete. A stream has content but it does not know how to open/close or stop. These are all examples of Data Objects that have attributes but do not have behavior. As such, they should be treated as dumb data objects and we as software engineers should not force behavior upon them.

---

Passing Around Data Instead of Behavior

Data Objects are moved around through different execution environments but behavior should be encapsulated and is usually pertinent only to one environment. In any application data is passed around, parsed, manipulated, persisted, retrieved, serialized, deserialized, and so on. An entity for example usually passes from the hibernate layer, to the service layer, to the frontend layer, and back again. In a distributed system it might pass through several pipes, queues, caches and end up in a new execution context. Attributes can apply to all three layers, but particular behavior such as save, parse, serialize only make sense in individual layers. Therefore, adding behavior to data objects violates encapsulation, modularization and even security principles.

---

Code written like this:

book.Write();  
book.Print();   
book.Publish();  
book.Buy();  
book.Open();   
book.Read();  
book.Highlight();  
book.Bookmark();  
book.GetRelatedBooks();   

can be refactored like so:

Book book = author.WriteBook();  
printer.Print(book);  
publisher.Publish(book);  
customer.Buy(book);  
  
reader = new BookReader();   
  
reader.Open(Book);   
  
reader.Read();  
reader.Highlight();  
reader.Bookmark();  
  
librarian.GetRelatedBooks(book);  

What a difference natural object-oriented modeling can make! We went from a single monstrous Book class to six separate classes, each of them responsible for their own individual behavior.

This makes the code:

• easier to read and understand because it is more natural
• easier to update because the functionality is contained in smaller encapsulated classes
• more flexible because we can easily substitute one or more of the six individual classes with overridden versions.
• easier to test because the functionality is separated, and easier to mock