Software Design for Python Programmers Principles and patterns (Ronald Mak)（Z-Library）

M A N N I N G Ronald Mak Principles and patterns

Design principles and design patterns covered in this book Design principles Principle Section Class Invariant Principle A given condition for an object must remain true as it changes state during run time. 6.3.4 Code to the Interface Principle Use polymorphism during run time to determine the method of which sub- class to call. 2.3.3 Delegation Principle A class should delegate a task to another class that is better suited to per- form the task. 2.3.2 Don’t Repeat Yourself (DRY) Principle Avoid duplicate code. 2.3.3 Encapsulate What Varies Principle Encapsulate code that can vary during development to prevent changes from affecting other code. 2.3.2 Factory Principle Encapsulate object creation in a separate factory function or method. 7.4 Favor Composition over Inheritance Principle The “has-a” relationship is often better than the “is-a” relationship between classes. 7.3.3 Law of Demeter This is another name for the Principle of Least Knowledge. 5.6 Lazy Evaluation Principle Make an expensive calculation only at the time it is needed. 5.3.3 Liskov Substitution Principle A superclass and its subclasses are properly designed if it’s logically possible to replace a superclass instance with a subclass instance. 7.2 Open-Closed Principle Close a class for modification, but allow its subclasses to vary during development. 2.3.3 Postcondition Principle A given condition must be true upon return from calling a function or method. 6.3.3 Precondition Principle A given condition must be true before calling a function or method. 6.3.2 Principle of Least Astonishment Don’t write code that can surprise another developer or has surprising run- time behavior. 6.1 Principle of Least Knowledge A class should make public only its components that other classes need to know. 2.3.2 Single Responsibility Principle Each class should have a single responsibility. 2.3.1 Note: Design patterns are listed on the inside back cover.

MANN I NG Shelter ISland Ronald Mak Software Design for Python Programmers Principles and patterns

For online information and ordering of this and other Manning books, please visit www.manning.com. The publisher offers discounts on this book when ordered in quantity. For more information, please contact Special Sales Department Manning Publications Co. 20 Baldwin Road PO Box 761 Shelter Island, NY 11964 Email: orders@manning.com © 2026 Manning Publications Co. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid- free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine. ∞ Manning Publications Co. 20 Baldwin Road PO Box 761 Shelter Island, NY 11964 ISBN 9781633439498 Printed in the United States of America The author and publisher have made every effort to ensure that the information in this book was correct at press time. The author and publisher do not assume and hereby disclaim any liability to any party for any loss, damage, or disruption caused by errors or omissions, whether such errors or omissions result from negligence, accident, or any other cause, or from any usage of the information herein. Development editor: Marina Michaels Technical editor: Thomas Anthony Holdroyd Review editor: Dunja NikitoviÊ Production editor: Andy Marinkovich Copy editor: Tiffany Taylor Proofreader: Jason Everett Technical proofreader: Steven Lott Typesetter: Tamara ŠveliÊ SabljiÊ Cover designer: Marija Tudor

iii brief contents Part 1 Introduction................................................................1 1 ■ The path to well-designed software 3 2 ■ Iterate to achieve good design 16 Part 2 Design the right application .................................49 3 ■ Get requirements to build the right application 51 4 ■ Good class design to build the application right 68 Part 3 Design the application right .................................93 5 ■ Hide class implementations 95 6 ■ Don’t surprise your users 125 7 ■ Design subclasses right 146 Part 4 Design patterns solve application architecture ... problems .................................................................. 181 8 ■ The Template Method and Strategy Design Patterns 185 9 ■ The Factory Method and Abstract Factory Design Patterns 209 10 ■ The Adapter and Façade Design Patterns 228 11 ■ The Iterator and Visitor Design Patterns 249

iv brief contents 12 ■ The Observer Design Pattern 283 13 ■ The State Design Pattern 302 14 ■ The Singleton, Composite, and Decorator Design Patterns 330 Part 5 Additional design techniques ............................... 363 15 ■ Designing solutions with recursion and backtracking 365 16 ■ Designing multithreaded programs 399

