Stay objective with POODR Sandi Metz’s Ruby Principles & when to break them Chris McGrath @chrismcg http://www.localeapp.com 

Those of us whose work is to write software are incredibly lucky. Building software is a guiltless pleasure because we get to use our creative energy to get things done. We produce things that matter. 

No content

Applications that are easy to change are a pleasure to write and a joy to extend. They’re flexible and adaptable. Applications that resist change are just the opposite; every change is expensive and each makes the next cost more. 

Getting the right message to the correct target object requires that the sender of the message know things about the receiver. This knowledge creates dependencies between the two and these dependencies stand in the way of change. 

Object-oriented design is about managing dependencies. It is a set of coding techniques that arrange dependencies such that objects can tolerate change. 

Your class can be no longer than 100 LOC Your methods can be no longer than 5 LOC You can pass no more than 4 parameters Controller actions can only instantiate one object You can only pass one instance variable to a view 

Single Responsibility Principle A class should have only one reason to change (Bob Martin) Does the smallest possible thing (Sandi Metz) 

T.R.U.E. Code Transparent The consequences of change should be obvious in the code that is changing and in distant code relies upon it Reasonable The cost of any change should be proportional to the benefits the change achieves Usable Existing code should be usable in new and unexpected contexts Exemplary The code itself should encourage those who change it to perpetuate these qualities 

Your class can be no longer than 100 LOC Your methods can be no longer than 5 LOC You can pass no more than 4 parameters Controller actions can only instantiate one object You can only pass one instance variable to a view 

Design • The arrangement of the code • Defer decisions and reduce the cost of change • What is the future cost of doing nothing today? • Cost per feature over time interval that matters 

Dependency when an object • Knows the name of another class • Knows the name of a message it intends to send to someone other than self • Knows the arguments a message requires • Knows the order of those arguments 

Classes control what’s in your source code repository; messages reflect the living, animated application. Design, therefore, must be concerned with the messages that pass between objects. It deals not only with what objects know (their responsibilities) and who they know (their dependencies), but how they talk to one another. 

Public Interfaces • Reveal its primary responsibility • Are expected to be invoked by others • Will not change on a whim • Are safe for others to depend on • Are thoroughly documented in the tests 

Sequence Diagrams (!!) 

When to use what • is-a : Inheritance • behaves-like-a: Modules (Duck Typing) • contains-a: Composition 

Why Test? • Find bugs • Supply documentation • Defer design decisions • Support abstractions • Expose design flaws 

What to test? • Test incoming messages • Test command messages are sent • Don’t test query messages • Don’t test private messages (unless you have to) 

When to test? • Spike if you need to • Use TDD or BDD for production code • Whatever you do don’t couple tests to implementation 

Thanks! Sandi will be speaking at La Conf in Paris 9-10 May http://2013.la-conf.org 3 course meals, wine tastings, really great speakers 20% Discount Code: RubyIreland Thanks Intercom! Intercom are hiring - We’re not allowed to leave until someone agrees to work for them!