Software Designer (Object-Oriented, UML, Design Patterns)

object oriented

• kind
  • A class is an abstraction of an object, and an object is an instance of a class
  • Entity class
    • Core classes (real entities in the real world)
  • interface class (boundary class)
    • Provides a way for users to interact cooperatively with the system (a medium of contact for participants within and outside the system)
  • control class
    • Control the flow of activities, acting as a coordinator (coordinating interactions between class objects)
  • Class general (vehicle) special relationship (ship, car, airplane) ps means that a large range includes a small range
• object
  • Objects are basic entities, including data (properties, states), and operations on data (services, behaviors, methods)
  • It consists of three parts: object name, attributes, and methods
  • A construct for communicating between objects is called a message
• Method overloading: A class can have multiple methods with the same name but different parameter types
  • The method name is the same but the number of parameters is different
  • Same method name but different parameter types
  • Method names with the same parameter type order are different
• Messages: Service requests issued by objects, providing mutual communication
• encapsulation
  • An object encapsulates attributes and behaviors as a whole, an information hiding technique. Only one interface is exposed
• inherit
  • A mechanism for sharing data and methods between parent classes (superclasses, base classes) and subclasses (derived classes)
  • A parent class can have multiple subclasses, inheriting from only one parent class is single inheritance, and multiple inheritance is multiple inheritance
  • Child extends Parent and child can override parent's method (override, replacement)
• polymorphism
  • Different objects receive the same message and produce completely different results. Implements support for receiving inheritance
  • Parent class name object name = new subclass name () compile (static binding) look at the left, run (dynamic binding) look at the right
  • Generic Polymorphism
    • Parametric polymorphism: the most widely used polymorphism, the purest polymorphism
    • Inclusion polymorphism: in many languages, one type is a subtype of another
  • specific polymorphism
    • Overload polymorphism: the same name means different things in different contexts
    • mandatory polymorphism
• Principles of Object-Oriented Design
  • Single Responsibility Principle: As far as a class is concerned, there should be only one principle that causes it to change
  • Open-closed principle: open for extension, closed for modification
  • Liskov Substitution Principle: Subclasses must appear where the base class appears
  • Dependency inversion principle: abstraction should not depend on details, details should depend on abstraction, high-level modules should not depend on low-level modules (depending on abstraction and not on details (implementation))
  • Interface Separation Principle: Depend on abstraction and not on concrete
  • Common reuse principle: Reuse a class in a package, then you must reuse all classes in the package
  • Common closure principle: If a change affects one, it will affect all classes in the package, while other packages will not have any impact
• Object Oriented Analysis OOA
  • The purpose is to gain an understanding of the application problem, and the purpose of the understanding is to determine the functional and performance requirements of the system
  • five steps
    • Identification object
      • In defining (determining) the problem domain, treat the naturally occurring "noun" as an object
    • organization object
    • Describe the interaction between objects (interaction between objects)
    • Determine the operation of the object (object-based operation)
    • Define the internal information of the object
• Object Oriented Design OOD
  • Transform the analysis model created by OOA into a design pattern. The goal is to define the system architecture blueprint (model diagram)
  • Understand the solution, implement system details
  • Five activities corresponding to OOA: identify classes and objects, define attributes, define services, identify relationships, and identify packages
• Object Oriented Programming OOP
• Four levels of object-oriented testing: algorithm layer, class layer, template layer, system layer
• expand
  • A static method of a class can only access the static member variables of that class
  • Static data members can be accessed by all methods of the class
  • Objects of this class share the value of its static members
  • Objects have clear boundaries, well-defined behavior, and extensibility
  • The domain class model contains attributes, operations, and associations

UML Unified Modeling Language

• UML building blocks
  • A thing is an abstraction of the most representative component of a model
    • Structural things (noun static): class, interface, collaboration, use case, active class, component, artifact, node
    • Behavioral things (verb dynamics): interaction (message), state machine (state), activity (action)
    • Grouping Things (Organizing Section): Packages, Annotating Things (Explaining Section): Annotations
  • relationship holds things together
  • The graph gathers related things
  • UML interfaces can be used to declare the services required by object classes
