Elegant objects in W2MO

Слайд 2

Objects vs data structure Data structure - access data directly Object

Objects vs data structure

Data structure - access data directly

Object - communicate

to it

Data structure usage:

Object usage:

Слайд 3

Data structure maintenance: Object maintenance:

Data structure maintenance:

Object maintenance:

Слайд 4

Choose names carefully builders are nouns, manipulators are verb (exception: boolean

Choose names carefully

builders are nouns, manipulators are verb (exception: boolean method)

void

addEdgesToGraph(Graph graph, Edge edge) {/*....*/} Edge edge(String edgeId) {/*....*/}

int save(long bytes){/*....*/} -> int bytesSaved(long bytes){/*....*/}

CommonGraphBuilder -> CommonGraphs

do not use prefixes like get-, set-

"Mutability, method names, and a complete absence of constructors are nothing compared to the much bigger sin this class is guilty of. It is not class, but rather data structure. And this sin can't be forgiven. Amen"

objects must be characterized by their capabilities. Name objects considering what they are and not what they do. "Suffix -er is evil ingredient"

Слайд 5

Object’s birth Make as many constructors as possible and one primary

Object’s birth

Make as many constructors as possible and one primary constructor:
to

be able to construct an instance of class in many different ways;
to avoid code duplication;
- Keep constructors code-free

Example: CaseTypeProduct

Слайд 6

Small and simple objects encapsulate as little as possible but something

Small and simple objects

encapsulate as little as possible but something at

the very least
expose fewer then five public methods (not including constructors, private methods)
don’t use static methods
don’t use public constants

"So what we get from making classes small? The answer is elegance, maintainability, cohesiveness, and testability "

Bad example

“We shouldn’t have to know about such things as static keywords in Java, but alas, we have them. I don’t know who exactly authored them in OOP, but they are pure evil. The static methods, not the authors. I hope.”

Слайд 7

Object’s life always use interfaces keep interfaces short; use smarts

Object’s life

always use interfaces
keep interfaces short; use smarts

Слайд 8

Object’s life be immutable always be immutable be either final or abstract

Object’s life

be immutable
always be immutable
be either final or abstract

Слайд 9

Object’s life try to avoid null references (null arguments) avoid casting

Object’s life

try to avoid null references (null arguments)
avoid casting

“Why might we

need to have an object of class User without a name being initialized? Seriously, when and why might we have such a necessity? I think I know the answer. In most cases, this happens when we need another class, but we are to lazy to create it.”
Слайд 10

Object’s testing write tests instead of documentation don’t mock; use fakes

Object’s testing
write tests instead of documentation
don’t mock; use fakes

Слайд 11

“The reality, in general, is much less elegant than practices described

“The reality, in general, is much less elegant than practices described

in this book.
However, we can change it - the reality, not the book ;)
Слайд 12

Decorator pattern The decorator pattern (also known as Wrapper) is a

Decorator pattern

The decorator pattern (also known as Wrapper) is a design

pattern that allows behavior to be added to an individual object, either statically or dynamically, without affecting the behavior of other objects from the same class.
Key use cases:
- add/remove additional functionalities/responsibilities dynamically
- avoid too much of sub-classing to add additional responsibilities.
Drawbacks:
overuse of Open Closed principle ( Open for extension and Closed for modification). Use this feature sparingly where the code is least likely changed.
Слайд 13

Decorator UML

Decorator UML