v contents preface xii acknowledgments xiv about this book xvi about the author xix about the cover illustration xx Part 1 Introduction .................................................1 1 The path to well-designed software 3 1.1 What is software design? 4 1.2 What you will learn from this book 5 1.3 The benefits of good software design 5 1.4 A few design examples 7 Leaking changes 7  ■  Code that’s too complex 8  ■  Inflexible code 10  ■  Surprise! 10  ■  Common architecture problems 11 1.5 Make sure we’re going to build the right application; then, build it right 12 1.6 Good design doesn’t come easily 12 1.7 Change and complexity are the enemies of good design 13 1.8 Design with object-oriented programming concepts 13 1.9 What about AI-generated code? 14

vi contents 2 Iterate to achieve good design 16 2.1 Good application design requires an iterative process 17 2.2 Don’t let changes leak out 19 2.3 Iterate to achieve good design 19 Iteration 1: Initial cohesive classes 21  ■  Iteration 2: Encapsulation, delegation, and loose coupling 27 Iteration 3: More kinds of books and their attributes 32 Iteration 4: A better design after backtracking 39 Part 2 Design the right application ...................49 3 Get requirements to build the right application 51 3.1 The overture to application design 52 3.2 Functional requirements: What must the application do? 53 3.3 Nonfunctional requirements: Constraints on the application 54 3.4 How to get requirements 55 A short requirements case study 56  ■  Stated and implied requirements 57 3.5 Unified Modeling Language diagrams for creating and documenting design 58 3.6 Use cases provide context for the requirements 59 UML use case diagram 59  ■  Use case description 60 3.7 The functional specification and software validation 62 3.8 Where do classes come from? 64 Textual analysis: Nouns can become classes 65 Textual analysis: Verbs can become methods 66 4 Good class design to build the application right 68 4.1 When do we do application design? 69 4.2 Two important goals for good class design 70 Cohesion and the Single Responsibility Principle 70 Loose coupling and the Principle of Least Knowledge 73 4.3 UML class diagrams to document class design 75 Dependency: The most basic relationship 77  ■  Aggregation and composition: Objects that contain other objects 78

viicontents Generalization: Superclasses and their subclasses 79  ■  Abstract classes and interfaces: What subclasses must implement 79 4.4 UML state diagram: How an object changes state 87 4.5 UML sequence diagram: How objects interact [optional] 87 4.6 The design specification and software verification 90 Part 3 Design the application right ...................93 5 Hide class implementations 95 5.1 The Principle of Least Knowledge and hidden implementations 96 5.2 Public getter and setter methods access hidden implementation selectively 97 5.3 Class Date: A case study of implementation hiding 100 Iteration 1: Date arithmetic with loops 101  ■  Iteration 2: Julian day numbers simplify date arithmetic 106  ■  Iteration 3: A hybrid approach with lazy evaluation 110 5.4 Public setter methods carefully modify hidden implementation 112 5.5 Beware of dangerous setter methods 114 5.6 Rules from the Law of Demeter support the Principle of Least Knowledge 116 5.7 But is the implementation really hidden? 117 5.8 The Open-Closed Principle supports code stability 120 6 Don’t surprise your users 125 6.1 No surprises and the Principle of Least Astonishment 126 Off-by-one errors 126  ■  Misnamed functions can mislead their callers 129 6.2 Poor performance is an unwelcome surprise 131 Bad design can cause unexpected performance problems 131 Performance surprises of lists, tuples, and arrays 132 6.3 Programming by contract helps eliminate surprises [optional] 137 Programming a circular buffer by contract 138  ■  Precondition: What must be true before calling a method or function 141 Postcondition: What must be true after returning from a function 142 Class invariant: What must remain true of object states 143

viii contents 7 Design subclasses right 146 7.1 When to override and when to overload methods 147 Override superclass methods to get subclass behavior 147 Type hints and method overriding 149  ■  Overload methods that have similar or equivalent behaviors 150  ■  Overloading with multimethod and type hints 155 7.2 The Liskov Substitution Principle and proper subclasses 157 7.3 Choosing the is-a and has-a relationships 161 Using is-a 162  ■  Using is-a with multiple inheritance 164 Using has-a 167 7.4 Use a factory function with the Code to the Interface Principle 172 7.5 Programming by contract with subclasses [optional] 174 Part 4 Design patterns solve application ............. architecture problems .......................... 181 8 The Template Method and Strategy Design Patterns 185 8.1 The Template Method Design Pattern defines the steps of an algorithm 186 Desired design features 188  ■  Before using the Template Method Design Pattern 188  ■  After using the Template Method Design Pattern 194  ■  Template Method’s generic model 197 8.2 The Strategy Design Pattern encapsulates algorithms 198 Desired design features 199  ■  Before using the Strategy Design Pattern 199  ■  After using the Strategy Design Pattern 202 Strategy’s generic model 207 8.3 Choosing between Template Method and Strategy 207 9 The Factory Method and Abstract Factory Design Patterns 209 9.1 The Factory Method Design Pattern lets subclasses create objects 210 Desired design features 210  ■  Before using Factory Method 210 After using Factory Method 215  ■  Factory Method’s generic model 219

