10 Object-Oriented Design Heuristics for Rubyists

Post on 08-May-2015

180 views 0 download

description

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.

Transcript of 10 Object-Oriented Design Heuristics for Rubyists

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.

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?

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.

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. !

Needs no explanation. We’ve all done it.

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

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. :)

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.

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.

ServicesReally 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.

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

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

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

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.

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.

Down the rabbit hole of Object thinking...

Free your mind

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

Object Design

DDD

Code Patterns