- From Physical Architecture to Code
- Taming the Maintenance Beast
- The Big Split: Those Who Know Patterns and Those Who Don't
- Where Development Is Headed
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Big Split: Those Who Know Patterns and Those Who Don't
The people who understood patterns continued to develop in the space, finding Kent Beck's patterns for test-driven development (TDD), [5] new guidelines for code (especially Robert C. Martin's work [6]), and even test automation patterns such as page object, driver factory, and data builder. [7] Over time, the use of language changed a bit: Strict definitions using terms like context, forces, solution, and resulting context are often dropped. To an insider, these new patterns may look a bit sloppy, but the goal of finding waypoints to guide the craft remains.
Slideshow Pavel Mitin describes the page object pattern.
Of course, there are also programmers who don't know patterns, except the ones forced on them by coding frameworks; for example, the Model-View-Controller (MVC) pattern is a core part of Rails, and Microsoft now uses MVC. This group of programmers doesn't understand the overall concept or have wide exposure to a large number of design patterns. Thanks in part to the Agile movement's "sprints" and "iterations," this group is in the awkward position of continually maintaining code, but without quite knowing how.
That reality leaves us with two groups coding software today: One group cleaning up messes and another group making them.
Another example to prove this point: The code listing in the preceding section certainly beats having one long routine, but it has a few "smells." Most noticeably, algo, strategy, and tax are tightly coupled. The fix for this problem is to have algo be part of co, dynamically created when co is created. That approach leaves us with something like this:
//co is an object that exists of type company taxDue taxAmount = co.calculateTaxDue();
How would this design work? taxDue would have a member variable that is the tax calculator base class; at create time, the builder would create the appropriate tax calculator as the member variable. But you would only know how to make this technique work if you read design patterns—or at least something influenced by them.