09 October 2014

I recently read Practical Object-Oriented Design in Ruby by Sandi Metz. A fantastic book to help bridge the gap between theory and implementation of design. I highly recommend this book even for non Rubyists. Below are bullet points to help remember key points in the book.

  1. General

    1. Make design decisions based on what you know now.

    2. Design behavior not data.

    3. Checking types or classes indicates an opportunity for inheritance or interfaces.

    4. Inject dependencies.

    5. Use factories to centralize design that otherwise would be spread throughout multiple classes. Such as instantiating classes to be injected.

    6. Use shallow inheritance hierarchies

    7. Favor composition over inheritance when in doubt.

    8. When dependencies cannot be eliminated then they should be isolated from the rest of the code.

    9. Dependency has a direction and should be pointed toward the code least likely to change.

    10. Abstractions are less likely to change than concretions.

    11. A diagram of object interaction should look like a tree not a mesh.

    12. Use sequence diagrams to determine the classes you need.

  2. Methods

    1. Should have single responsibility

    2. Large methods indicate the need to be reduced to multiple smaller methods

    3. Many private methods indicate the possible need for a new class.

    4. Method parameter order is a dependency.

  3. Interfaces

    1. The messages sent between objects are how they interface.

    2. Interfaces are roles shared by otherwise unrelated objects.

  4. Classes

    1. Should have a single responsibility

    2. Use inheritance when classes are "is a"

    3. Use composition when classes "has a"

    4. May have roles which translate to interfaces. These roles may be implicit rather than explicit.

    5. Use dependency injection rather than explicitly using classes in other classes.

    6. Use Hashes for parameters. This helps prevent dependencies on method parameter order.

    7. Use template design pattern when using inheritance.

    8. Template design pattern should use hooks instead of using "super". User of super creates dependency.

  5. Testing

    1. Test from the general to the specific.

    2. Test only the public interface of a class.

    3. Use modules/mixins in test to verify interfaces (modules/mixins) in the code. Then include in all classes implementing interface.

    4. Use modules/mixins in test to verify super classes. These then can be included in subclasses.

    5. Use a singular module/mixin to verify subclasses act correctly in relation to super class. Then include in all subclasses.

  6. SOLID

    1. Single Responsibility

    2. Open for extension, but Closed for modification

    3. Liskov Substitution:  Subclasses stand in for parent classes

    4. Interface Segregation:  Clients should only know the methods they use.   (Adapter pattern?)

    5. Dependency Inversion

Less Is More ~ Older posts are available in the archive.