Object-oriented programming and object-oriented analysis

Object-oriented programming is not programming with object-oriented programming languages, but using the polymorphic properties of programming.

Object oriented analysis is to analyze the objective world, that is, the business domain of programming.

  • Hyperemia model and anemia model

  • Domain-driven design DDD

The purpose and principles of object-oriented design

The ultimate goal of software design is to make software achieve “strong cohesion and loose coupling”, so that software:

  • Easy to extend – Easy to add new features

  • Stronger – less likely to be broken by careless programmers

  • Portable – Can run in a variety of environments

  • Simpler – easy to understand and maintain

Principles of object-oriented design

  • In order to achieve the above design goals, several guiding principles have been summarized

  • Principles are language independent and can even be used in non-object-oriented programming languages.

Design patterns

A design pattern is a generic solution to a problem. Design patterns are also language-neutral. Design patterns implement design principles.

  • Create a model

  • Behavior patterns

  • Structure mode

Frameworks

The framework is used to realize the structural program of a certain kind of application, and is the design and implementation of the reusable scheme of a certain kind of architecture

  • The frame of a framelike mansion

  • Simplify your life as an app developer

  • The realization of a variety of design patterns, so that the application developers do not need to spend too much effort, can design a well-structured program

Frameworks for different domains

  • Microsoft has developed the MFC framework for Windows programming.

  • Java developed the AWT framework for its GUI

  • There are also many open source frameworks: MyBatis, Spring, etc

  • The Web server is also a framework: Tomcat

Framework VS Tools

The framework calls application code. Application code calls tools

The architect framework ensures that the architecture’s landing architect uses tools to improve development efficiency

The stink of Software Design

Bad software gives off the following stinks

  • Stiff – hard to change

  • The design is rigid if a single change leads to a chain of changes in dependent modules, and the more modules that must be changed, the more rigid the design becomes.

  • Fragile – Trying to change A, only to have B accidentally destroyed

  • [Vulnerability] If there is no conceptual connection between the place where new problems occur and the place where changes are made. Fixing these problems leads to more problems, and the development team becomes like a dog chasing its tail.

  • Non-portable – cannot adapt to changes in the environment

  • [Robustness] The design contains parts that are useful to other systems, and the effort and risk required to separate these parts from the system is enormous.

  • Misuse traps – It’s easier to do the wrong thing than the right thing, enticing the programmer to break the design

  • [Viscosity] can keep the system design method is more difficult to apply than the method of breaking the design.

  • Obscure – The code is hard to understand

  • Obscurities not showing good intent

  • Over-designed, copy-paste code

  • Unnecessary complexity and repetition

OOD Principle 1: Open and Close (OCP)

OCP-OPEN/Closed Principle

  • It is open for extension

  • Is closed to change

  • It should be possible to extend functionality without modifying software entities (classes, modules, functions, and so on).

The traditional way to extend a module is to modify the source code of the module. How do you implement extension without modification?

  • The key is abstraction

Phone-dialer-digitbuttons-sendButton

OOD Principle 2: Dependency Inversion

DIP – Dependency Inversion Principle

  • High-level modules cannot depend on low-level modules, but everyone depends on abstractions;

  • Abstraction does not depend on implementation, but on abstraction.

DIP inverted what?

  • Module or package dependencies

  • Development sequence and responsibilities

The hierarchy of software

  • The top determines the bottom

  • High level reuse

The core of the framework

Hollywood rules:

  • Don’t call me, I’ll call you.

Programs do not call frameworks; frameworks call applications. Dependency inversion: You want to use the framework, but don’t have to call the framework (Spring, Junit, Tomcat)

OOD Principle 3: Liskov Substitution Principle (LSP)

In statically typed languages like Java/C++, the key to OCP is abstraction, and the power of abstraction lies in polymorphism and inheritance.

  • What are the requirements for a proper inheritance?

  • Answer: The Liskov substitution principle

Liskov described this principle in 1988:

  • If for every object o1 of type T1, there exists an object O2 of type T2, such that in all programs P written for T2, the behavior function of program P remains unchanged after o2 is replaced by o1, then T1 is a subtype of T2.

  • In short: Subtypes must be able to replace their base types.

Error Demonstration [cannot use subclasses where base classes are used]

  • Shape: round, square

  • The JDK: hashtable – Properties; Vector-Stack

  • When calculating area, square subclasses rectangle

View LSP from the perspective of contract

  • LSP requires that wherever a base class is used, it also applies to its subclasses.

  • Java syntactically means:

  • A subclass must have the entire interface of the base class.

  • Subclasses cannot have tighter access controls than base classes.

  • A subclass’s contract cannot be stricter than a base class’s

  • For example, if a square is of equal length, the contract is stricter than a rectangle, so the square is not a subclass of rectangle

  • For example, the contract for Properties is stricter than for Hashtbale.

How to reconstruct the code to solve the LSP problem

  1. Extract commonalities to base classes;

  2. To combine

Inheritance VS composition

Inheritance and composition are two extensions of OOP.

Advantages of inheritance:

  • This is easier because most of the functionality of the base class can be inherited directly into subclasses.

Disadvantages of inheritance:

  • Break encapsulation, exposing base class details to subclasses, and inheritance is white box reuse

  • Base class changes, affecting subclasses

  • Inheritance is static and cannot change composition at run time

  • Class number explosion

Combinations should be used in preference

Principle 4 of OOD: Single Responsibility (SRP)

SRP – Single Responsibility Principle

  • Also called Cohesion principles

  • Functional dependencies between components of a module

  • Connect it to the forces that cause a module to change, and you get the following description

  • A class can only have one cause that causes it to change

What is duty?

  • Just talking about it, different definitions

  • Definition: A responsibility is a cause for change.

Consequences of violating SRP principles

Consequences:

  • Vulnerability – Coupling drawing and computing functions so that when one is modified, the other can be accidentally compromised

  • Non-portability – Computational geometry applications only need to use the “compute area” functionality, but have to include GUI dependencies.

Principle 5 of OOD interface Separation (ISP)

ISP- interface Segregation Principle

  • Clients should not be forced to rely on methods they do not need

Relationship between ISP and SRP:

  • ISP is related to SRP, both related to cohesion

  • SRP specifies how a class should be designed — there can only be one reason for a class to change.

  • The ISP points out how to design an interface — from the customer’s point of view, emphasizing that customers don’t see methods they don’t need.

Recommendation: Agile software development