Any time you have a long-term data structure, it’s important to have some form of unique identifier used to look up or recognize the structure. It doesn’t matter if the long-term data is a database record, a document in some form of storage, an object, or whatever. If the data lives for a while, you’ll… Read More »
One of the design ideas that came out of the early days of the agile movement was YAGNI. As I have written before, this idea is push back against the tendency of many programmers to over-engineer or over-complicate our designs. We normally use some variation of the flexibility argument to justify this tendency. In fact,… Read More »
One of the classic mistakes of software development results from thinking we know what we are doing. Entirely too many people in software start off each project believing they know enough about the project to lay out the whole design. Except in the rare circumstance that you are building an exact copy of something you… Read More »
As I’m writing this in December of 2014, I’ve been reminded that the classic Design Patterns book came out in 1995, almost twenty years ago. I didn’t see the book until a year or two later. Reactions I remember several reactions from the programmers I was working with at the time. Most of the programmers… Read More »
A few years ago, I first became aware of the concept of Value Objects. Unlike most objects you might use in a design, the identity of a value object is completely unimportant. Instead, the value of the object is all that is important. This leads to a couple of interesting design decisions: Value objects tend… Read More »
This is yet another in the Best Practices Gone Bad series of posts. Around two decades ago, the book Design Patterns (often called the Gang of Four, or GoF, book) was published. This book introduced a large number of programmers to a new approach to thinking about solutions. For those who are not familiar with… Read More »
This is the second entry in the Best Practices Gone Bad series of posts. One principle that a lot of developers have been holding to lately is DRY. In The Pragmatic Programmer, Hunt and Thomas state the DRY principle as: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. This… Read More »
While I was at YAPC::NA this year, I got a chance to catch up with a few old friends and talk with some really knowledgeable people from other parts of the Perl programming community. One such discussion started when Rob Kinyon told me that exceptions are fundamentally flawed by design and should never be used.… Read More »
The comments from Ian and rlb3 have made me think a bit more on what I said last time about Chronistic Coupling. One thing I didn’t make perfectly clear is that I’m not advocating avoiding Chronistic Coupling at all costs. Any real system will require some amount of Chronistic coupling. The key design point is… Read More »
Many programs have a need to store program state to disk at various points. An approach used by many of these programs is to serialize the objects representing the program state directly to disk (or a database). Back in 2004 (XML-Serialized Objects and Coupling), I described a coupling problem caused by automatically serializing objects to… Read More »