Elevator scheduling program Pair Programming

Paired person: Ma zuolin Wang Di

1. Pair Programming

1.1 Pair Programming advantages and disadvantages

(1) The first step is the high efficiency of Pair programming. During Pair programming, two people can do different units separately or the same unit at the same time. In some simple units of the project, a person can assign a simple unit to different people. For the core unit, such as the elevator Scheduling Algorithm of the project, this is a core part. We need to discuss it together. After the discussion, we can implement it again, or two people can write their own ideas and implement them using code. At this time, we will combine the algorithm of the person with high efficiency. In addition, in Pair programming, there must be mutual supervision, compared to a Write Program, do not want to play some other things.

(2) The idea stems from intense discussions between two people. In many cases, during the discussion, we often suddenly have an idea that suddenly strikes, or something we didn't know before, it may be easy to understand.

(3) We have a lot of fun in pairing programming, and we are very happy to work together. This will improve our passion, efficiency, and work.

(4) When debugging, it is no longer as helpless as a person debugging. When two people encounter a bug, the above picture is left by the two of us during debugging. At this time, with the experience of two people, it is easier to deal with these bugs. Later maintenance is more convenient.

1.2 PAIR partner advantages and disadvantages

Advantages of Wang Di: (1) very serious; (2) very enthusiastic; (3) Humorous. It is fun to work with him.

Disadvantages of Wang Di: he enjoys the best practices and the project progress is slow.

My advantages: (1) optimistic; (2) faster coding; (3) Better communication skills

My disadvantages: lack of experience

2. Information Hiding, interface design, loose coupling

2.1Information 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.2Interface Design

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.3Loose 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

4. Unit Test

5. UML diagram

6. Algorithms

Elevator scheduling program Pair Programming