Practical Object-Oriented Design

Chapter 1: Object-Oriented Design

Chapter 1 - Object-Oriented Design

The problem with poorly designed small applications is that if they are successful they grow up to be poorly designed big applications.

Successful but undesigned applications carry the seeds of their own destruction; they are easy to write but gradually become impossible to change.

At my various jobs, I have seen numerous poorly-designed smaller applications grow up to be untenable (though highly-profitable) beasts. The tech-debt accumulates through the numerous small poorly designed compromises that are made during development to deliver software “quickly”.

Designs that anticipate specific future requirements almost always end badly. Practical design does not anticipate what will happen to your application… The purpose of design is to allow you to do design later and… reduce the cost of change.

The poorly designed beast often creates a desire to design all new features or changes “correctly” in the future by using “standards” and “rules”. However, that sort of mindset has the seeds of its own destruction given that the core problem with the original design–and inevitably with the BUFD–is that it’s not changeable. The rewrite does not change the core behavior of the team that created the original issues. They’ll inevitably create largely the same issues because of their rigid approach to development.

You must not only write code for…today, you must also create code that is amenable to being changed later.

The cost of change will eventually exclipse the original cost of the application.

The iterative nature of Agile development allows design to adjust regularly and to evolve naturally.

Agile thus does not prohibit design, it requires it.

Easily changeable software that does not concern itself with future-proofing and models ideas and concepts in the form of objects and the messages that are sent between them, is the core idea in object-oriented design.

Applications that never need to be changed don’t need to be written or designed in a way that allows for change. Those applications are few and far between and in my experience writing changeable code coincides with the verifiability and quality of the application. These principles overlap with software that is a joy to write and change.

Object-Oriented software fails when the act of design is separated from the act of programming. Design is a process of progressive discovery that relies on a feedback loop.

Type fixation–in the form of services, models, etc–is a particular disease that infects the majority of those attempting to change their programming style from a procedural one to a true Object-Oriented one. They believe that by fixating on certain types that they can use those types for practically everything. However, this inevitably leads to procedural code that uses classes for organization which is the very definition of an Anemic Domain Model.