You are previewing Emergent Design: The Evolutionary Nature of Professional Software Development.
O'Reilly logo
Emergent Design: The Evolutionary Nature of Professional Software Development

Book Description

For software to consistently deliver promised results, software development must mature into a true profession. Emergent Design points the way. As software continues to evolve and mature, software development processes become more complicated, relying on a variety of methodologies and approaches. This book illuminates the path to building the next generation of software. Author Scott L. Bain integrates the best of today’s most important development disciplines into a unified, streamlined, realistic, and fully actionable approach to developing software. Drawing on patterns, refactoring, and test-driven development, Bain offers a blueprint for moving efficiently through the entire software lifecycle, smoothly managing change, and consistently delivering systems that are robust, reliable, and cost-effective.

Reflecting a deep understanding of the natural flow of system development, Emergent Design helps developers work with the flow, instead of against it. Bain introduces the principles and practices of emergent design one step at a time, showing how to promote the natural evolution of software systems over time, making systems work better and provide greater value. To illuminate his approach, Bain presents code examples wherever necessary and concludes with a complete project case study.

This book provides developers, project leads, and testers powerful new ways to collaborate, achieve immediate goals, and build systems that improve in quality with each iteration.

Coverage includes

  • How to design software in a more natural, evolutionary, and professional way

  • How to use the “open-closed” principle to mitigate risks and eliminate waste

  • How and when to test your design throughout the development process

  • How to translate design principles into practices that actually lead to better code

  • How to determine how much design is enough

  • How refactoring can help you reduce over-design and manage change more effectively

  • The book’s companion Web site, www.netobjectives.com/resources, provides updates, links to related materials, and support for discussions of the book’s content.

    Table of Contents

    1. Copyright
      1. Dedication
    2. Series Foreword: The Net Objectives Product Development Series
      1. Emergent Design: The Evolutionary Nature of Professional Software Development
      2. The End of an Old Era, the Beginning of a New One
    3. Preface
      1. Qualities
      2. Principles
      3. Practices
      4. Disciplines
      5. Patterns
      6. Processes
    4. Acknowledgments
    5. About the Author
    6. 1. Software as a Profession
      1. How Long Have Human Beings Been Making Software?
      2. What Sort of Activity Is Software Development?
      3. What Is Missing?
      4. Who Is Responsible?
      5. Uniqueness
    7. 2. Out of the Closet, Off to the Moon
      1. Patterns and Professionalism in Software Development
      2. Andrea’s Closet
      3. Off to the Moon
        1. Forces Lead to Forces
        2. Different Forces, Different Design
        3. And There Are More Contextual Forces
        4. The Costs and Benefits
        5. On to Mars
      4. The Value of Patterns
      5. Summary
    8. 3. The Nature of Software Development
      1. We Fail Too Much
      2. Definitions of Success
      3. The Standish Group
      4. Doing the Wrong Things
      5. Doing the Things Wrong
      6. Time Goes By, Things Improve
      7. One Reason: The Civil Engineering Analogy
      8. Giving Up Hope
      9. Ignoring Your Mother
      10. Bridges Are Hard, Software Is Soft
      11. We Swim in an Ocean of Change
      12. Accept Change
      13. Embrace Change
      14. Capitalize on Change
      15. A Better Analogy: Evolving Systems
      16. Summary
    9. 4. Evolution in Code: Stage 1
      1. Procedural Logic Replaced with Object Structure
      2. The Origins of Object Orientations and Patterns
      3. An Example: Simple Conditionals and the Proxy Pattern
      4. The Next Step: Either This or That
      5. Why Bother?
      6. One Among Many
      7. Summary
    10. 5. Using and Discovering Patterns
      1. Design from Context: More Carpentry from Scott
      2. Patterns Lead to Another Cognitive Perspective
      3. Patterns Help Give Us a Language for Discussing Design
      4. Patterns in This Book
      5. Summary
    11. 6. Building a Pyramid
      1. Elements of the Profession
      2. A Visual Representation
      3. Summary
    12. 7. Paying Attention to Qualities and Pathologies
      1. Encapsulation
      2. Cohesion
        1. Method Cohesion
        2. Cohesion of Perspective Level
        3. Class Cohesion
        4. How Cohesive Is Cohesive Enough?
      3. Coupling
        1. Intentional Coupling Versus Accidental Coupling
        2. Types of Coupling
      4. Redundancy
        1. Redundancy and Coupling
      5. Testability
      6. Readability
      7. Pathologies
        1. Indicators of Weak Cohesion
        2. Indicators of Accidental or Illogical Coupling
        3. Indicators of Redundancy
      8. Summary
    13. 8. Paying Attention to Principles and Wisdom
      1. Separating Use from Creation
        1. Fowler’s Perspectives
        2. Another Kind of Perspective
        3. The Perspective of Use
        4. A Separate Perspective: Creation
        5. Considering Construction Details Last
        6. The Real World
      2. The Open-Closed Principle
        1. Open-Closed at the Class Level
        2. Open-Closed at the Method Level
      3. The Dependency Inversion Principle
      4. Advice from the Gang of Four
        1. Designing to the Interface of a Method
        2. Designing to the Interface of a Class
        3. GoF: Favor Object Aggregation Over Class Inheritance
      5. GoF: Consider What Should Be Variable in Your Design and Encapsulate the Concept That Varies
      6. Summary
    14. 9. Paying Attention to Practices
      1. Consistent Coding Style
        1. Comments
        2. Naming Classes, Methods, and Variables
        3. Virtues of Coding Standards
      2. Programming by Intention
        1. Are They Really All Private?
      3. Encapsulating the Constructor
        1. Principles Versus Practices
        2. Making the Decision
      4. Commonality-Variability Analysis
      5. Practices and Freedom
      6. Summary
    15. 10. Paying Attention to Disciplines: Unit Testing
      1. Economies of Testing
        1. Unit Testing
        2. Up-Front Testing
      2. JUnit Framework
        1. JUnit Basics
        2. JUnit Examples
        3. Rule.java: Code First, Then Test
        4. RuleContainer.java: Test First, Then Code
        5. Eliminating Redundancy: @Before and @After
        6. Automating Tests in Batches
        7. Exceptions and Unit Testing
      3. Mock Objects
        1. MockObject Frameworks
        2. Faking It
        3. Dependency Injection and the Endo-Testing Technique
        4. Endo-Testing
      4. Summary
    16. 11. Paying Attention to Disciplines: Refactoring
      1. Refactoring Bad Code
      2. Refactoring Good Code
      3. Structural Changes Versus Functional Changes
      4. Refactoring Helps You Choose Your Battles
      5. Patterns Can Be Targets of Refactoring
      6. Avoiding Refactoring: Prefactoring
      7. The Mechanics of Refactoring
      8. Refactoring Legacy Code
      9. Summary
    17. 12. Test-Driven Development
      1. What Makes Development Test-Driven?
        1. Test-Driven Versus Test-First
        2. Designing from the Perspective of the Unit Test
      2. Testing and Quality
        1. Testing and Cohesion
        2. Testing and Coupling
        3. Testing and Redundancy
      3. Test-Driven Development and Patterns
        1. The Strategy Pattern
        2. Turtles All the Way Down
        3. Mock Object/Mock Turtles
      4. Mock Objects
      5. Mock Turtles
      6. Testing the Decorator Pattern
      7. Summary
    18. 13. Patterns and Forces
      1. Making Decisions in an Evolving Design
      2. Christopher Alexander and Forces
        1. The Signal Processor Example
        2. The PKZip Example
        3. Testing and Forces
      3. More Choices, More Forces
      4. Summary
    19. 14. Emergent Design: A Case Study
      1. The Problem Domain: The MWave Corporation
      2. The Teams
      3. The Simplest Thing That Could Possibly Work
      4. A New Requirement: Complex Machines
      5. Oh, By the Way
      6. More Good News
      7. Summary: What a Long, Strange Trip It Has Been
    20. 15. A Conclusion: 2020
    21. A. Evolutionary Paths
      1. Encapsulated Constructor to Singleton
      2. Programming-by-Intention to Encapsulated Constructor to Strategy (Varying on an Issue Extrinsic to the Client)
      3. Programming-by-Intention to Encapsulated Constructor to Strategy (Varying on an Issue Intrinsic to the Client)
      4. Programming-by-Intention to Encapsulated Constructor to Chain of Responsibility (Varying on an Issue Extrinsic to the Client)
      5. Programming-by-Intention to Encapsulated Constructor to Chain of Responsibility (Varying on an Issue Intrinsic to the Client)
      6. Encapsulated Construction to Strategy to Singleton (Object Factory) to Adapter/Façade
      7. Encapsulated Constructor to Proxy to Decorator with Singleton (Object Factory)
    22. B. Overview of Patterns Used in the Examples
      1. The Abstract Factory Pattern
        1. Contextual Forces
          1. Motivation
          2. Encapsulation
          3. Procedural Analog
          4. Non-Software Analog
        2. Implementation Forces
          1. Example
          2. Questions, Concerns, Credibility Checks
          3. Options in Implementation
        3. Consequent Forces
          1. Testing Issues
          2. Cost-Benefit (Gain-Loss)
      2. The Adapter Pattern
        1. Contextual Forces
          1. Motivation
          2. Encapsulation
          3. Procedural Analog
          4. Non-Software Analog
        2. Implementation Forces
          1. Example
          2. Code
          3. Questions, Concerns, Credibility Checks
          4. Options in Implementation
        3. Consequent Forces
          1. Testing Issues
          2. Cost-Benefit (Gain-Loss)
      3. The Bridge Pattern
        1. Contextual Forces
          1. Motivation
          2. Encapsulation
          3. Procedural Analog
          4. Non-Software Analog
        2. Implementation Forces
          1. Example
          2. Code
          3. Questions, Concerns, Credibility Checks
          4. Options in Implementation
        3. Consequent Forces
          1. Testing Issues
          2. Cost-Benefit (Gain-Loss)
      4. The Chain of Responsibility Pattern
        1. Contextual Forces
          1. Motivation
          2. Encapsulation
          3. Procedural Analog
          4. Non-Software Analog
        2. Implementation Forces
          1. Example
          2. Code
          3. Questions, Concerns, Credibility Checks
          4. Options in Implementation
        3. Consequent Forces
          1. Testing Issues
          2. Cost-Benefit (Gain-Loss)
        4. Chain of Responsibility: The Poker Example
      5. The Composite Pattern
        1. Contextual Forces
          1. Motivation
          2. Encapsulation
          3. Procedural Analog
          4. Non-Software Analog
        2. Implementation Forces
          1. Example
          2. Code
          3. Questions, Concerns, Credibility Checks
          4. Options in Implementation
        3. Consequent Forces
          1. Testing Issues
          2. Cost Benefit (Gain-Loss)
      6. The Decorator Pattern
        1. Contextual Forces
          1. Motivation
          2. Encapsulation
          3. Procedural Analog
          4. Non-Software Analog
        2. Implementation Forces
          1. Example
          2. Code
          3. Questions, Concerns, Credibility Checks
          4. Options in Implementation
        3. Consequent Forces
          1. Testing Issues
          2. Cost-Benefit (Gain-Loss)
      7. The Façade Pattern
        1. Contextual Forces
          1. Motivation
          2. Encapsulation
          3. Procedural Analog
          4. Non-Software Analog
        2. Implementation Forces
          1. Example
          2. Code
          3. Questions, Concerns, Credibility Checks
          4. Options in Implementation
            1. Façade is often implemented using other patterns
            2. Legacy conversion
          5. “Strangling” a Legacy System
        3. Consequent Forces
          1. Testing Issues
          2. Cost-Benefit (Gain-Loss)
          3. Façade and N-Tier Architecture
      8. The Proxy Pattern
        1. Contextual Forces
          1. Motivation
          2. Encapsulation
          3. Procedural Analog
          4. Non-Software Analog
        2. Implementation Forces
          1. Example
          2. Code
          3. Questions, Concerns, Credibility Checks
          4. Options in Implementation
        3. Consequent Forces
          1. Testing Issues
          2. Cost-Benefit (Gain-Loss)
      9. The Singleton Pattern
        1. Contextual Forces
          1. Motivation
          2. Encapsulation
          3. Procedural Analog
          4. Non-Software Analog
        2. Implementation Forces
          1. Example
          2. Code
          3. Questions, Concerns, Credibility Checks
          4. Options in Implementation
            1. Deterministic instantiation
            2. Using a synchronization semaphore
            3. Double-Checked, Locking Singleton
            4. Nested class
          5. Refactoring Issue
          6. Encapsulated Destruction
        3. Consequent Forces
          1. Testing Issues
          2. Cost-Benefit (Gain-Loss)
      10. The Strategy Pattern
        1. Contextual Forces
          1. Motivation
          2. Encapsulation
          3. Procedural Analog
          4. Non-Software Analog
        2. Implementation Forces
          1. Example
          2. Code
          3. Questions, Concerns, Credibility Checks
          4. Options in Implementation
        3. Consequent Forces
          1. Testing Issues
          2. Cost-Benefit (Gain-Loss)
      11. The Template Method
        1. Contextual Forces
          1. Motivation
          2. Encapsulation
          3. Procedural Analog
          4. Non-Software Analog
        2. Implementation Forces
          1. Example
          2. Code
          3. Questions, Concerns, Credibility Checks
          4. Options in Implementation
        3. Consequent Forces
          1. Testing Issues
          2. Cost-Benefit (Gain-Loss)
    23. C. The Principle of the Useful Illusion
      1. My View
      2. An Alternate View
    24. Bibliography