April 2013 Ruby Ireland POODR Talk

Slides from my talk on Sandi Metz's awesome book. Video is at http://www.rubyireland.com/poodr-talk-video.html

Transcript

1. Stay objective with POODR Sandi Metz’s Ruby Principles & when to break them Chris McGrath @chrismcg http://www.localeapp.com
2. 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.
4. 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.
5. 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.
6. Object-oriented design is about managing dependencies. It is a set of coding techniques that arrange dependencies such that objects can tolerate change.
7. 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
8. Single Responsibility Principle A class should have only one reason to change (Bob Martin) Does the smallest possible thing (Sandi Metz)
9. 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
10. 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
11. 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
12. 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
13. 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.
14. 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
15. Sequence Diagrams (!!)
16. When to use what • is-a : Inheritance • behaves-like-a: Modules (Duck Typing) • contains-a: Composition
17. Why Test? • Find bugs • Supply documentation • Defer design decisions • Support abstractions • Expose design flaws
18. 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)
19. When to test? • Spike if you need to • Use TDD or BDD for production code • Whatever you do don’t couple tests to implementation
20. 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!