10 Object-Oriented Design Heuristics for Rubyists

36

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

Page 1: 10 Object-Oriented Design Heuristics for Rubyists
Page 2: 10 Object-Oriented Design Heuristics for Rubyists
Page 3: 10 Object-Oriented Design Heuristics for Rubyists
Page 4: 10 Object-Oriented Design Heuristics for Rubyists
Page 5: 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.

Page 6: 10 Object-Oriented Design Heuristics for Rubyists
Page 7: 10 Object-Oriented Design Heuristics for Rubyists
Page 8: 10 Object-Oriented Design Heuristics for Rubyists

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?

Page 9: 10 Object-Oriented Design Heuristics for Rubyists

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.

Page 10: 10 Object-Oriented Design Heuristics for Rubyists

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

Page 11: 10 Object-Oriented Design Heuristics for Rubyists
Page 12: 10 Object-Oriented Design Heuristics for Rubyists

Needs no explanation. We’ve all done it.

Page 13: 10 Object-Oriented Design Heuristics for Rubyists
Page 14: 10 Object-Oriented Design Heuristics for Rubyists

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

Page 15: 10 Object-Oriented Design Heuristics for Rubyists

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

Page 16: 10 Object-Oriented Design Heuristics for Rubyists
Page 17: 10 Object-Oriented Design Heuristics for Rubyists

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.

Page 18: 10 Object-Oriented Design Heuristics for Rubyists
Page 19: 10 Object-Oriented Design Heuristics for Rubyists

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.

Page 20: 10 Object-Oriented Design Heuristics for Rubyists
Page 21: 10 Object-Oriented Design Heuristics for Rubyists

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.

Page 22: 10 Object-Oriented Design Heuristics for Rubyists
Page 23: 10 Object-Oriented Design Heuristics for Rubyists

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

Page 24: 10 Object-Oriented Design Heuristics for Rubyists

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

Page 25: 10 Object-Oriented Design Heuristics for Rubyists

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

Page 26: 10 Object-Oriented Design Heuristics for Rubyists
Page 27: 10 Object-Oriented Design Heuristics for Rubyists

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.

Page 28: 10 Object-Oriented Design Heuristics for Rubyists
Page 29: 10 Object-Oriented Design Heuristics for Rubyists

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.

Page 30: 10 Object-Oriented Design Heuristics for Rubyists

Down the rabbit hole of Object thinking...

Page 31: 10 Object-Oriented Design Heuristics for Rubyists

Free your mind

Page 32: 10 Object-Oriented Design Heuristics for Rubyists

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

Page 33: 10 Object-Oriented Design Heuristics for Rubyists

Object Design

Page 34: 10 Object-Oriented Design Heuristics for Rubyists

DDD

Page 35: 10 Object-Oriented Design Heuristics for Rubyists

Code Patterns

Page 36: 10 Object-Oriented Design Heuristics for Rubyists