Object-Oriented Design (OOD) Concepts

Object-Oriented Design (OOD)

• Object-Oriented Programming (OOP) is a paradigm based on objects
  • Objects contain data, also known as attributes or properties
  • Objects contain code, also known as methods or functions
  • Objects are instances of classes which determine their types
• Object-Oriented Design (OOD) is the use of objects and object-oriented programming for designing software solutions

Object Calling and Answering

• Objects do not accept arbitrary calls
• Acceptable calls are defined by "methods"; also known as operations, procedures, subroutines, and functions
• Each method has its own signature, containing a name, parameters, and types

Object Interface

• Every method has a signature
• An object's interface is the set of method signatures for that object
• Objects can hide their state (attributes), restricting access through an interface. This is known as Information Hiding

Client and Server Objects

• Objects send messages by calling methods
  • The method call is identified as the message
  • The object calling the method is the client object
  • The object receiving and executing the call is the server object

Object Interfaces

• An interface is a set of method signatures
• Methods define the "services" a server object offers
• An interface is a set of functional properties (services) a software object provides or requires
• Methods/services should be created and named according to the needs of client objects intending to use them
• On-demand design involves "pulling" interfaces and implementations based on client needs, rather than "pushing" features from a class

Modularity

• Modular programming is a software design technique emphasizing the separation of the functionality of a program into independent, interchangeable modules (packages)

Modules vs Objects

• Modules are loose groupings of subprograms and data
  • This "promiscuous" access to data can result in misuse
• Objects encapsulate data

Unified Modeling Language (UML)

• UML is a standardized visual language used in software engineering, representing different aspects of a system's structure and behavior
• UML contains diagrams such as class diagrams, use case diagrams, sequence diagrams, activity diagrams, and state machine diagrams

Key UML Components

• Class Diagrams: Represent the structure of a system via classes, attributes, methods, and relationships
• Use Case Diagrams: Illustrate interactions between actors (users or external systems) and the system to achieve specific goals
• Sequence Diagrams: Depict interactions between objects in a scenario/use case over time
• Activity Diagrams: Model the flow of activities/actions within a system/use case
• State Machine Diagrams: Describe the states of an object/system and the transitions between those states which are triggered by events
• Component Diagrams: Display the components of a system and their relationships
• Deployment Diagrams: Visualize the physical deployment of software components across hardware nodes
• Package Diagrams: Organize and structure system elements into logical groupings

UML Class Notations

• UML has three compartments for class notations
  • Class Name
  • Attributes
  • Operations
• Notations include:
  • + for Public
  • - for Private
  • # for Protected
  • ~ for Package
  • / for Derived

Inheritance in UML

• Inheritance relationships in UML diagrams show Base Classes inheriting from Derived Classes

UML Object Association

• Association: One object accesses the other
• Top: bidirectional association
• Middle: Class1 accesses Class2 (unidirectional)
• Bottom: Class1 is prohibited from accessing Class2

UML Object Inheritance

• Inheritance (aka generalisation): An object inherits the properties of another object through class extension
• Known as an “is a” relationship

UML Object Composition

• Composition: An object references another object as an instance variable
• Known as a "has a” relationship

UML Object Aggregation

• Differentiated from composition
  • Aggregation implies the child class may exist without the parent class
  • Composition implies the child class cannot exist without the parent class
• Some sources consider both concepts synonymous

Object Relationships - Inheritance vs Composition

• Inheritance and composition both extend the base functionality
• Inheritance: Changes in the "base" class propagate to the derived class and its client classes
  • Code changes risk introducing unintentional bugs
• Composition: More adaptive to change; changes in the base class remain contained and hidden from the clients of the front-end class

Polymorphism

• Polymorphism allows objects of different classes to be treated as objects of a common superclass
  • This invokes methods on different objects in a uniform manner, even across distinct behaviors/classes
• Polymorphism means providing a single interface to entities of varying types, allowing entities to take on many forms

Types of Polymorphism

• Compile-time Polymorphism (Static Binding or Early Binding)
  • Decision of which method to call occurs during compilation time
  • Method/operator overloading
• Runtime Polymorphism (Dynamic Binding or Late Binding)
  • Decision of which method to call occurs during runtime, based on the object's type
  • Achieved through method overriding and interface implementation, redefining in a subclass which is already defined in a superclass

Duck Typing

• Duck Typing: Object’s type/class is less important than its methods
• "If it walks like a duck and it quacks like a duck, then it must be a duck"
• Instead of checking types, one checks for methods/attributes

Duck Typing - Focus on Object Behaviors

• Focuses more on behaviors vs actual type/class
• If an object supports the necessary methods/properties for a certain operation; it is considered the expected type, regardless of its inheritance
• Example: Iterating over collections of any type

Polymorphism and Subtyping

• Subtyping: A type of polymorphism where code for a supertype can work on a subtype
• Often achieved with inheritance

Polymorphism: Ad-hoc

• Ad-hoc: involves multiple implementations
• Also known as Method/Operator Overloading: A single name/symbol may have multiple implementations per the passed arguments

Implementation Selection in Polymorphism

• Static: Implementation is selected at compile time
  • Called static dispatch
• Dynamic: Implementation is selected at run time
  • Called dynamic dispatch
• The type used depends on the programming language

Why Polymorphism?

• Pros:
  • Allows code reuse
  • Reduces code size
  • Improves code modularity
• Cons:
  • Can be complex
  • Makes code reading difficult, without knowing which implementation will be called
  • Dynamic dispatch is slower

Why Object-Oriented Design?

• Modularity/reusability makes development faster and cheaper
• Modularity also makes systems easier to maintain
• Object-Oriented Design can be complicated to design/explain

Object-Oriented vs Process-Oriented

• Process-oriented is easier to grasp as it is person-centric
• Object-oriented is confusing due to labor-division (assigning tasks and coordinating workflow becomes a management concern)
• Object-oriented is organization-centric and scales to large problems but is difficult to design

How to Design OO Systems Well?

• Primary factors in methodology:
  • Agility (like the scrum process)
  • Traceability
  • Testability
  • Measurability
  • Security

Traceability Importance

• It should be possible to step-by-step trace a software system from requirements to blocks of code
• "Why is this here?" should be an answerable question
• Good traceability ensures efficient time and resource allocation

Testability

• Test Driven Development (TDD): Software requirements must be converted into test cases prior to software development.
• Each step should involve a means of verification.
• Developers must know how a software artifact will be tested before creation.
• Continuous integration tools improve testability

Measurability

• Measure software quality using statistics, bug reports, performance reviews and optimizations
• Measure development productivity
  • Example: Scrum points per unit, burndown charts
• However, performance is improved if developers are left to do their jobs

Security

• Often critical to consider a system's security during design
• Security issues arise from poorly designed code, exposing the system to exploits
• Interconnectivity indicates a compromised system could affect others connected to it
• Security requirements may create conflicts with others, such as ease of use