In the previous debate about anemia or congestion, TX proposed this idea book. save () is very strange to use. Some people think that this is not enough, because it is not the behavior of books, but the Book Administrator: bookmanager to make it more reasonable. Here I will talk about my opinion, or Oo, and continue to answer the bricks.
First, my opinion is that whether book. Save () is in line with the OO spirit, the key is to see how to use it. For example. If book. Save () appears in editbook. aspx. CS, I think it is not in line with the OO design philosophy, because the behavior of saving books is indeed not what the book itself was. However, if there is a user-class user and there is an updatebook method in the user, the book appears in this method. save (), so I think this is very Oo, because the behavior of saving books after modification is indeed sent by the user. However, some may ask, why not read the book attribute directly to generate an SQL statement to update the database (that is, the bookmanager practice, which I do not agree? It is very simple. According to the OO encapsulation principle, the book-class instance must change its status by itself, therefore, we need to change the book state (not the persistent state to the persistent State) for the attributes of the persistent book. If it is done by bookmanager, The encapsulation of the book class is damaged, naturally, it is not oo.
So whether or not oo depends on whether the idea you used in the design follows the OO principle, rather than on a certain line.Code, Book. Save () can be oo or not Oo, where the anemia model is not Oo, the event sequence initiator is handed over to the service, thus undermining the encapsulation of the class.
After the demonstration is completed, I am very grateful to you for writing it very short because it is about to get off work.