Delphi Object-oriented learning essay five: a real class

Bahamut
(Please specify and remain intact)
Written in the previous words:
This note is entirely my personal subjective point of view, please correct me if there is an error ^_^
Definition of the class:
First of all, I want to say that classes are not simply "patchwork" of variables and functions. A class should be an abstract description of a thing, not an abstract description of an action. What do you say?
For example: Shoes is a thing, we can abstract its characteristics, and use computer language to describe it as a class, and shoes are divided into sandals, shoes, etc., then "sandals" and "shoes" is the "shoes" derived class. They seem to be very natural.
So, now that I have another class, the Initialize database class, this class looks very awkward, because it looks more like an action. This "Initialize database" class is more like an "Initialize database" method in other classes.
Issues to be noted in writing classes:
a, as far as possible, restrict the accessibility of members of a class: When you are unsure whether a method should be public, you should first consider defining it as a private method.
two, try to avoid exposing the details of the implementation without concern: for example, the engine principle of the car is not required to drive the car driver know.
threeand maintain the independence and robustness of the class itself, there should be no presumption or compulsion on the user of the class: for example, if you write a class whose property cannot be negative, you should explicitly handle negative values within the class and give appropriate error handling, rather than writing "{After creating the class, Initialize the XX attribute to a positive number, and the class will crash if it is initialized to a negative number, "this will push the responsibility to the user's declaration."
Four, making code reading easier than writing: Because code reads more times than you write.
Five, as much as possible, to reduce the degree of coupling between classes and classes: Unless there is a class that contains a relationship, if it is an equal relationship, the method in the class should be avoided depending on the property or method in the other class.
How to deal with problems when you meet them:
Suppose, we have a base class of "birds" (Tbird), there is a universal method of "Fly" in the class. And for this class derived some subclass "seagull" (tgull) and so on, these seem to be quite normal, but when we define "ostrich" (Tostrich), found that the ostrich is not actually fly, but he ran quickly, then someone will simply cover the base class (Fly) method, Do not give the implementation, but add another run method.
This is actually not good, of course, I do not want to let everyone in the future to make a prediction, I would like to say, in the discovery of the parent class and subclass in a method of conflict, we should start from the source, I think a better solution is:
Change the fly method in the base class Tbird to the Doaction (action) method, and specify the abstract method, then add two derived classes Tflybird (Flying Birds) and Trunbird (running birds).
The Tflybird class covers the Doaction method to achieve the "Fly" action, and add the public method fly, in the fly call Doaction to achieve "flying" this method;
Override the Doaction method in the Trunbird class to implement the "Run" action, and add the public method run, calling Doaction in run to implement the "Run" method.
Then change the parent class such as Tgull with Fly method (that is, flying bird) to Tflybird, change Tostrich, etc. without fly (that is, the running bird) of the parent class is Trunbird.
So, even if one day we find a swimming bird, then we just need to derive a tswimbird (swimming bird) subclass for the Tbird class and add a public method swim let it call doaction to implement the "swim" method.
Of course, my approach is not the best, but I think it would be better to handle it directly in a derived class.

Delphi Object-oriented learning essay five: a real class