Pairwork-programming of elevator dispatch program pair

1 Pair Programming

　　1.1 Advantages and Disadvantages of Pair Programming

Advantages:

Compared with independent development, pairing helps people maintain a better state under pressure. Pair Programming encourages both parties to maintain the high quality of the Code, even when there is a pressure that people have to write code quickly.

It can improve code quality. Code readability and comprehensibility tend to rise to the level of the best programmers in the team

It can shorten the schedule. A pair can usually write code faster, with fewer code errors. In this way, the project team will spend less time correcting defects later in the project.

Disadvantages:

Programmers who have different habits can work together, which may cause troubles or even conflicts.

When two people work together, they may be unable to concentrate. Programmers may talk about work-independent things, but they are distracted, resulting in lower efficiency than single users.

It may give some people the opportunity to initiate a flood of attacks.

 

　　1.2 Advantages and Disadvantages of paired partners

2 Information Hiding, interface design, loose coupling

　　2.1 Information Hiding

Information Hiding refers to the specific information (process or data) contained in a module when designing and determining a module. It is not accessible to other modules that do not need such information.

Information Hiding is the foundation of structured design and object-oriented design. The concepts of functions and object-oriented encapsulation in the structure are derived from information hiding. The software industry has recognized this principle for the past decade.
David parnas first proposed Information Hiding in 1972. He pointed out in his thesis that code modules should be encapsulated using well-defined interfaces. The internal structure of these modules should be the private property of programmers, and the outside should be invisible. Fred Brooks admitted to his criticism of parnas in the 20th anniversary of the mythical man-month. "I'm sure information hiding-often built in Object-Oriented Programming-is the only way to improve the design level," he said ".
The following lists some information hiding principles.
1. layer and layer are added to the interface layer;
2. All classes and classes are accessed through interface classes;
3. All data members of the class are private, and all accesses are implemented through the access function;

　　2.2 Interface Design

　　Every large system is composed of many modules. system development is a great project, and it is difficult to develop. Therefore, a system of a certain scale usually breaks down the system to reduce the difficulty of analysis, design, and Development. module division is a common method, modules and modules are integrated through interface design. In practice, there are two very likely situations: the interface maintenance is out of control or too strict and rigid (and affects development ). The interface is out of control because the interface maintenance is too casual, because the module needs to easily add an interface (method) to module B, resulting in this interface (method) non-independence (basically used only for this function of module A), or strict interface control, resulting in low work efficiency, or poor ease of use of interfaces. The reason is: the interface is the coupling between the two modules, and various problems occur because the module coupling is too tight. In practice, the interface provided by the module is, it is confused with the interface of the external module to be implemented by the module. According to the guiding principle: To reduce coupling, only one layer is added in the middle. A feasible practice is: it is easy to design external interfaces (methods) for the module, unless it is obtained through restructuring. The module provides two types of external services: one is the interface that needs to be implemented by an external module (the interface design starts from the needs of this module. Of course, although each interface serves a certain functional point, it should also be noted that it is universal within the module ), the other is the implementation class of the interfaces required by other modules. That is, module A has some interfaces that need to be implemented by Module B (Requirements of module A for Module B), while Module B also has interfaces that require implementation by module, therefore, a has the implementation classes of these interfaces. The advantage of this practice is that the module interface is isolated to reduce coupling, and the versatility of the interface and adaptability of the interface are separated, and the boundary of the module is also clarified, this provides a buffer for Interface Optimization and adjustment in the future. The key to interface design is that each module of the system can be well integrated and the system can run better. The module interface design is also a means to realize the whole of system functions, and is necessary for System Splitting and integration.

1. Single Responsibility Principle-single responsibility principle (SRP)
For a class, there should be only one reason for its change. This is the reason for the change ". 2. Open-Close principle-Open Close principle (OCP)
Software entities (classes, modules, functions, etc.) should be extensible, but cannot be modified. Expansion is open, and changes are closed. The key is abstraction. The general part of a function and the implementation details are clearly separated. Developers should only abstract those parts that present frequent changes in the program. Rejecting immature abstraction is as important as the abstraction itself)
3. The Rys replacement principle-the liskov substitution principle (LSP) subtype (subclass) must be able to replace their base type (superclass ).
4. Dependency inversion principle (iocp) or dependency injection principle-dependence inversion principle (DIP)
Abstraction should not depend on details. Details should depend on abstraction. Hollywood principle: "Don't call us, we'll call you". All dependencies in the program should end with abstract classes and interfaces. Programming for interfaces rather than implementations. No variable should hold a pointer or reference pointing to a specific class. No class should be derived from a specific class. No method should overwrite the implemented methods in any of its base classes.
5. Interface isolation principle (ISP)
Customers should not be forced to rely on methods they do not need. An interface belongs to a customer and does not belong to its class hierarchy. Multiple user-oriented interfaces are better than one common interface. Package (class library, DLL) Cohesion Principle 6. Reuse release Equivalence Principle (REP) Reuse granularity is the release granularity. 7. Principle of joint closure (CCP)