ixcontents 9.2 The Abstract Factory Design Pattern creates families of objects 220 Before using Abstract Factory 220  ■  After using Abstract Factory 220  ■  Abstract Factory’s generic model 225 9.3 Choosing between Factory Method and Abstract Factory 227 10 The Adapter and Façade Design Patterns 228 10.1 The Adapter Design Pattern integrates code 229 Desired design features 229  ■  Before using Adapter 230 After using Adapter 234  ■  Adapter’s generic model 238 An alternative Adapter model 238 10.2 The Façade Design Pattern hides a subsystem of interfaces 241 Desired design features 242  ■  Before using Façade 242 After using Façade 244  ■  Façade’s generic model 247 10.3 Choosing between Adapter and Façade 248 11 The Iterator and Visitor Design Patterns 249 11.1 The Iterator Design Pattern: One algorithm operates on different sequential data collections 250 Desired design features 251  ■  Before using Iterator 252 After using Iterator 256  ■  Iterator’s generic model 262 11.2 The Visitor Design Pattern: Different algorithms operate on a single data collection 263 Desired design features 266  ■  Before using Visitor 266 After using Visitor 271  ■  Visitor’s generic model 280 11.3 Choosing between Iterator and Visitor 282 12 The Observer Design Pattern 283 12.1 The Observer Design Pattern: Publish data for multiple subscribers 284 Desired design features 286  ■  Before using Observer 286 After using Observer 292  ■  The Observer’s generic model 300 13 The State Design Pattern 302 13.1 The State Design Pattern models state transitions 303 Desired design features 308  ■  Before using State 309 After using State 318  ■  State’s generic model 328 13.2 Choosing between State and Visitor 329

x contents 14 The Singleton, Composite, and Decorator Design Patterns 330 14.1 The Singleton Design Pattern ensures that a class has only one object 331 Desired design features 331  ■  Before using Singleton 331 After using Singleton 334  ■  Singleton’s generic model 338 14.2 The Composite Design Pattern: Treat individual and composite objects uniformly 339 Desired design features 340  ■  Before using Composite 340 After using Composite 346  ■  Composite’s generic model 351 14.3 The Decorator Design Pattern: Dynamically add object responsibilities 352 Desired design features 352  ■  Before using Decorator 353 After using Decorator 355  ■  Decorator’s generic model 360 Part 5 Additional design techniques ................. 363 15 Designing solutions with recursion and backtracking 365 15.1 Recursion compared to the for loop 366 15.2 Finding the largest value in a list by recursion 367 15.3 Reversing a list with recursion 368 15.4 Solving the Towers of Hanoi puzzle by recursion 370 15.5 Recursive algorithms for a binary search tree 373 Inserting into a BST with recursion 375  ■  Printing a BST with recursion 376 15.6 Quicksorting a list with recursion 378 Quicksort in action 379  ■  Partitioning a list into sublists 380 Quicksort implementation 383 15.7 The Fibonacci sequence and a recursion disaster 386 15.8 Dynamic backtracking increases the power of recursion 388 15.9 Solving the eight queens puzzle with recursion and backtracking 389 15.10 Solving Sudoku puzzles with recursion and backtracking 393 16 Designing multithreaded programs 399 16.1 How do things happen simultaneously? 400 16.2 A mutex enforces mutual exclusion 402 Protect the integrity of a shared printing resource 403

xicontents 16.3 A semaphore accepts multiple threads 409 The classic reader–writer problem 409 16.4 Condition objects synchronize threads 418 How condition objects synchronize threads 419  ■  The classic producer–consumer problem 420 16.5 A final note on multithreading 427 index 429

