Alexander W. Winkler
Robotics researcher specialized in motion planning for legged systems.
6 Object Oriented Design Principles
Presentation built from:
- Head First Design Patterns, Bert Bates et al, 2009
- The Pragmatic Programmer, Andrew Hunt, 1999,
- Principles of OOD, Robert C. Martin, 2003 (SOLID Principles)
...to improve code architecture and higher-level code structure
The one constant in software development is change. No matter how well you design an application, over time an application must grow and change or it will die.
Often more time is spent on code after initial development is complete. So design should focus on making maintenance and extensibility easier.
EVOLVE OR DIE
Source: http://skyteach.ru/wp-content/uploads/2017/08/evolve-or-die-366x315.png
6 Design Principles are "heuristics" to follow, that increase your chances of creating flexible, reusable, and maintainable code.
Source: https://www.shutterstock.com/image-illustration/businessman-front-huge-maze-121706023
OO Basics
Inheritance
Abstraction
Polymorphism
Better Code
flexible
reusable
maintainable
OO Principles
(DRY, OCP, ...)
OO Design Patters
(Template Method,..)
1st Principle
Don't Repeat Yourself (DRY)
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
modification of any single element of a system (knowledge) does not require a change in other logically unrelated elements
→ simplifies maintenance, extensibility ☺
"It isn't a question of whether you'll remember: it's a question of when you'll forget."
- the pragmatic programmer
class Line {
public:
Point start;
Point end;
double lenght;
};class Line {
public:
Point start;
Point end;
double length()
{
return start.distanceTo(end);
};
};→ extract common code to functions and reuse
→ combine functions to classes and reuse (e.g. inheritance, composition)
void runningController()
{
readSensorData();
calculateTorqueWithMethod1();
setCommands();
}
void safetyController()
{
readSensorData();
calculateTorqueWithMethod2();
setCommands();
}class A {
public:
int a_, b_;
A() { a_=0; b_=5; };
A(int a) { a_=a; b_=5; };
}class A {
public:
int a_, b_;
A() : A(0) {};
A(int a) { a_=a; b_=5; }
}one place to modify, one place to maintain ☺
Examples: Don't Repeat Yourself (DRY)
e.g. Template Method
2nd Principle
Identify the aspects of your application that vary and separate them from what stays the same
Take what might vary (in the future!) and encapsulate it so it won’t affect the rest of your code.
(way more easily said than done!)
3rd Principle
Classes should be open for extension, but closed for modification
If your needs or requirements change, just go ahead and make your own extensions, through e.g. inheritance, composition, ...
We spent a lot of time getting this code correct and bug free, so we can’t let you alter the existing code. This reduces the chances of introducing bugs or causing unintended side effects in pre-existing code.
...a more specific way to separate the code is
Design Pattern: Template Method
"...defines the program skeleton of an algorithm in an operation, deferring some steps to subclasses."
void advanceControlLoop()
{
readSensorData();
calculateTorqueValues();
setCommands();
}
void calculateTorqueValues() = 0;Dario's Walking Controller Class
void calculateTorqueValues() override
{
// Dario's implementation
}void calculateTorqueValues() override
{
// Christian's implementation
}Marko's Skating Controller Class
This part never has to be touched again, closed, no more bugs can be introduced!
(✓)
(✓)
4th Principle
Single Responsibility Principle
A class should have only one reason to change (be rewritten)
Want to avoid changing a class like the plague because bugs creep. And when a class has two reasons to change, instead of one, it is more likely to.
...so how to write a "closed" class
2 > 1
2>1
So how can we see that a class has only a single responsibility?
Cohesion
measure of how strongly related and focused the various responsibilities of a software module are.
- all member variables used by most functions
- functions similar in what they do
Example: Do these classes have only a single responsiblity / reason to change?
5th Principle
Program to an interface, not an implementation
...since there will always be coupling to other classes (even if just one), most flexible way is through an interface
Example: Program to an Interface
Dog d = Dog();
d.bark();Animal* animal = new Dog();
animal->makeSound();Why is this better?
- Client code doesn't have to change when new animal is added ("loose coupling" between client and dog")
- Can load different implementations during runtime
"Client"
6th Principle
Favor composition over inheritance
"HAS-A" can be better/more flexible than IS-A
Example: Favor Composition over Inheritance
void RubberDuck::fly() {
// override to do nothing
}Disadvantages of Subclassing:
- Hard to generalize all duck behaviours into one interface (e.g. not all ducks should be able to fly)
- Changes can unintentionally affect other ducks (adding non-virtual method to base)
- Runtime behaviour changes are difficult
Squeaking and flying duck?
Code reuse :-)
"Strategy Pattern"
has-a
has-a
Composition:
- add new functionality by writing new code rather than altering existing code, e.g. RubberDuck (open closed principle).
- done dynamically at runtime.
The one constant in software development is change. More time is spent on code after initial development process is complete, or it will die.
- design should focus on making maintenance and extensibility easier.
- Following well-known design principles/heuristics increase chances of writing code with these characteristics.
Summary: Software Development Guidelines
Source: https://www.shutterstock.com/image-illustration/adapt-vs-fail-toggle-switch-change-176572736
(You yourself will be the most frequent user/client of your code. So you will be the one that will benefit most from proper code design.)
Outlook/Extensions: Design Patterns
Shared vocabulary for communication to convey ideas more concisely (meetings, documentation, ...)
Think at pattern level, not at nitty-gritty object level
Reuse tested code as much as possible to reduce likelihood to introduce new bugs.
Goal is to write code once, and then never have to touch it again.
End of presentation
6 Object Oriented Design Principles Presentation built from: Head First Design Patterns , Bert Bates et al, 2009 The Pragmatic Programmer, Andrew Hunt, 1999, Principles of OOD , Robert C. Martin, 2003 (SOLID Principles) ...to improve code architecture and higher-level code structure www.awinkler.me
6 Code Design Principles
By Alexander W. Winkler
6 Code Design Principles
to improve object oriented code architecture and high-level structure.
- 1,855
