Elegant objects in W2MO

1.

“Elegant objects” in W2MO
it’s all about maintain pain-ability
© 2010-2016 Logivations GmbH. All Rights Reserved
1

2.

Objects vs data structure
- Data structure - access data directly
- Object - communicate to it
Data structure usage:
Object usage:
© 2010-2016 Logivations GmbH. All Rights Reserved
2

3.

Data structure maintenance:
Object maintenance:
© 2010-2016 Logivations GmbH. All Rights Reserved
3

4.

Choose names carefully
• objects must be characterized by their capabilities. Name objects considering what they are and
not what they do.
"Suffix -er is evil ingredient"
CommonGraphBuilder -> CommonGraphs
• 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){/*....*/}
• 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"
© 2010-2016 Logivations GmbH. All Rights Reserved
4

5.

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
© 2010-2016 Logivations GmbH. All Rights Reserved
5

6.

Small and simple objects
"So what we get from making classes small? The
answer is elegance, maintainability, cohesiveness,
and testability "
-
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
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.”
© 2010-2016 Logivations GmbH. All Rights Reserved
6

7.

Object’s life
- always use interfaces
- keep interfaces short; use smarts
© 2010-2016 Logivations GmbH. All Rights Reserved
7

8.

Object’s life
- be immutable
- always be immutable
- be either final or abstract
© 2010-2016 Logivations GmbH. All Rights Reserved
8

9.

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.”
© 2010-2016 Logivations GmbH. All Rights Reserved
9

10.

Object’s testing
- write tests instead of documentation
- don’t mock; use fakes
© 2010-2016 Logivations GmbH. All Rights Reserved
10

11.

“The reality, in general, is much less elegant than
practices described in this book.
However, we can change it - the reality, not the book ;)
© 2010-2016 Logivations GmbH. All Rights Reserved
11

12.

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.
© 2010-2016 Logivations GmbH. All Rights Reserved
12

13.

Decorator UML
© 2010-2016 Logivations GmbH. All Rights Reserved
13

14.

Decorator example
© 2010-2016 Logivations GmbH. All Rights Reserved
14