1 The path to well-designed software

This chapter introduces the path to building sustainable Python applications that are reliable, flexible, maintainable, and easier to test. It emphasizes that good design helps teams reach a minimum viable product sooner, adapt to evolving requirements, and avoid costly rework. The journey isn’t linear: it starts with understanding and validating requirements to ensure you build the right application, then iterates through design–code–test cycles to build the application right. Throughout, the chapter frames change and complexity as the chief challenges that sound design must anticipate and manage.

The chapter equips readers with object-oriented design principles for improving code at the function and class level, and design patterns for addressing recurring architectural problems. It contrasts “before” and “after” examples to expose pitfalls such as leaking changes across classes, oversized classes that violate single responsibility, unnecessary subclass hierarchies, hardcoded decisions that reduce flexibility, and surprising behavior stemming from poor interfaces. It also previews how patterns (for example, solving publisher–subscriber workflows with an Observer-style model) provide proven, adaptable templates that are grounded in core OOP concepts.

Success, the chapter argues, comes from iterative development, deliberate trade-offs, and the disciplined use of encapsulation, abstraction, inheritance, and polymorphism to contain variation and reduce dependency. Aimed at beginner to intermediate Python programmers, the book uses simple Python examples to keep the focus on design quality, collaboration, and long-term maintainability. It closes by urging developers to evaluate even AI-generated code through a design lens—checking for sound principles and appropriate patterns—so that tools accelerate, rather than undermine, the creation of well-designed software.

A hierarchy of classes and subclasses. Does it have to be so complex? Good design techniques can simplify this data.

Publisher–subscriber is a common software architecture situation. One application component produces data that other application components consume. The Observer Design Pattern provides a model to solve this problem.

The Big Bang theory of application development. If we write lots of code in a prolonged marathon instead of developing the software iteratively, we can only hope that the Big Bang at the end will magically produce a working application. Unfortunately, that magic rarely happens.

• Design is a disciplined engineering approach to creating a solution to a problem. In software engineering, the problem is to create working software, and the solution is a well-designed, sustainable application.
• Well-designed software is better in many ways, such as being more reliable, flexible, and maintainable. Good design helps ensure that applications are completed on time and do what their clients expect.
• It is possible to become a better programmer by using good software design techniques that include good design principles and design patterns.
• Good design principles help make our code more flexible and able to handle changes such as new requirements. Design patterns are industry-proven models for creating solutions to common software architecture problems.
• Software design starts by acquiring and analyzing an application’s requirements to ensure that we’re developing the right application. The application must do what it’s supposed to do.
• Developing a well-designed sustainable application nearly always requires multiple iterations with backtracking over bad design decisions. It’s hard work. Don’t rely on a magical Big Bang at the end of a marathon coding session.
• Good software design must deal with the major challenges of change and complexity.
• The design principles and design patterns in this book are based on the object-oriented programming concepts of abstraction, encapsulation, inheritance, and polymorphism.
• Encapsulation also means isolating the parts of a program that can change. Then, when changes do occur, they won’t leak out and cause changes to other parts of the program.

FAQ