Object-Oriented Programming - OO Thought

Professor Zhou Ligong's years of hard work "Programming and Data Structure" and "Programming for AMetal Framework and Interface (I)", the electronic version has been distributed to electronic engineers and college groups for free, after the content of the book is published, in electronic The industry has set off a learning boom. Authorized by Professor Zhou Ligong, this public number has serialized the contents of the book "Programming and Data Structure" and is willing to share it.

The fourth chapter is object-oriented programming . This article is 4.1 OO thinking .

Chapter IV Guide

Process-Oriented Programming (POP) is a process-centric programming idea that focuses on what is happening and guides developers to use algorithms as basic building blocks to build complex systems.

Object-Oriented Programming (OOP) uses classes and objects as basic building blocks to guide developers in exploring the expressiveness of object-based and object-oriented programming languages. Therefore, when decomposing the system, either start with the algorithm or start with the object, and then use the obtained structure as a framework to build the system.

> > >    4.1 OO thinking

> > >    4.1.1 Transfer of duties

1. Limitation of the human brain

Due to the influence of computer information processing functions, cognitive psychology based on information processing theory was produced in the early 1960s. The research achievements of American psychologist George Miller in information memory provide theoretical evidence for emerging cognitive psychology.

Although the psychologists at that time had roughly divided the process of information processing into sensory memory (less than 2 seconds), short-term memory (less than 15 seconds) and long-term memory, the nature and importance of short-term memory is It was only after George Miller published the research report "Magic Number 7 +/- 2, Limitation of Our Information Processing Capability" in 1956, that is, Miller Magic - humans can only remember and deal with 7 plus or minus 2 items.

Subsequent evidence suggests that the base may be as few as three or four, a figure that represents the amount of information that the brain's "scratchpad" can hold when solving problems. Regardless of the actual number, if you ask the average person to consider about 15 things at the same time, you can actually only remember and deal with 9 or even less.

If more things are required to be processed, only a few pieces can be processed at the same time, and others will be quickly cut into or out of the scratchpad. Think about buying 15 things in the store. If you don't have a shopping list, you are likely to miss something or buy something incorrectly. By the same token, if there are thousands of things in the list of requirements or in the list of products, then your brain can't handle such complicated things at all, unless it is broken down into smaller structured groups.

2, core and non-core domains

A software system encapsulates knowledge in several fields. One domain knowledge represents the core competitiveness of the system. This domain is called the “core domain” and the other domain is called the “non-core domain”. Although the more popular terms are "business" and "technology," the use of "core domains" and "non-core domains" is more rigorous.

Non-core domains are areas of others, such as the underlying drivers, operating systems, and components. Even if you have some advantages, it is temporary, and competitors can get it through other channels. Improvements in non-core domains are necessary, but not sufficient, and they need to be dig deeper into the core domain so that competitors cannot easily obtain it from third parties. Because of the deep digging in the core domain and the core domain-based reuse, this is the fundamental means of gaining and maintaining competitiveness.

To achieve core domain-based reuse, it is necessary to consider the core domain and the non-core domain separately. Because the capacity of the human brain is limited, and prematurely mixing knowledge in various fields increases the unnecessary burden, which leads developers to think less deeply about the deeper problems in the core domain.

Because the capacity and computing power of the human brain is limited, once the scale of the problem to be solved becomes larger, it must be divided and ruled because the knowledge of the core domain and the non-core domain are independent. For example, a calculator has no holes, and the problems are complicated. If you do not use statecharts to explicitly model the domain logic, then map to the implementation based on the model. Instead, I started programming directly, and the knowledge of domain logic relied on temporary thinking. The resulting code was definitely flawed. In fact, there are profitable systems, the internals are very complicated, and do not naively think that "my system is not complicated."

3. Transfer of duties

In process-oriented programming, because the main program takes on too many responsibilities, to ensure that everything works correctly, and to coordinate the functions and control their order, it often produces very complicated code. Change is inevitable in many cases, and functional decomposition cannot cope with possible changes. Once the code is modified, there are more and more bugs. More importantly, because the human brain can't do too much complicated processing, memory and understanding are limited. Therefore, in the face of complex software development, the main program can not do too many things, you must carry out the job transfer responsibility by "separating concerns."

Suppose you want to take a taxi to the airport. One way is to tell the driver to go to the airport according to a separate interface such as "start, turn right, turn left, stop". This way requires passengers to be responsible for their actions, and passengers know the route each city goes to the airport.

Since the user's needs are always changing, we will not be able to stop the change. Instead of complaining about changes, it's better to change the development process to respond more effectively to changes. Object-oriented programming is what this means as a means of combating software complexity.

Another way to do object-oriented programming is to tell the driver, "Please take me to the airport." Although the specific implementation is different in different cities such as Guangzhou, Beijing or Shanghai, it can be said in any city. Because the driver knows how to get to the airport, the driver is responsible for his actions and trusts the driver to know how to perform. This is the transfer of duties. Obviously this method is much easier than the functional decomposition method.

Since each object is responsible for its own behavior, there must be a way to tell the object what to do. The methods are all identified as being able to be called by other objects, and the collection of these methods is called the public interface of the object. The analogy of its image is, "Looking at a software object as someone with a certain responsibility, he has to work with others to get the job done."

> > > 4.1.2 OO mechanism