　　2.3 loose coupling

　　In common application architectures in the past, most applications communicate with each other directly. This dependency becomes a real problem when the application needs to be modified or eliminated. Any modification may update each unique communication line in its own way. Therefore, such changes may be costly. This situation is called inter-ApplicationTight couplingAnd gradually become a headache for some enterprises.

On the other hand, SOA (Service-Oriented Architecture) willLoose couplingAs a major principle for successful enterprise-level application integration. In contrast to tight coupling, loose coupling is:

Restrict the mutual understanding of requester application code and provider application code. If any aspect of the coupled service changes, the requester or provider's application code (more likely the two at the same time) must change. If either party (requester, provider, or intermediary infrastructure) changes any aspect of the decoupled service, the other parties do not need to change.

A loosely coupled system is usually a message-based system. At this time, the client and remote service do not know how the other party implements the system. Communication between the client and the service is governed by the message architecture. As long as the message conforms to the negotiated architecture, the implementation of the client or service can be changed as needed without worrying about damaging the other party. Loosely Coupled communication mechanisms provide many advantages that do not exist in the tight coupling mechanism, and they help reduce the dependency between the client and remote services. However, tight coupling can usually provide performance benefits to facilitate closer integration between the client and the service (which may be necessary when there are security and transaction processing requirements ).

For loose coupling, although I have not participated in software development with relatively large specifications, I have also felt the importance of loose coupling in some personal programs.

Loose coupling is not only of great benefit to the communication mechanism, but also can be of great inspiration in programming and structure as an idea. Loose coupling emphasizes the independence of modules.

3 design by contract, code contract

 

Contractual design or design by contract (DBC) is a method for designing computer software. This method requires software designers to define formal, accurate, and verifiable interfaces for software components. In this way, a prior condition, posterior condition, and non-Variant Form are added for traditional abstract data types. This method is similar to the commercial contract. A contract defines the rights and responsibilities of two interactive objects. The employment contract specifies the number of hours you work and the rules of behavior that you must follow. As a company, you are paid, both of them fulfill their obligations, and both of them benefit. The core idea of DBC is to compare the elements in the software system with each other and the "responsibility" and "obligation.

 

Six principles of DBC

 

Principle 1: differentiate between commands and queries. The query returns a result without changing the visible nature of the object. Command to change the object status, but no results are returned. (The result may not be returned)

 

Principle 2: Separate basic queries from derived queries. A derived query can be defined using a basic query.

 

Principle 3: Set a posterior condition for each derived query and define it using the results of one or more basic queries. In this way, we can know the value of the derived query as long as we know the value of the basic query.

 

Principle 4: Write a posterior condition for each command to specify the value of each basic query. Based on the principle of defining derived queries using basic queries, we can now understand all the visual effects of each command.

 

Principle 5: a proper prior condition is used for each query and command. A prior condition limits the client's time to call queries and commands.

 

Principle 6: Write an unchanged expression to define the constant characteristics of an object. Class is an embodiment of an abstraction. We should focus on the most important attributes to help readers build correct conceptual models of class abstraction.

 

DBC is a great theoretical reform for software engineering and has a great impact on the C/S model. For the C/S model, we think that the status of the two modules is not equal. We often require the server to be very powerful and can handle all possible exceptions, but ignore the client, this causes poor client code.
In DBC, the user and the called user are in equal status, and both parties must fulfill their obligations to drive their rights. The caller must provide correct parameters. The caller must ensure the correct results and immutability required by the caller. Both parties have obligations and rights to use. This guarantees the quality of the code and improves the efficiency and quality of software engineering.
The disadvantage is that there are certain requirements for programming languages. Contractual programming requires a mechanism to verify whether a contract is established. Assertions are obviously the best choice, but not all programming languages have assertions. Therefore, forced language imitation will inevitably lead to code redundancy and readability improvement. For example, before net4.0, there was no assert concept. After net4.0, the concept of contractual programming was fully introduced, greatly improving the availability of contractual programming. In addition, contractual programming is not standardized, so the definitions and modifications between projects are different, causing great confusion to the Code. This is precisely why contractual programming applications are rarely seen in reality.

In our programming, the call between functions basically uses the idea of contractual programming, requiring that the input parameters must meet specific requirements.

 

4 unit test

5. UML diagram

6. algorithm details

Pairwork-programming of elevator dispatch program pair