Software Design for Python Programmers: Principles and patterns

Software Design for Python Programmers....1 brief contents....5 contents....7 preface....14 acknowledgments....16 about this book....18 Who should read this book?....18 How this book is organized: A roadmap....18 About the code....19 liveBook discussion forum....20 about the author....21 about the cover illustration....22 Part 1 Introduction....23 1 The path to well-designed software....25 1.1	What is software design?....26 1.2	What you will learn from this book....27 1.3	The benefits of good software design....27 1.4	A few design examples....29 1.4.1	Leaking changes....29 1.4.2	Code thats too complex....30 1.4.3	Inflexible code....32 1.4.4	Surprise!....32 1.4.5	Common architecture problems....33 1.5	Make sure were going to build the right application; then, build it right....34 1.6	Good design doesnt come easily....34 1.7	Change and complexity are the enemies of good design....35 1.8	Design with object-oriented programming concepts....35 1.9	What about AI-generated code?....36 2 Iterate to achieve good design....38 2.1	Good application design requires an iterative process....39 2.2	Dont let changes leak out....41 2.3	Iterate to achieve good design....41 2.3.1	Iteration 1: Initial cohesive classes....43 2.3.2	Iteration 2: Encapsulation, delegation, and loose coupling....49 2.3.3	Iteration 3: More kinds of books and their attributes....54 2.3.4	Iteration 4: A better design after backtracking....61 Part 2 Design the right application ....71 3 Get requirements to build the right application....73 3.1	The overture to application design....74 3.2	Functional requirements: What must the application do?....75 3.3	Nonfunctional requirements: Constraints on the application....76 3.4	How to get requirements....77 3.4.1	A short requirements case study....78 3.4.2	Stated and implied requirements....79 3.5	Unified Modeling Language diagrams for creating and documenting design....80 3.6	Use cases provide context for the requirements....81 3.6.1	UML use case diagram....81 3.6.2	Use case description....82 3.7	The functional specification and software validation....84 3.8	Where do classes come from?....86 3.8.1	Textual analysis: Nouns can become classes....87 3.8.2	Textual analysis: Verbs can become methods....88 4 Good class design to build the application right....90 4.1	When do we do application design?....91 4.2	Two important goals for good class design....92 4.2.1	Cohesion and the Single Responsibility Principle....92 4.2.2	Loose coupling and the Principle of Least Knowledge....95 4.3	UML class diagrams to document class design....97 4.3.1	Dependency: The most basic relationship....99 4.3.2	Aggregation and composition: Objects that contain other objects....100 4.3.3	Generalization: Superclasses and their subclasses....101 4.3.4	Abstract classes and interfaces: What subclasses must implement....101 4.4	UML state diagram: How an object changes state....109 4.5	UML sequence diagram: How objects interact [optional]....109 4.6	The design specification and software verification....112 Part 3 Design the application right ....115 5 Hide class implementations....117 5.1	The Principle of Least Knowledge and hidden implementations....118 5.2	Public getter and setter methods access hidden implementation selectively....119 5.3	Class Date: A case study of implementation hiding....122 5.3.1	Iteration 1: Date arithmetic with loops....123 5.3.2	Iteration 2: Julian day numbers simplify date arithmetic....128 5.3.3	Iteration 3: A hybrid approach with lazy evaluation....132 5.4	Public setter methods carefully modify hidden implementation....134 5.5	Beware of dangerous setter methods....136 5.6	Rules from the Law of Demeter support the Principle of Least Knowledge....138 5.7	But is the implementation really hidden?....139 5.8	The Open-Closed Principle supports code stability....142 6 Dont surprise your users....147 6.1	No surprises and the Principle of Least Astonishment....148 6.1.1	Off-by-one errors....148 6.1.2	Misnamed functions can mislead their callers....151 6.2	Poor performance is an unwelcome surprise....153 6.2.1	Bad design can cause unexpected performance problems....153 6.2.2	Performance surprises of lists, tuples, and arrays....154 6.3	Programming by contract helps eliminate surprises [optional]....159 6.3.1	Programming a circular buffer by contract....160 6.3.2	Precondition: What must be true before calling a method or function....163 6.3.3	Postcondition: What must be true after returning from a function....164 6.3.4	Class invariant: What must remain true of object states....165 7 Design subclasses right....168 7.1	When to override and when to overload methods....169 7.1.1	Override superclass methods to get subclass behavior....169 7.1.2	Type hints and method overriding....171 7.1.3	Overload methods that have similar or equivalent behaviors....172 7.1.4	Overloading with multimethod and type hints....177 7.2	The Liskov Substitution Principle and proper subclasses....179 7.3	Choosing the is-a and has-a relationships....183 7.3.1	Using is-a....184 7.3.2	Using is-a with multiple inheritance....186 7.3.3	Using has-a....189 7.4	Use a factory function with the Code to the Interface Principle ....194 7.5	Programming by contract with subclasses [optional] ....196 Part 4 Design patterns solve application architecture problems....203 8 The Template Method and Strategy Design Patterns....207 8.1	The Template Method Design Pattern defines the steps of an algorithm....208 8.1.1	Desired design features....210 8.1.2	Before using the Template Method Design Pattern....210 8.1.3	After using the Template Method Design Pattern....216 8.1.4	Template Methods generic model....219 8.2	The Strategy Design Pattern encapsulates algorithms....220 8.2.1	Desired design features....221 8.2.2	Before using the Strategy Design Pattern....221 8.2.3	After using the Strategy Design Pattern....224 8.2.4	Strategys generic model....229 8.3	Choosing between Template Method and Strategy ....229 9 The Factory Method and Abstract Factory Design Patterns....231 9.1	The Factory Method Design Pattern lets subclasses create objects....232 9.1.1	Desired design features....232 9.1.2	Before using Factory Method....232 9.1.3	After using Factory Method....237 9.1.4	Factory Methods generic model....241 9.2	The Abstract Factory Design Pattern creates families of objects....242 9.2.1	Before using Abstract Factory....242 9.2.2	After using Abstract Factory....242 9.2.3	Abstract Factorys generic model....247 9.3	Choosing between Factory Method and Abstract Factory....249 10 The Adapter and Faade Design Patterns....250 10.1	The Adapter Design Pattern integrates code....251 10.1.1	Desired design features....251 10.1.2	Before using Adapter....252 10.1.3	After using Adapter ....256 10.1.4	Adapters generic model....260 10.1.5	An alternative Adapter model....260 10.2	The Faade Design Pattern hides a subsystem of interfaces....263 10.2.1	Desired design features....264 10.2.2	Before using Faade....264 10.2.3	After using Faade....266 10.2.4	Faades generic model....269 10.3	Choosing between Adapter and Faade....270 11 The Iterator and Visitor Design Patterns....271 11.1 The Iterator Design Pattern: One algorithm operates on different sequential data collections....272 11.1.1	Desired design features....273 11.1.2	Before using Iterator....274 11.1.3	After using Iterator....278 11.1.4	Iterators generic model....284 11.2	The Visitor Design Pattern: Different algorithms operate on a single data collection....285 11.2.1	Desired design features....288 11.2.2	Before using Visitor ....288 11.2.3	After using Visitor....293 11.2.4	Visitors generic model....302 11.3	Choosing between Iterator and Visitor....304 12 The Observer Design Pattern....305 12.1	The Observer Design Pattern: Publish data for multiple subscribers....306 12.1.1	Desired design features....308 12.1.2	Before using Observer ....308 12.1.3	After using Observer ....314 12.1.4	The Observers generic model....322 13 The State Design Pattern....324 13.1	The State Design Pattern models state transitions....325 13.1.1	Desired design features....330 13.1.2	Before using State....331 13.1.3	After using State....340 13.1.4	States generic model....350 13.2	Choosing between State and Visitor....351 14 The Singleton, Composite, and Decorator Design Patterns....352 14.1	The Singleton Design Pattern ensures that a class has only one object....353 14.1.1	Desired design features....353 14.1.2	Before using Singleton....353 14.1.3	After using Singleton....356 14.1.4	Singletons generic model....360 14.2	The Composite Design Pattern: Treat individual and composite objects uniformly....361 14.2.1	Desired design features....362 14.2.2	Before using Composite....362 14.2.3	After using Composite....368 14.2.4	Composites generic model....373 14.3	The Decorator Design Pattern: Dynamically add object responsibilities....374 14.3.1	Desired design features....374 14.3.2	Before using Decorator....375 14.3.3	After using Decorator....377 14.3.4	Decorators generic model....382 Part 5 Additional design techniques....385 15 Designing solutions with recursion and backtracking....387 15.1	Recursion compared to the for loop....388 15.2	Finding the largest value in a list by recursion....389 15.3	Reversing a list with recursion....390 15.4	Solving the Towers of Hanoi puzzle by recursion....392 15.5	Recursive algorithms for a binary search tree ....395 15.5.1	Inserting into a BST with recursion....397 15.5.2	Printing a BST with recursion....398 15.6	Quicksorting a list with recursion....400 15.6.1	Quicksort in action....401 15.6.2	Partitioning a list into sublists....402 15.6.3	Quicksort implementation....405 15.7	The Fibonacci sequence and a recursion disaster....408 15.8	Dynamic backtracking increases the power of recursion....410 15.9	Solving the eight queens puzzle with recursion and backtracking....411 15.10	Solving Sudoku puzzles with recursion and backtracking....415 16 Designing multithreaded programs....421 16.1	How do things happen simultaneously?....422 16.2	A mutex enforces mutual exclusion....424 16.2.1	Protect the integrity of a shared printing resource....425 16.3	A semaphore accepts multiple threads....431 16.3.1	The classic reader–writer problem....431 16.4	Condition objects synchronize threads....440 16.4.1	How condition objects synchronize threads....441 16.4.2	The classic producer–consumer problem....442 16.5	A final note on multithreading....449 index....451