4

Speaking in terms of object oriented design, do you think to give a functionality of saving itself into Data-base to an object spoils the COHESION of the class?

Imagine:

Product p = new Product() 
          {
           Name = "Joy Rider", 
           Price = 100, 
           Currency = "USD"
          };

Do you think to save this product p onto DataBase is better to be done in this way:

 p.Save();

or in a way something like this:

 ProductServices.SaveProduct(p);

What do you think?

pencilCake
  • 51,323
  • 85
  • 226
  • 363

3 Answers3

8

An object that can save itself to the database would violate SRP (Single responsibility principle).

Persistence is a responsibility all by itself and should be handled by dedicated classes.

This would be in addition to having LOW cohesion - the members that have to do with persistence have no relation to those that do not and would not be used in those methods of the class that do not deal with persistence.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • 1
    The OP does not go any further to describe what code or logic would exist in side `p.Save()`. So `p.Save()` might simply be something like `void Save(){ if (IsValid() && XXsomeOtherLogic()) _productService.SaveProduct(this); }` where `_productService` could be `IProductService` merely an interface injected to `Product` during construction. See Martin Fowler's discussion about exactly the OP's question, entitled, "AnemicDomainModel" https://martinfowler.com/bliki/AnemicDomainModel.html : In other words, I agree with @phillip 's answer. – snowcode Jul 01 '18 at 18:04
5

It does interfere with the single responsibility principle. The purpose of the Product class in your example is to represent a Product and the operations on that product. Interacting with the database is not a core part of the class' responsibility.

Having the ProductServices class increases the maintainability of your code. Suppose the logic for saving objects in the database was to change (which it can) do you want to change every entity class in your system?

Vincent Ramdhanie
  • 102,349
  • 23
  • 137
  • 192
3

In terms of Object Oriented Design only then no there is nothing wrong with the Save method being part of Product. It would actually be the preferred method within the Object Oriented Design world. And from a pure OO perspective you would not want it broken apart because that's more functional than object.

However, if you believe in the Dependency Inversion Principle which says high level modules should not depend upon low level modules; then a Save method would be appropriate but it should take an abstract Connection type as a parameter. This would give you an nice object model which includes a Save method but it would have no knowledge of the type of connection.

phillip
  • 2,618
  • 19
  • 22
  • burak - Do you want to know if there should be a Save method in Product? Or do you want to know if it should be moved to another class ProductServices? – phillip Dec 07 '10 at 15:55
  • If you are asking about the actual processing Save does in Product then Oded is correct and keep it DRY with SRP. But if you are asking if the method should be moved to ProductServices then that isn't a correct statement and should be discussed a little better. – phillip Dec 07 '10 at 15:58
  • Agree with @phillip and like the fact Phillip explains that the entity needs to take an abstract connection type, thus not coupling the domain entity to the connection : Martin Fowler has written about this exact question in his article enttitled "Anemic Domain Model" : https://martinfowler.com/bliki/AnemicDomainModel.html – snowcode Jul 01 '18 at 18:09