oop-design
OOP Design
Writing a program to do something is the first and easy part, writing it and change it (refactoring it) with good design and knowing the trade offs is different.
The only constant in application is change. That is why the soft is in software. To make change easy/fast/efficient/cheap we need software to be designed with this in mind. Software design helps with making the software more readable/maintainable/extendable with out increasing costs or time for reading/maintaining/extending.
a lot of what writing good code is about comes down to making proper use of abstraction levels, and deciding which abstractions to put in place is the first step to a good design.
Improving OO design or any software design is to keep software soft.
why?
May result in lower total cost of ownership (TCO) for a longer-lived system
May allow the business to be more agile (responding more quickly to changing marketplace conditions)
May result in happier development teams (which in turn,may increase productivity and reduce staff turnover)
ultimately it is the code that must be transformed from its current state to a new state to support the goals of the organisation or users.
Use of diagramming and planning
UML
Sequence diagrams
Big picture - full process of an application
single flow
Architectrual diagrams
team apps including 3rd party/ database/ filesystems
full service - all apps that provide all the services
OO features
Using an OO programming language does not mean that you are programming in a OO style. Sometimes you will use a procedural style. Knowing the features and using them will help in taking advantage of the benefits of OO.
Polymorpshism
Encapsulation
Abstraction
inheritence
Object-oriented programming, there’s basically three main concepts.
There are objects, which hold state and accept messages,
there are the messages that are sent between objects, and
there are the methods, which are the code that runs when the message is received.
In this way, you create this network of objects that communicate with each other. The computation happens through the dispatch of different messages and what each object does with the messages it receives
Design Principles
Implementing these design principles to have better code
Use SOLID principles (See below)
high cohesion
low coupling
separation of concerns
YAGNI
DRY
Avoid Duplication
Tell, dont ask
law of demeter
dependency injection
composition over inheritence
code to interface
inversion of control
Let the compiler pick up on errors
use Generics
Anything from effective java
Comment on the why, not the why
Compose method with other methods
Links
SOLID Principles
SRP - Single Responsibility Principle
OCP - Open Closed PRincple
LSP - Liskov Substitution Pricinple
ISP - Interface Segregation Principle
DIP - Dependency Inversion Principle
Object Design Rules
Not be all rules
just a set of practices that make you think when coding
Rules for good OO design
One level of indentation per method
Don’t use the ELSE keyword
guard clause
Polymorpshism
Wrap all primitives and Strings
First class collections
only one field with the collection
One dot per line
law of demeter
Don’t abbreviate
Keep all entities small (50 lines classes, methods 7 lines)
No classes with more than two instance variables
No getters/setters/properties
tell dont ask
should not get info from getter to do something else with it or extract something else. This should be the responsiblity of the object the getter is from, ie a new method that can encapsulate this
Links and Books
links
Last updated
Was this helpful?