Chapter 6. Separation of concerns in practice

 

This chapter covers

  • Developing an application with separate high-level concerns
  • Using specific types of encapsulation to loosen the coupling of different concerns
  • Creating a well-separated foundation to enable future extension

In chapter 2, I showed you some of the best practices around separation of concerns in Python. Separating concerns means creating boundaries between code that deals with distinct activities to make the code more understandable. You learned how functions, classes, modules, and packages are useful in decomposing code into pieces that are easier to reason about. Although chapter 2 covered several of the tools available for separating concerns, it’s helpful to get some experience applying them.

As is true for many, I learn best by doing. As I work through a real project, I often discover connections I didn’t see before or find new questions to explore. In this chapter, you’ll work through a real application that exhibits a good use case for separating concerns. You’ll improve upon it in the chapters to come, and you’ll end up with something you can extend for your own personal use.

6.1. A command-line bookmarking application

6.2. A tour of Bark

6.2.1. The benefits of separation: Reprise

6.3. An initial code structure, by concern

6.3.1. The persistence layer

6.3.2. The business logic layer

6.3.3. The presentation layer

Summary

sitemap