• Four Relationships in UML
  • Dependency: A change in an independent thing A will affect the semantics of another dependent thing B---->A The dotted line represents
  • Association: A structural relationship that describes a set of chains, which are connections between objects
    • The relationship is a straight line, on which you can mark the multiplicity (repetition) and role 0...1—0...* one-to-many
    • Many-to-many needs to create an association class (new class)
    • Aggregation: A special type of association that describes structural relationships between wholes and parts
      • Aggregation:—◇ Part of the whole life cycle is inconsistent, the whole disappears, the part still exists, and the part can exist without the whole
      • Combination:—◇(solid) parts have the same overall life cycle, the whole disappears, and the part also disappears, and the part cannot exist without the whole
  • Relationship: The object of the child element (special element) can replace the object of the parent element (general element) (the relationship between a class and multiple classes), and the child shares the structure and behavior of the parent. The graphic is: a solid line of a hollow arrow (pan ), pointing to the parent element
  • Realization: A classifier specifies an opportunity guaranteed to be executed by another classifier. The graphic is: a dotted line with a hollow arrow, the class points to the interface
• UML diagram

  • Class Diagram

    • The most common diagram showing a set of objects, interfaces, collaborations and the relationships between them
    • Preceding modifiers: +public-private#protected~package's
    • It is used to model the static design view of the system, the view supports functional requirements, and the three modeling methods use class diagrams
      • Modeling the vocabulary of a system, modeling a simple collaboration, modeling a logical database schema

  • object graph

    • A set of objects and the relationship between them at a certain moment, describing the static snapshot of the instance, generally including objects and chain graphs Object name: class name attribute (generally has a value) No method

  • use case diagram

    • When modeling the static use case view of the system: modeling the context of the system, modeling the requirements of the system
    • Shows a set of use cases, actors and their relationships (a diagram representing a use case is an ellipse)
      • There is an extend and include relationship between use cases and use cases
        • A basic use case (including use case) - "include" –> B must be executed before the included use case executes A
        • When a use case is executed, some special or optional situations may occur, which are the extended use cases of this use case
          • Extended use case (special case)----《extend》—>basic use case
      • Generalization between use cases and use cases and actors.
        • The graphic is: a solid line with a hollow arrow, the child class points to the parent element
      • Association between actors and use cases

  • interactive diagram

    • Model the dynamic aspects of the system, the passing of messages between them. Interaction diagrams generally contain objects, chains, and messages, and are represented as sequence diagrams and communication diagrams
      • Sequence Diagram (Sequence Diagram): A graphical representation of a scene that describes the interaction activities between objects organized in chronological order. The interactive object is placed on the top of the graph, on the left side where the interaction is initiated, and on the right side of the subordinate object
        • The sequence diagram has an object lifeline, which represents a vertical dotted line, indicating that an object exists within a period of time. X means that the lifeline disappears (ends)
        • The sequence diagram has a control focus, which is represented by a thin and tall rectangle, which represents the time period during which an object performs an action (the time period for object interaction), which can be executed directly or through a lower-level program.
        • Message—> <------- return message synchronously need to wait for return message asynchronously do not need
      • Communication diagram (collaboration diagram): Emphasizes the structural organization of objects that send and receive messages (shows the message flow and sequence between objects)
        • Communication graphs have paths that indicate how one object is linked to another
        • Communication diagrams have sequence numbers, indicating the chronological order of vague messages

  • State diagram

    • Represents a state machine consisting of states, transitions, events, and activities. Focus on a dynamic view of the system, emphasizing the sequence of events in the behavior of objects. Reactive Object Modeling (an object)

      • A state is an observable pattern of system behavior that can both change state and perform actions. The states are: initial state (black dot), final state (black dot plus a circle), intermediate state.

      • The state diagram is a rounded quadrilateral (then divided into upper, middle and lower), the upper part is the state name (must have), the middle part is the name and value of the state variable (optional), and the lower part is the activity table (optional). The state transition between states, The beginning is ignition or triggering, the initial state can only have one final state, multiple or none

      • Activity diagram = activity = multiple actions: event name (ps ringing) / action expression (ps answering the phone)

        • Three standard event names
          

      • Conversion (migration): state transition between states is represented by a line with an arrow

        • There are two states original state ===== "target state

      • Event (will trigger conversion): It is the event on the conversion logo, which is something that happens at a certain moment, and it abstracts the external events that cause the system action to change from one state to another.

        • Expression: event description [guardian condition]/action expression
          • Use event description and guard condition (Boolean) at the same time, if and only if the event occurs and the condition is true, the state transition will occur. Action expression
          • If there is only a monitoring condition (Boolean) and no event description, the condition is true, and the action expression can occur when the state transitions (if no event is marked, it will automatically switch after the internal activity ends)

      • Activities (actions) can be executed within a state or at state transitions (transitions)

      • Composite states (superstates) contain nested states (substates)

  • activity diagram

    • A special kind of state diagram that flows from one activity to another. (The difference from the state is that there is no time on the solid line arrow and there is only [] guardian expression)
    • Modeling workflow, modeling operations, two ways to use activity diagrams

  • Architecture Diagram (Component Diagram)

    • The organization and dependencies among a set of components. Static implementation view, related to class diagrams, where components are mapped to one or more classes, interfaces, and collaborations.
      

  • deployment diagram

    • A method for modeling the physical aspects of object-oriented, (stereo) static relative to component diagrams
    • Shows the relationship between the software and hardware of the system, used in the implementation phase
    • Dependencies between deployment components are similar to package dependencies

  • Summarize
    

