Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter4: Objec-Oriented Paradigm - Coggle Diagram
Chapter4: Objec-Oriented Paradigm
OOP
Encapsulation
Separate interface from implementation
Polymorphism
Refers to the ability of an object to behave differently and assume different forms based on its inheritance hierachy
Includes vertical override operations between
Parent classes
Derived classes
Horizontal overloading oprerations within the same classes
Inheritance
Can difine new classes that derive from existing base classes
Allows software reuse, hence improving the effectiveness of software development
Introducing the Object-Oriented Paradigm
Classes and Objects
Classes
Groups together related date and their operations
Defines the attributes and behaviors shared by all of its objects
Syntactic description
A list of attributes
A list of operations
A class name
Objects
Is an instance of a class
Relationships
Association
represents the logical relationship among classes
represented by a solid line and it has the following parts
name of the association
end type at each end of the association
link
multiplicity at each end
Inheritance
prevent repeatedly writing the same code for
similar classes
represented using a line with a closed arrowhead
If the line is dashed, it is a realization relationship
Aggregation
represented using a hollow diamond arrowhead.
may be involved in more than
one aggregation relationship
Parts involved in an aggregation relationship do not have to share the
same lifespan as the owner
Composition vs. Inheritance
three general principles to follow to make the right decision
Composition (or aggregation) can be used to model the "has-a"
relationship among classes
Inheritance could possibly weaken the encapsulation of an OO design (Venners, 1998).
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
Composition
the parts of a class have the same
lifespan as their owner, and the parts cannot be involved in another composition.
represents the whole/part relationship between classes
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
captures the functionalities and logical relationships among the different elements of the system
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
OO Design
Step 2: Construct an Interaction Diagram
how the objects that compose the system interact with one another to accomplish a use case
Two forms
Sequence diagrams
Communication diagrams
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
A class is involved in multiple use cases
Step 1: Identify Classes—CRC Card
Is a team-based approach
Step 4: Class Specification
A class provides four categories of operations in its public interface
Destructor operations
Accessor operations
Constructor operations
Mutator operations
Design Principle
Ensuring cohesion
Is about the design of a single class
A cohesive class is one that performs a set of closely related operations
Open-Closed principle
The principle encourages OO designers to practice the following two guidelines
The open-closed principle
Principle of decoupling
Easy extension
Simplicity and elegance in implementation
Less interdependency