See the hands-on Series-object-oriented literacy-the popular oo first bullet-[encapsulation]

There have been too many discussions on OO recently, too many misunderstandings, and too many misunderstandings. Let me solve the problem of object orientation at one time. This is the first article.

Object-Oriented Programming, design, and ideas. We use big vernacular.

Object-oriented means describing something (object), what is (class), what is (Object State), and what can be done (method ).Program. This is object-oriented.

The characteristics and encapsulation of an object-oriented program: the change of the state of something must be based on its own behavior.

For example, I (human), I have money (what is there), you (human), and I want to borrow money (what can I do ). Therefore

Class man ()
{
Private int money;
Public int money
{
Get {return money}
Set {money = value}
}
Public void borrow (man target, int howmuch)
{
Money + = howmuch;
Target. Money-= howmuch;
}
}
This is what it looks like. This statement is incorrect, which destroys the encapsulation of the class. We bypassed the man object and directly operated on the object state. This is completely a bandit logic, just as unforgivable as saving money in my wallet. Therefore, you need to borrow money from me, and I want to lend you money. Let's modify Code . We add a lend method to the man class to encapsulate the change in its status when lending money. Then the behavior of borrowing money will be changed.
Class man ()
{
Private int money;
Public int money
{
Get {return money}
Set {money = value}
}
Public bool lend (INT howmuch)
{
If (howmuch <money)
{
Money-= howmuch;
Return true;
} Else
{
Return false;
}
}
Public void borrow (man target, int howmuch)
{
Money + = howmuch;
Target. Lend (howmuch );
}
}
This code satisfies the encapsulation principle. Note that encapsulation is both a feature and a condition that must be met. If the encapsulation principle is broken, the OO principle is broken.

Here we return to a very practical question: Why is the blood loss model not OO.
We have defined the book class and encapsulated the book state (attribute ). If we use a bookmanager class to save this book (typical out-of-school mode ). So how do we save it in bookmanager? Many people read the book attributes in bookmanager. Save, generate SQL statements, write databases, and return execution results. So OO? Not Oo, because this approach completely undermines the encapsulation principle. Just like the example of borrowing money. Therefore, we need to add a save method in the book class, which is used to maintain the state of the book class itself. Many ORM can also inject this type of method into our classes, so that our classes can be persistent. In this way, the attributes of the book, How to store it in the database, how to read it, and how to delete it are the responsibility of the book itself, because the records on the book in the database are in the book state, therefore, books must be encapsulated to make them transparent.

Many people mentioned in the previous topic about whether book. Save is oo. They thought that the book. Save method only changed the location. But where I know it, this small change is a matter of principle. As for Pisces, the context parameter added to save is more in line with the actual situation. I personally think that addition and absence of context does not have much impact on whether the book class conforms to the OO principle.
But there is a world of difference.

Encapsulation is an important design principle to ensure high cohesion and low coupling of the system.
Use book as an example. If your book needs to add an attribute to indicate a new State (in other words, you add columns to the database and the database changes ). If your book class maintains its own Persistence State, you only need to modify the method of the book class Persistence State. If you use vs2005, you can use the refactoring function to modify all the affected items at a time (Java eclipse also has the same function ). If it is not encapsulated. You may need to change the bookmanager. If you still use the book elsewhere, there may be countless codes waiting for you to change. Why is it troublesome? Because there is no encapsulation, coupling occurs between classes.

In the next chapter, we will talk about inheritance (including the implement of interfaces)