Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 4 - Object-Oriented Paradigm - Coggle Diagram
Chapter 4 - Object-Oriented Paradigm
4.1 Overview
OO principles
Inheritance
Can define new classes that derive from existing base classes
Allows software reuse, hence improving the effectiveness of software development
Polymorphism
Refers to the ability of an object to behave differently and assume different forms based on its inheritance hierarchy
Includes vertical override operations between
Parent classes
Derived classes
Horizontal overloading operations within the same class
Encapsulation
Separate interface from implementation
4.2 Introducing the Object-Oriented Paradigm
Classes and Objects
Classes
Groups together related data and their operations
Defines the attributes and behaviors shared by all of its objects
Syntactic description
A list of attributes
A class name
A list of operations
Objects
Is an instance of a class
Relationships
Composition
Represents the whole/part relationship between classes
The parts of a class have the same lifespan as their owner, and the parts cannot be involved in another composition
Aggregation
Represented using a hollow diamond arrowhead
Do not have to share the same lifespan as the owner
May be involved in more than one aggregation relationship
Association
Represents the logical relationship among classes
Represented by a solid line and has the following parts
Name of the association
End type at each end of the association link
Multiplicity at each end
Inheritance
Represented using a line with a closed arrowhead
If the line is dashed, it is a realization relationship
Prevent repeatedly writing the same code for similar classes
Composition vs. Inheritance
Three general principles to choose between composition and inheritance
Composition can be used to model the "has-a" relationship among classes
Inheritance could possibly weaken the encapsulation of an OO design
Use the inheritance relationship only when the derived class "is-a" base class
Weakness of inheritance
Changes to the design of a base class may lead to cascading changes to derived classes and the users of derived classes
4.3 00 Analysis
Step 1: Design of a UML Use Case Diagram
Each use case is monitored by a controller class, especially when the use case has a complex event flow
Step 2: Develop an Analysis Class Diagram via Noun Extraction
Describes the key classes of a system and their interrelationships but is not the design of the system
Describes the functionality of the system in terms of abstractions (classes) of the concepts found in the problem and the domain
Captures the functionalities and logical relationships among the different elements of the system
4.4 OO Design
Steps of design
Step 3: Build a State Machine Diagram
Specify the interface of each class and make decisions about implementation
Consists of two types of basic elements
State
Transition
Two cases of building a state machine diagram
A class is responsible for a single use case
Look into the flow of events and corresponding interaction diagram to identify the different states that an object of this class goes through and the corresponding transitions
A class is involved in multiple use cases
Combine all the information and consider the environment and the change of internal data values to identify the states
Step 1: Identify Classes—CRC Card
Is a team-based approach
Step 2: Construct an Interaction Diagram
Describes how the objects that compose the system interact with one another to accomplish a use case
Two forms
Sequence diagrams
Communication diagrams
Step 4: Class Specification
A class provides four categories of operations in its public interface
Destructor operations
Used to clean up memory and free system resources when an object is no longer in use
Accessor operations
Retrieves information from the object
Does not change the state of an object
Constructor operations
Used to initialize the data members of an object when it is created
Mutator operations
Resets the value of one or more object attributes
Invocation of a mutator operation usually causes the transition between object states
Goal of design
Develop the structural architecture of a system
4.5 Design Principles
Open-Closed Principle
The principle encourages OO designers to practice the following two guidelines
Open to extension
The system should have the ability to be extended to meet new requirements
Closed to modification
The existing implementation and code of the system should not be modified as a result of system expansion
The open-closed principle
Keep attributes private
Minimize the use of global variables
Separate interface and implementation
Ensuring Cohesion
Is about the design of a single class
A cohesive class is one that performs a set of closely related operations
Principle of Decoupling
Simplicity and elegance in implementation
Easy extension
Less interdependency