The Registry Pattern Reexamined

Last July, I wrote about the registry pattern and some of its advantages. These advantages include the ability to access objects across different areas of your application, and the storage of objects for later retrieval.

Much of the debate in the comments focused on whether or not the registry pattern was suitable for today’s object-oriented development, and some of the arguments focused on whether or not the “global scope” was a good place to have objects.

Continue reading

The 15 Minute Rule Of Software Development

I talk a lot about how having a spec is a critical component of software development. But how do you know that your spec is good, and that it has been developed enough? Simply put, how do you distinguish between a good spec and a spec that is lacking?

This problem had confounded me for a good bit of time, because it’s hard to create a rule surrounding spec development. Since most developers (myself included) are also generally bad at developing good specs, it becomes even more difficult to create such a rule. However, I heard a great adage from someone recently that I thought summed up how developers can see specs nearly perfectly.

Continue reading

Five (Good) Lessons The Government Teaches Us About Object-Oriented Programming

As Benjamin Franklin once famously said, “the only two things that are certain in life are death and taxes.” His point, while political, has a good perspective on one of life’s ever-persistent truths: the fact that governments exist in every country, and, largely, they have some of the same benefits and drawbacks everywhere.

However, the ubiquity of governments around the world also gives us a unique opportunity to learn some lessons from them as developers, particularly about principles of object oriented programming. Governments serve as perfet object lessons (pun intended), demonstrating some of the good, the bad, and the ugly object-oriented practices we see.

Continue reading

Peer Review: Improving The Business Logic

This entry is part of an ongoing series involving the review of a code sample and it’s refactoring. For the original code sample, see here.

So far, we’ve done quite a bit of work on our Twitter class, making it better. There’s still work to be done, though, especially improving the logic.

The Twitter class we have now has a number of logical flaws in it that we need to address. Additionally, there are some logical flaws that we started with that I want to highlight, even though we’ve already fixed them. Let’s get started with those.
Continue reading