preface
Section on object-oriented design thoughts.
Everyone who enters must abide by its rules. Since we belong to an “object oriented” party, we must embrace some of these values:
- Everything is an object, and objects have classes
- Relationships drive the world
- All things change and remain unchanged
Everything is an object, and objects have classes
In the object-oriented world, everything can be abstracted into an object, such as a rose, a ginkgo tree, a woodpecker, a Siberian tiger, everything can be abstracted into: what is, what is, what can be done; Then further, we can abstract, encapsulate, and then boil down to the category — flowers, trees, birds and animals.
Abstract is the perspective from which we see things, helping us to extricate ourselves from the complicated details, and to understand a thing in a higher level of a way of thinking.
Encapsulation is from the perspective of the transaction itself, hiding the details as much as possible and exposing only the capabilities that need to be exposed. Cell phones, for example, simply reveal the ability to make a call without the need for the outside world to know the details of how the action is done.
These two object-oriented features are fundamental to our understanding of object orientation, and we use them everywhere as we map everything to our code world.
Relationships drive the world
When we try to single something out, we find that it is related to everything else in the universe. Samuel Muir, 1911, “SUMMER in the mountains”
There is nothing in the world that can exist independently of anything else, and it also maps to our code world. After abstracting things into objects/classes, all we have to do is find relationships between them.
Looking at the picture above, we can find many relationships:
- Inheritance relationships between classes and subclasses.
- Overloading/overriding relationships between methods.
- Abstract – concrete relationships between classes and objects
- Various combinations of dependencies between objects/classes… * * relationship
Inheritance and polymorphism
Among them about the class, there is a basic relationship, that is inheritance – inherit the father, carry forward.
Inheritance allows us to acquire some basic abilities from the same kind of things, and at the same time extend them.
In general, the relationship between inherited subclasses and superclasses is between special (special) and general (abstract). For example, a bird is a kind of animal. It has the characteristics and abilities of animals, and also has its own unique characteristics and abilities:
In addition, if you are careful, you can see that we have overridden the “activity ()” method of the parent animal in the bird subclass. This override gives our inheritance relationship a higher level of capability – (runtime) polymorphism. The so-called polymorphism is simply understood as dynamic decision – making. A thing can exist in many forms, all of which can respond to a particular event, depending on the circumstances of the runtime.
What’s the good of that? The biggest benefit is the separation of “what to do” and “how to do it “, separating the interface from the implementation. Let our program has a great expansion, in fact, many design patterns are based on the object-oriented characteristics of the precipitation of polymorphism.
Another type of compile-time polymorphism is the overloading of methods in the same class-methods with the same name, different arguments passed in, and different things to do.
Six types of relationships
Of course, our class relationship, in addition to inheritance, there are many other forms of relationship, colorful relationship can build our colorful world.
When we talk about class relationships, we often use UML class diagrams. UML is a universal Modeling Language, full name Unified Modeling Language, which is a visual specification Language for software Modeling. Because of its influence in the industry, it has gradually become a modeling design language standard. GoF design pattern diagrams are also umL-based, so it is important to understand the UML class representation.
In general, class relationships are divided into six types, described and expressed in UML as follows:
Let’s look at a practical example:
From the point of view of our software design, the weaker the relationship is, the better it must be. Only the weak relationship can be loosely coupled. So there are also things that we often hear about composition over inheritance.
All things change and remain unchanged
The only constant is change itself, Spence. Johnson “Who Moved My Cheese?”
Movement is absolute while stillness is relative. All people, things, things and relationships in life are constantly changing. Similarly, the software world will always face changes, and how our programs can cope with those changes with minimal cost – that’s what object oriented design is all about.
You are welcome to follow my wechat account @Bianyuelmj.
