2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- November 28, 2018
- Bits and Pieces
We refer to object-oriented programming as a paradigm or way of thinking because it’s more than just a set of techniques and practices. It’s a different way of modeling behaviors. It’s not necessarily as easy to learn as the syntax of a programming language.
Object-oriented programming is subtly different than procedural programming and it’s easy to overlook those subtleties if we’re not paying attention to their benefits. Really, the goal of good object-oriented code is to make the software accurately reflect the important features of what we are modeling. In other words, we should design our software to reflect as closely as possible whatever it is we are modeling.
We create models by defining classes and their relationship to each other. These are the “paints and brushes” of software development. They allow us to model anything—anything that we can name. It’s important that our domain model be clear, consistent, and complete.
It seems that wherever we find “bad code” it is a product of poor understanding. We must understand the problems that we’re trying to solve and model them accurately. When I say understanding, what I mean is that we are able to see how to create a behavior in a system through the interaction of objects. It can be easy to identify the need to create a new behavior but not so easy to identify where in the domain model that behavior belongs. However, keeping a design clear as it evolves is critical for maintainability and future extensibility.
To “codify” something is to understand it deeply enough to be able to express it in code. Writing software requires attention to the most minute details. If we are able to embody a process in code then we understand it in great detail. But just translating a process into code is often not enough to make it maintainable.
Good software is also straightforward to work with and extend. Good software encapsulates behaviors from each other through a well-designed object model where each object in the system has a single, well-defined responsibility. That way, when a change happens, it only impacts a small number of simple objects in the system, thus minimizing its impact overall.
However, functional decomposition is only part of what’s important in an object-oriented system, we also need to organize code in ways that make it straightforward to extend. We do this by recomposing or calling out commonalities between behaviors with abstractions and design patterns. Together, these two approaches, decomposing and recomposing, help us build more maintainable software that costs less to work with and extend.
There are many ways to write software. Conventional wisdom for development practices is totally different today than they were just a few years ago. This is a good sign that our industry is maturing rapidly and we are finally gaining the right insights to be able to create more consistent success throughout our industry.
Previous Post: « The Virtues of Laziness
Next Post: Announcing the Ten Year Anniversary of My Blog »