xii preface I wrote this book to pass on what I’ve learned from decades of professional software development and teaching. I’ve studied, lived, worked, and taught in Silicon Valley my entire adult life. I’ve held senior engineering positions at established computer com- panies such as Sun Microsystems and Apple, and also at several startups. I’ve developed advanced software at IBM Research (data analytics regarding the causes of obesity), Lawrence Livermore National Laboratory (enterprise software for NIF, the National Ignition Facility fusion energy project), and NASA (data management code for the Mars rovers and the Orion spacecraft). I’ve taught software development at both the undergraduate and graduate levels at several universities, including San José State Uni- versity, where I teach classes in the Computer Science, Computer Engineering, and Applied Data Science departments. Working with students and other beginning programmers has taught me that it’s important to practice good software design before bad habits set in. As students, we inadvertently learn “run and done”: as soon as a program assignment runs successfully, it’s done! After we turn it in, we may never have to see it again, so good design concepts such as maintainability are immaterial. We must unlearn that mentality to have a suc- cessful career as a professional software developer. I am well aware of the pressures to get an application done on time and under bud- get. Therefore, I teach an iterative, incremental approach to software development. If we can’t reach the last iteration and complete the product due to an upcoming dead- line, we want the results of the next-to-last iteration (or the next-to-next-to-last itera- tion) to produce a minimum viable product (MVP). Well-designed applications can actually take less time to develop. Hopefully there will be the next release of the applica- tion to clean up design problems and add more features.

xiiipreface Experience is the best teacher Besides studying the examples in this book, what is the key to becoming a top-tier pro- grammer? It’s practice, practice, practice! I hope the saying “Experience is the best teacher” applies both to you as a software developer and to me as the teacher and writer.

xiv acknowledgments This is a hard section to write! How can I acknowledge all my teachers from so many years ago who set me off on the right path, and all the people I’ve worked with who taught me so much about software development? Therefore, I’ll limit myself to thanking those who helped me write this book. First, my university students unknowingly showed me the best way to present and teach this material. My agent, Carole Jelen at Waterside Productions, Inc., got me started on this book. I greatly appreciate the careful, thoughtful feedback I received from my review- ers; several of them even tested my example programs. It took several rewrites, but I hope the final version of this book justifies their diligence. Two reviewers were col- leagues at San José State University in Silicon Valley, so I especially want to thank Cay Horstmann and Robert Nicholson. Cay allowed me to borrow his date arithmetic and circular buffer examples from his earlier Java software design book. Tony Holdroyd and Steven Lott were excellent technical reviewers provided by the publisher, Man- ning. To all the reviewers: Akshay Phadké, Alex Martelli, Artur Baruchi, Brandon Dar- lington-Goddard, Christopher Fry, Dermot Doran, Gary Samuelson, Helio Loureiro, Himanshu Kandpal, Ivo van Hurne, João Dinis Ferreira, Joe Banks, Jon Rioux, Lana Crowell, Louis Luangkesorn, Natasha Kulkarni, Nicolantonio Vignola, Noah Flynn, Pat Viafore, Piti Champeethong, Rashan Smith, Rory Cawley, and Shantanu Kumar, your suggestions helped make this a better book. I am extremely impressed by the dedication, care, and effort that Manning put into me and the writing of this book. Senior Development Editor (and fellow multi-cat par- ent) Marina Michaels and I spent many hours chatting online to improve my writing and to keep me encouraged through several revisions. I want Marina to be the editor for my next book and to continue exchanging cute pictures of cats with her. I also had

xvacknowledgments several conversations with Associate Publisher Michael Stephens, who gave me some key tips. What a career I’m having, working and teaching in Silicon Valley! I cannot give enough thanks for that.

xvi about this book This book is about writing well-designed software that’s reliable, flexible, and main- tainable. It covers requirements elicitation and analysis, design principles, and design patterns. There are many examples of poorly designed code and how applying the principles and incorporating the patterns improves the code. The goal of this book is simple: to make you a better programmer. Who should read this book? Python is now one of the most popular programming languages. Its programmers develop medium to large-scale applications in various domains, especially AI and data analytics. This book is for you if you want to become a top-tier Python programmer who can create well-designed applications that meet their requirements and that are more reliable, flexible, and maintainable. Well-designed applications are more bug- free, and they can cost less to produce and perform better at run time. We’ll tackle the enemies of good software design: change and complexity. You’ll be proud of the appli- cations that you design and develop. You will get the most out of this book if you are at least a beginning or intermediate Python programmer and understand the basics of object-oriented programming. How this book is organized: A roadmap The book has 16 chapters organized into five parts. Part 1, “Introduction,” introduces software design and a development methodology: ¡ Chapter 1 discusses what software design is and includes several design examples. ¡ Chapter 2 demonstrates iterative development to achieve good design.