Design Patterns

• Elements of Design Patterns

  • Provide solutions to related problems, making it easier and more convenient for people to reuse successful designs and architectures
  • Four elements: model name, problem, solution, effect
  • Each design pattern focuses on a specific object-oriented design problem or design point
    

• Creational Design Patterns

  • Various types of information are encapsulated, and what the entire system knows about these objects is the interface defined by the abstract lock
  • Factory Method Pattern (Class)
    • The intent is to define an interface for creating objects, letting subclasses decide which class to instantiate, and factory methods to defer the instantiation of a class to its subclasses
    • Applicable when a class does not know the class of the object it creates, and when a class wants its subclasses to specify the object it creates
  • abstract factory pattern
    • The intent is to provide an interface for creating a series of related or interdependent objects without specifying its concrete class
    • When a system is to be independent of the creation, composition and presentation of its products
    • When a system is to be configured by one of several product families
    • When the design of a series of related product objects is to be emphasized for joint use
    • When providing a library of product classes and only want to show their interfaces but not their implementations
    • ps: Define parallel class hierarchies for different platforms for graphical user interface components, suitable for abstract factories
  • generator pattern
    • Separate the components of a complex object from its representation so that the same construction process can create different representations
    • Applicable when the algorithm for creating a complex object should be independent of the object's constituent parts and how they are assembled
    • When the construction procedure must allow different representations of the objects being constructed
  • prototype pattern
    • The intent is that prototype instances specify the kind of objects to create, and new objects are created by duplicating these prototypes
    • Applicable when a system should be created, constructed and represented independently of its products
    • When the class to instantiate is specified at runtime, for example, by dynamic loading
    • To avoid creating a factory class hierarchy parallel to the product class hierarchy when
    • When an instance of a class can only have one of several different combinations of states, it may be more convenient to create a corresponding number of prototypes and clone them than to manually instantiate the class each time with the appropriate state
  • singleton pattern
    • The intent is to ensure that a class has only one instance and provide a global access point to it
    • Applicable when a class can have only one instance and clients can access it from a well-known access point
    • When the only instance should be subclassable and clients can use an extended instance without code changes

• Structural Creation Patterns

  • How to combine classes and objects to get larger structures, using inheritance mechanism to combine interfaces or implementations

  • adapter pattern (class)

    • Convert the interface of a class to another interface that the client wants. The adapter mode enables classes that could not work together due to incompatible interfaces to work together.
    • Want to use an existing class whose interface does not meet the requirements
    • Want to create a reusable class that works with other unrelated or unforeseen classes (understand)
    • Want to use an existing subclass, but it is impossible to subclass each one to match their interface, object adapter can adapt its superclass interface (only for objects)

  • bridge mode

    • Separating the abstract part from its implementation so that they can both vary independently
      

  • combination mode

    • Combining objects into a tree structure to represent a "part-whole" hierarchy, the combination enables users to use the combined objects of a single object with consistency
    • Suitable for wanting to represent part-whole hierarchies of objects
    • It is hoped that the user will ignore the difference between the composite object and the single object, and the user will use all objects in the composite structure uniformly

  • decorator pattern

    • The intent is to dynamically add some additional responsibilities to an object
    • Dynamically and transparently add responsibilities to individual objects without affecting other objects
    • Deal with responsibilities that can be revoked

  • appearance mode

    • The intent is to provide a consistent interface to a set of interfaces of a subsystem
    • When you want to provide a simple interface to a complex subsystem
    • There is a large dependency between the client program and the implementation part of the abstract class
    • When you need to build a hierarchical subsystem, use it to define the entry point for each layer in the subsystem

  • Flyweight mode

    • The intent is to efficiently support large numbers of fine-grained objects using sharing techniques
    • An application uses a large number of objects
    • Entirely due to the large number of objects, resulting in a large storage overhead
    • Most states of an object can become external states
    • Many groups of objects can be replaced with relatively few shared objects if the external transitions of the objects are removed

  • Proxy mode

    • The intent is to provide a proxy for other objects to control access to this object
      

