Upgrade to Pro — share decks privately, control downloads, hide ads and more …

April 2013 Ruby Ireland POODR Talk

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

Chris McGrath

April 16, 2013
Tweet

More Decks by Chris McGrath

Other Decks in Programming

Transcript

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

    View Slide

  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.

    View Slide

  3. View Slide

  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.

    View Slide

  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.

    View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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.

    View Slide

  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

    View Slide

  15. Sequence Diagrams (!!)

    View Slide

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

    View Slide

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

    View Slide

  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)

    View Slide

  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

    View Slide

  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!

    View Slide