xviiabout this book Part 2, “Design the right application,” discusses requirements and good class design: ¡ Chapter 3 is about how to analyze requirements and introduces UML diagrams. ¡ Chapter 4 is about good class design. Part 3, “Design the application right,” contains examples of good design principles such as encapsulation, loose coupling, coding to the interface, and hiding implementations: ¡ Chapter 5 explains why it’s important to hide the implementations of classes. ¡ Chapter 6 explains why we shouldn’t write code that surprises its users. ¡ Chapter 7 demonstrates how to design subclasses right. Part 4, ”Design patterns solve application architecture problems,” shows how to apply industry-proven design patterns: ¡ Chapter 8 is about the Template Method and Strategy Design Patterns. ¡ Chapter 9 is about the Factory Method and Abstract Factory Design Patterns. ¡ Chapter 10 is about the Adapter and Façade Design Patterns. ¡ Chapter 11 is about the Iterator and Visitor Design Patterns. ¡ Chapter 12 is about the Observer Design Pattern. ¡ Chapter 13 is about the State Design Pattern. ¡ Chapter 14 is about the Singleton, Composite, and Decorator Design Patterns. Part 5, “Additional design techniques,” examines recursion, backtracking, and multithreading: ¡ Chapter 15 is about designing solutions with recursion and backtracking. ¡ Chapter 16 is about designing multithreaded programs. I designed the book to be read in order, especially parts 1 through 4. In particular, chapters in part 4 refer to material covered by chapters in parts 2 and 3. A few chapter sections are marked “optional.” I included them for completeness and because their topics are interesting. Those sections are not required to understand the rest of the book. About the code Readers and students learn best with lots of examples. Therefore, I’ve included many examples of poorly designed programs with explanations of why they’re bad and how to transform them into well-designed programs. I tested the example programs in this book using Python 3.12, although you can run nearly all of them with earlier Python versions starting with 3.10. With the exception of chapter 3, each chapter has example programs. As much as possible, I used a limited set of Python features so that the design concepts are clear and to make it easier for you to apply the concepts to other object-oriented languages. I provide explanations when- ever I stray from the basic language features.

xviii about this book This book contains source code both in numbered listings and in line with normal text. In both cases, source code is formatted in a fixed-width font like this to sepa- rate it from ordinary text. Sometimes code is also in bold to highlight important code pointed out in the text. In many cases, the original source code has been reformatted: added line breaks and reworked indentation accommodate the available page space in the book. In rare cases, even this was not enough, and listings include line-continuation markers (➥). Addi- tionally, comments in the source code have mostly been removed from the numbered listings. Instead, code annotations in the listings highlight important concepts. You can get executable snippets of code from the liveBook (online) version of this book at https://livebook.manning.com/book/software-design-for-python-programmers. The complete code for the examples in the book is available for download from the Manning website at https://www.manning.com/books/software-design-for-python-programmers and from GitHub at https://github.com/RonMakBooks/SoftwareDesignPython. liveBook discussion forum Purchase of Software Design for Python Programmers includes free access to liveBook, Man- ning’s online reading platform. Using liveBook’s exclusive discussion features, you can attach comments to the book globally or to specific sections or paragraphs. It’s a snap to make notes for yourself, ask and answer technical questions, and receive help from the author and other users. To access the forum, go to https://livebook.manning .com/book/software-design-for-python-programmers/discussion. Manning’s commitment to our readers is to provide a venue where a meaningful dia- logue between individual readers and between readers and the author can take place. It is not a commitment to any specific amount of participation on the part of the author, whose contribution to the forum remains voluntary (and unpaid). We suggest you try asking the author some challenging questions lest his interest stray! The forum and the archives of previous discussions will be accessible from the publisher’s website for as long as the book is in print.