• Behavioral Design Patterns

  • Design algorithms and assignment of responsibilities between objects, describe schemas for objects and classes, and communication schemas between them
  • interpreter mode
    • The intent is to, given a language, define a representation of its grammar, and define an interpreter that uses this representation to interpret sentences in the language
    • When a language needs to be interpreted and executed, and the sentences in the language can be represented as an abstract syntax tree
    • The grammar is simple and efficiency is not a critical issue
  • template method pattern
    • The intent is to define the skeleton of an algorithm in an operation, while deferring some steps to subclasses. Templates allow subclasses to redefine certain steps of an algorithm without changing the structure of the algorithm
    • Implement the constant parts of an algorithm at once, leaving the variable behavior to subclasses
    • Behaviors that are common across subclasses should be extracted and centralized into a common parent class to avoid code duplication
    • control subclass extension
  • chain of responsibility model
    • Intents avoid coupling between the sender and receiver of a request by giving multiple objects a chance to handle the request. Link these objects into a chain, and pass the request along the chain until an object handles it.
    • There are multiple objects that can handle a request, and which object handles the request is automatically determined at runtime
    • Want to submit a request to one of multiple objects without explicitly specifying the receiver
    • The set of objects that can handle a request should be specified dynamically
  • command mode
    • The intention is to encapsulate a request into an object, so that different requests can be used to parameterize clients, love requests or record request logs, and support undoable operations.
    • Abstract the action to be performed and parameterize an object
    • Specify, queue and execute requests at different times
    • Support cancel operation Support modification log
    • Construct a system with high-level operations built on primitive operations
  • iterator pattern
    • The intent is to provide a way to sequentially access the elements of an aggregate object without exposing the object's internal representation
    • Access the contents of an aggregate object without exposing its internal representation
    • Supports multiple traversals of aggregated objects
    • Provide a common interface for traversing different aggregation structures
  • mediator pattern
    • The intent is to use an intermediary object to encapsulate a series of object interactions
    • A set of objects communicate in a well-defined but complex way, resulting in interdependencies that are unstructured and difficult to understand
    • Does an object refer to many other objects and communicate directly with these objects, making it difficult to reuse the object
    • Want to customize a behavior that is distributed across multiple classes without generating too many subclasses
  • memo mode
    • The intent is to capture the internal state of an object without breaking encapsulation, and save this state outside the object, so that the object can be restored to the original saved state later
    • The state of an object at a certain point in time must be saved so that it can be restored to a previous state if needed later
    • If one uses an interface to allow other objects to get these states directly, it will expose the implementation details of the object and break the object's encapsulation
  • Observer pattern
    • The intent is to define a one-to-many dependency relationship between objects. When the state of an object changes, all objects that depend on it are notified and automatically updated
    • When an abstract model has two aspects, one of which depends on the other, encapsulate the two in separate objects so that they can be changed and reused independently
    • When a change to one object requires changes to other objects at the same time, and it is not known exactly how many objects need to be changed
    • When an object has to notify other objects, but it cannot assume who the other objects are, neither wants these objects to be tightly coupled
  • state mode
    • The intent is to allow an object to change its behavior when its internal state changes. The object appears to have modified its class
    • An object's behavior is determined by its state, and it must change its behavior at runtime based on state
    • There are huge multi-branch conditional statements in an operation, and these branches depend on the state of the object. This state is often represented by one or more enumeration constants
  • strategy pattern
    • The intention is to define a series of algorithms, encapsulate them one by one, and make them interchangeable. This mode enables algorithms to vary independently of the clients using them
    • Many related classes simply behave differently
    • Different variants of an algorithm need to be used
    • Algorithms use data that clients should not know
    • A class defines a variety of behaviors, and this behavior appears in the form of multiple conditional statements in the operation of this class, and the relevant conditional branches are moved into their respective strategy classes to replace these conditional statements. (Customer junior members, intermediate members and senior members have different discounts)
  • visitor pattern
    • An intent represents an operation to be performed on elements in an object structure. It defines new operations on elements without changing their class
    • An object structure contains many class objects with different interfaces, and the user wants to perform some operations on these objects that depend on their specific classes
    • The class that defines the object structure rarely changes, but often needs to define new operations on this structure
    • Need to perform many different and unrelated operations on objects in an object structure