This is a talk I gave to our Dev group to help promote better object-oriented coding with Ruby. There's less code than I would have liked (deadlines, deadlines), but most points should be clear enough. The heuristics have been take from the book, "Object-Oriented Design Heuristics" by Arthur Riel in 1996. I curated the few that would resonate with our team; those that focus on better public APIs and being mindful of coupling. The slides lose a little bit of meaning without my narration, so your mileage may vary.

5. You want to encapsulate at all times.
This initializer is focused on initialization. Setters
guard their respective attributes (e.g. in this case,
legal values for gender and status).
Hide direct attribute access even within the class.

8. Public API should be
useful without
having to view
implementation
details.
If this is not the
case, improve your
method signatures.
!
How often do you
look at public API
method
implementations
offered by Gems?

9. Why do you people
indent private and
protected methods?
When followed
consistently by a
team, developers
then know indented
code is likely the
implementation
details of a class.

10. Modules and
concerns seem
convenient, but
there are some
cons.
They require
reviewing an out of
view file to know the
API.
!
Spurious methods
can enter into the
API.
!
Alternative:
!
Consider class-based composition.
!

12. Needs no explanation. We’ve all done it.

14. Export coupling. FeedingTube is coupled to a receiver
role which is played by the SlaveHuman instance.

15. Nil coupling. No coupling, but you better have two
instances or your program is uninteresting.
!
Or consider String or Math classes as better examples
of nil coupling; the above example could be argued as
coupled. :)

17. Beware of methods on a class that seem
to be using accessors or methods of another
class and few of its own.
!
You may be writing a method that belongs on
that other class.
!
Changes there may break you here.

19. There could be some argument here if a SlaveHuman
is really just a role that a Human plays.
!
The decision hinges on new and different behavior.
This model implies that the Human doesn’t digest
food.
This is not true in the real world, but our model need
only apply to the problem domain.

21. Services
Really en vogue now. Extract it to a service!
A service should mediate between classes only when it
makes no sense for any one of them to do so
themselves. Consider whether one class has
authoritative knowledge before separating out to a
service.
Lots of services yield an anemic object model; classes
are stripped of behavior they should own.
Services are great, just be sure you’ve thought it through.

23. Problem
A room requires heat when its temperature is
greater than 72 and occupied.
!
How shall we code it?

24. Often seen. LeakyRoom leaks its details to allow
the GodFurnace to take on too much responsibility.

25. Well-place responsibilities. Did it all start with
discipline at the public API level?

27. God Classes
• There are two kinds of God classes:
• One that performs services by orchestrating
object collaborations. Less data, more
methods.
• One that contains data that others need.
Fewer methods, lots of data.

29. Sometimes the real world is the wrong thing to model
after.
!
In this case, the building is more authoritative on
targeting and damage, so the messaging is flipped.
!
The wonderful thing about O-O design is that you get
to create your own world which abides by your laws of
physics.

30. Down the rabbit hole of
Object thinking...

31. Free your mind

32. Tank, we need more
O-O KNOWLEDGE
programs...

33. Object Design

34. DDD

35. Code Patterns