Principles of Package Design

Retired

This book is no longer available for sale.

723
Readers
268
Pages

English
PDF
EPUB
MOBI
APP

Last updated on 2015-01-05

About the Book

In Principles of Package Design Matthias Noback tells you everything about designing software components, also known as packages. In the first part you'll revisit the SOLID principles of class design. They will help you prepare your classes for use in packages. The second part covers the important, yet lesser known package design principles. When you've finished this book, you'll be ready to design packages that have high cohesion, low coupling and are at the same time user- and maintainer-friendly.

This book has been revised and then republished by Apress. From now on you can order it from them: https://www.apress.com/us/book/9781484241189

Share this book
Feedback
- Email the Author(s)

Matthias Noback

Matthias Noback has been building web applications since 2003. He is the author of A Year With Symfony, Principles of Package Design and Microservices for everyone. He is a regular speaker at conferences and regularly posts on his blog. While always striving for better programming practices in general, he’s taken a special interest in application architecture, Domain-Driven Design, testing, and application integration patterns.

Introduction
- The situation
- Overview of the contents
- Notes about the code samples
- Thank you
Class design
- Introduction
  - SOLID principles
  - Why follow the principles?
  - Prepare for change
- The Single responsibility principle
  - A class with too many responsibilities
  - Responsibilities are reasons to change
  - Refactoring: using collaborator classes
  - Advantages of having a single responsibility
  - A small peek ahead: common closure
- The Open/closed principle
  - A class that is closed for extension
  - Refactoring: abstract factory
  - Refactoring: making the abstract factory open for extension
  - Refactoring: polymorphism
  - Conclusion
    - Packages need classes that are open for extension
- The Liskov substitution principle
  - Violation: a derived class does not have an implementation for all methods
  - Violation: different substitutes return things of different types
  - Violation: a derived class is less permissive with regard to method arguments
  - Violation: secretly programming a more specific type
  - Conclusion
- The Interface segregation principle
  - Violation: leaky abstractions
    - Refactoring: create separate interfaces and use multiple inheritance
      - What did we do?
  - Violation: multiple use cases
    - Refactoring: separate interfaces and multiple inheritance
  - Violation: no interface, just a class
    - Implicit changes in the implicit interface
    - Refactoring: add header and role interfaces
- The Dependency inversion principle
  - Example of dependency inversion: the FizzBuzz generator
    - Making the FizzBuzz class open for extension
    - Removing the specificness from the FizzBuzz class
  - Violation: a high-level class depends upon a low-level class
    - Refactoring: abstractions and concretions both depend on abstractions
  - Violation: a class depends upon a class from another package
    - Solution: add an abstraction and remove the dependency using composition
  - Conclusion
    - Peeking ahead: abstract dependencies
Package design
- Principles of cohesion
  - - Becoming a programmer
    - The hardest part
  - Cohesion
    - Class design principles benefit cohesion
    - Package design principles, part I: Cohesion
- The Release/reuse equivalence principle
  - Keep your package under version control
  - Add a package definition file
  - Use semantic versioning
    - Design for backward compatibility
      - Rules of thumb
        
        Don’t throw anything away
        
        When you rename something, add a proxy
        
        Only add parameters at the end and with a default value
        
        Methods should not have side effects
        
        Dependency versions should be permissive
        
        Use objects instead of primitive values
        
        Use private object properties and methods for information hiding
        
        Use object factories
        
        And so on
  - Add meta files
    - README and documentation
      - Installation and configuration
      - Usage
      - Extension points
      - Limitations (optional)
    - License
    - Change log
  - Quality control
    - Quality from the user’s point of view
    - What the package maintainer needs to do
      - Add tests
  - Conclusion
- The Common reuse principle
  - Signs that the principle is being violated
    - Feature strata
      - Obvious stratification
      - Obfuscated stratification
    - Classes that can only be used when … is installed
      - Suggested refactoring
      - A package should be “linkable”
      - Cleaner releases
    - Bonus features
      - Suggested refactoring
      - Sub-packages
  - Conclusion
    - Guiding questions
    - When to apply the principle
    - When to violate the principle
    - Why not to violate the principle
- The Common closure principle
  - A change in one of the dependencies
    - Assetic
  - A change in an application layer
    - FOSUserBundle
  - A change in the business
    - Sylius
  - The tension triangle of cohesion principles
- Principles of coupling
  - Coupling
- The Acyclic dependencies principle
  - Coupling: discovering dependencies
    - Different ways of package coupling
      - Composition
      - Inheritance
      - Implementation
      - Usage
      - Creation
      - Functions
      - Not to be considered: global state
    - Visualizing dependencies
  - The Acyclic dependencies principle
    - Nasty cycles
    - Cycles in a package dependency graph
      - Dependency resolution
      - Release management
      - Is it all that bad?
  - Solutions for breaking the cycles
    - Some pseudo-cycles and their dissolution
    - Some real cycles and their dissolution
      - Dependency inversion
      - Inversion of control
        
        Mediator
        
        Chain of responsibility
        
        Mediator and chain of responsibility combined: an event system
  - Conclusion
- The Stable dependencies principle
  - Stability
  - Not every package can be highly stable
  - Unstable packages should only depend on more stable packages
  - Measuring stability
  - Decreasing instability, increasing stability
  - Violation: your stable package depends on a third-party unstable package
    - Solution: use dependency inversion
  - A package can be both responsible and irresponsible
  - Conclusion
- The Stable abstractions principle
  - Stability and abstractness
  - How to determine if a package is abstract
    - The A metric
  - Abstract things belong in stable packages
  - Abstractness increases with stability
  - The main sequence
  - Types of packages
    - Concrete, instable packages
    - Abstract, stable packages
    - Strange packages
  - Conclusion
- Conclusion
  - Creating packages is hard
    - Reuse-in-the-small
    - Reuse-in-the-large
    - Embracing software diversity
    - Component reuse is possible, but requires more work
  - Creating packages is doable
    - Reducing the impact of the first rule of three
    - Reducing the impact of the second rule of three
  - Creating packages is easy?
Appendices
- Appendix I: The full Page class

The Leanpub 45-day 100% Happiness Guarantee

Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

See full terms...

Write and Publish on Leanpub

Authors, publishers and universities use Leanpub to publish amazing in-progress and completed books and courses, just like this one. You can use Leanpub to write, publish and sell your book or course as well! Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks. Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. It really is that easy.

Learn more about writing on Leanpub