Object-oriented programming is implemented by a structure of classes, and the concept of C++ classes is an extension of the concept of C structures. So on the surface it seems that these features have a lot to do with object-oriented programming languages, but can actually be implemented in any language. Regardless of the language implementation, any large software system uses abstraction, inheritance, or polymorphism in some form.

1, the package

Encapsulation is an important principle in the OO method. Its meaning is to regard the encapsulation as any form of concealment, forming a boundary externally and exposing only a limited external interface to connect with the outside. Encapsulation not only combines all the attributes of an object with all operations, forms an inseparable independent unit (object), but discovers changes to encapsulate it.

Abstract implementations that encapsulate the analysis tools, abstractions allow us to focus on the most essential aspects of the application while ignoring the details. What are the objects of interest before deciding how to implement the functionality? What have you done? More specifically, abstraction is the process of summarizing the common features of a class of objects to create classes, including data abstractions and behavioral abstractions.

Data abstraction is a combination of data and processing methods, that is, the ability to encapsulate data and functions into classes. Therefore, data abstraction is called information hiding or encapsulation. Information hiding is a software design idea. Since you don't have to know the internal structure, you can manipulate the data as a black box. Even if the data structure changes in the future, it has no effect on the outside. This prevents the various components of the program from being too interdependent, otherwise small changes can cause huge chain reactions.

In a structured design, code is usually packaged into functions and modules. Therefore, encapsulation is not unique to the OO language, but it can organize data structures and behaviors in an entity. Its main purpose is to provide a consistent interface for programmers who use code. This is a prominent feature of object-oriented programming. Still, object-oriented and structured code is not mutually exclusive, and you won't be able to create objects without structured code. Therefore, when constructing an object-oriented system, structured technology is still indispensable in design.

2, inheritance

While structured programming is reused by writing a function block, the way object-oriented programming implements code reuse is to allow relationships between classes to be defined. Inheritance is the primary means of implementing this functionality, extracting the same parts of different code. That is, extracting common attributes and behaviors of different classes to create entirely new classes, maximizing code reuse.

Using the two characteristics of class and inheritance, the abstract data is efficiently encapsulated by the class, that is, the same class object is managed by the class. So it can be said that a class is a tool that black-boxes data, and inheritance can inherit properties from other classes. It only needs to extend the implementation or slightly improve the implementation to support software reuse.

In the classic Shape example, Circle, Square, and Star all inherit directly from Shape, a relationship commonly referred to as an is-a relationship. Because a circle is a shape, a rectangle is also a shape, and a star is also a shape, that is, Circle, Square, and Star are both extensions of Shape. When a subclass inherits from a parent class, any subclass that the parent class can do can do it.

3. Polymorphism

When you ask someone to draw a shape Shape, no one actually can complete the task. Because shape is an abstract concept, Shape cannot provide drawing code and must specify a specific shape. With a specific shape, you can implement your own drawing code for a variety of specific shapes.

Obviously, no matter what shape is drawn, the commonality is the Draw drawing method. Each shape can draw its own drawing code through the function pointer. This is the meaning of polymorphism, that is, polymorphism allows the same method (code) to run. In the process, different handler functions are called depending on the type of the object.

4, combination

Combining refers to including an object in a class, and the object is an instance of another class, and the developer delegates responsibility to the completed object. There are two ways to combine: aggregation and composition, which represent the collaborative relationship between objects.

Aggregation means "gathering and dispersing", and the contained object is like a collection. The aggregation relationship is a relationship between the whole and the part, and the part can exist separately from the whole. Although the car and the engine are integral and partial, the engine can still exist without the car, so the car and the engine are in a polymeric relationship.

Although the combination relationship is also a kind of whole and partial aggregation of some form, the part cannot exist separately and exists separately, and some objects have a co-death relationship with the whole object. In the combined relationship, the part is a part of the whole, and the whole can control the life cycle of the part, that is, the existence of the part depends on the whole.

Although the petal is not a flower, it is part of the flower, so there is a true has-a combination between them, and there is no father-son relationship. Similarly, the head is made up of eyes, mouth, nose and ears. If the head does not exist, these parts cannot exist alone.

> > > 4.1.3 OO income

Coupling and cohesion are complementary. Cohesion describes the closeness of the interconnection between the internal components of a module, while coupling describes the closeness of the connection between a module and other modules. It can be seen that no matter which method is used, the goal of software development is to create modules that conform to "high cohesion, low coupling". That is, each module performs a specific function as independently as possible.

If the modules are low-coupled, modifying one module does not require modifying the other. The most important point of using modularity is the ability to modify individual modules independently without modifying other modules of the system. A typical mistake is to use a tightly coupled approach to integrate between modules so that modifications to one module can result in modifications by their consumers. A low-coupling module should know as little as possible about the information of the modules it works with, ie it should limit the number of different calling forms between the two modules, because in addition to potential performance issues, excessive communication can cause tight coupling.

Cohesion is used to assess the functional relevance of members in a component (package, module, or accessory). A high degree of cohesion indicates that each member has completed a functional characteristic or a set of functional characteristics. A low degree of cohesion indicates that each member provides The functions are irrelevant. A class is cohesive if its methods and properties work together to perform a function or a series of closely related functions. Suppose there is one such class that implements three completely different functions. If the details of the requirements for these three functions change, the class must also change, resulting in more development and maintenance costs. So high cohesion is to bring together related behaviors and put irrelevant behaviors elsewhere. The advantage of this is that if you want to modify an action, you can modify it in one place and publish it as soon as possible.