Please enable JavaScript.
Coggle requires JavaScript to display documents.
Programming Foundations: Object-Oriented Design Barron Stone and Olivia…
Programming Foundations: Object-Oriented Design
Barron Stone and Olivia Chiu Stone
Concepts
UML
Unified Modeling Language: can be easily transformed into modern OOP langauges, such as Java, Python, C++
Standardized notation for diagrams to visualize the object-oriented systems
Objects
Prerequisites: an object is a noun, and can be either physical or abstract (You should be able to call it with "the")
3 Main Features
Identity (id #, or just a
name
)
Attributes/Properties (describe a state)
Behaviors/Functions (describe a change)
Classes
Template used to create/define/instantiate objects
Java has 6000+ class in its built-in library
APIE
(4 pillars of OOD and foundations of OOP)
A
bstraction
E.g. Person -> you know the approx. attributes and behaviors of a "person" without need to know all the instances
The process of creating a class
E
ncapsulation
Only allow the necessary function or attributes to be accessible by other function or outside world! (Protection)
I
nheritance
Single Inheritance Langauges
Java/Rube/C#/Swift
Multiple Inheritance Languaes
Python/C++
Finding the common attributes and functions, and then summarize them into a
parent/base class
. And then the
child/derived classes
can inherit from the parent/base class.
P
olymorphism
Different forms of methods
Dynamic/Runtime polymorphism
Using the same interface to implement different class and thus different objects.
Static/Compile-time polymorphism
Implementing multiple functions with same name but different arguments
Analysis
What to solve
:red_flag:Design
How to solve it
Inheritance and composition
Inheritance
Abstract: hybrid of normal functions and abstract functions
Interface: Purely without implementations
Used when
method types are shared
Aggregations: super class "use a (many)" sub classes, but the sub classes still exist after the destroy of the super class.
Concrete class
no children (cannot be extended or be inherited by)
C++ can inherit from multiple levels
Composition
"has a" or "use a" relationship
The sub classes are destroyed when the super class was destroyed
Advantanges
When the code scale up OOD and OOP will show it's power: just like writing a recipe, you can reuse the chunk of the code in the future by switching
Cake Mould
to
Muffin Mould
The ability to reuse the code
4 fundamental concepts of OOD (
APIE
): Abstraction, Polymorphism, Inheritance, Encapsulation
Procedures
Steps
Gathering Requirements
Describe the Application
Identifying the main objects
Describe the interactions
Create a class diagram
Diagrams (used in this class)
Class Diagrams
Use case diagrams
Detailed
Gathering Requirements
Concepts: Just to meet the MVP the core needs
Eliminate any kind of unnecessary design jargon)
E.g. For a microwave on space
:shallow_pan_of_food:
It (app/system) should be ...
24/7 available
Usable with gloves
How should we do it?
Legal
Security
Performance
Support
:red_flag: Functional Requirements
Heat meal in space packaging
Allow user to set time for meal to be ready
Change cooking time based on type of meal
FURPS
Functionality (what customers what)
Usability: UI/UX and documentations
Reliability: System Down time, Predictability
Performance: Speed, Efficiency
Support ability: Testability, extensible, configuraability, Serviceability
FURPS+
Design
Implementation
Interface (API, etc.)
Physical
:checkered_flag: Jukebox design challenge
Functional Requirements
Allow user to insert a quarter and play music
Allow user to switch at most three songs
Only allow to play three thoughts in a role by one user
Maintaining a library of songs and albums
Play music!
Allow users to sort by artist (no need to mention how now, like a button)
Non-functional Requirements
Must be available 24/7
Use minimum electricities
Have light on so people can be attracted by it.
Beautiful UI Design
Updatable
Use case & User stories
Rule of Thumb: don’t spend more than a few days on this
Template
Title (succinct)
Primary Actor (detail)
Detail to accomplish the gold (paragraph/List is good)
Success Scenarios + Extensions (error/unidentifiable)
Preconditions (e.g. one package at a time)
Identifying the actors
Focusing on the Goal! (By group, even different people)
Primary just means the one actor that initiate the activity, not necessarily in higher social rank
Identifying the scenarios
The goal of actors.
User focused, and success scenarios
Not likely to focusing on all the wired results.(Easy is the key)
Easy describe
Intention is the key
Diagraming use cases
Listing the use cases works
Actors
In circuses and using box to group.
Link actors with use cases with line.
On the write board is good enough at first
User stories
As a (type of user) I want (goal) so that (reason) :star:
:checkered_flag: Challange
Two use casess
Use case 1
Title: Playing music
Primary actor: space users
Scenario:
System identify user
Space user insert a quarter
User select a song
User adjust the volumn
The song play
The Jukebox stop after three songs played
Use case 2
Title: Maintaining the jukebox
Primary actor: jukebox admin
Scenario
Maintainer open the box
Maintainer insert update device
Update the songs
Close the connection setting
Two user stories
User story 1
As a space jukebox user, I want to play music at any time, so that I can enjoy everyday.
User story 2
As an admin, I want to easily update the sons, so that I can save my time on figuring out how to fix bugs and do other things.
Domain Modeling
Identifying the objects
Summarizing the nouns and remove the non-related ones
Connect the object relationships
Accurate verbs on the links
Using amount notations
Identifying class responsibilities
You don’t need to add too much behaviors to one object! (I.e. god object) in the very beginning!!!
Just go make them as premium edition.
Object should be responsible for itself, and not all into one admin/system object (god object)
CRC Card (CRH Card)
Class Name (this class)
——————————————
Responsibilities (describing the function) | Collaborators (relate with other class)
Using physical CRC card is a good idea
Naturally putting the related cards together
Constrain your intension to give too much power to one class!
:checkered_flag:Challange
Identifying the
potential object, responsibilities, and relationships
:book: Read More
Use Cases
Writing Effective Use Cases by Alistair Cockburn
Use stories applied for Agile software development
UML
UML Distilled by Martin Fowler
FURPS+ Requirements
Software Requirements by Karl Wiegers
Mastering the Requirements Process by Suzanne and James Robertson
Principles
SOLID
Open/Closed principles
Liskv substitution principles
Interface segregation principles
Dependency Inversion principles
Single responsibility principles
DRY
Don't Repeat Your Self
Small codes
YAGNI
You Ain't Gonna Need It