Refactoring Classes, Objects, and People: Part 1: The Decision Process
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Introduction
For good reasons or bad, most people seek to minimize the number of companies, things, people—and, in short, hassles—that they have to deal with on a day-to-day basis. To a great degree, no one can be faulted for wanting a single source of reliable information. (Hey, that's the web's stock in trade, isn't it?)
Problems begin to arise when ill-advised, ill-conceived, and generally ill-suited combinations start emerging from the pile of ideas. Just because two things are often used at the same or are located near to each other in the kitchen doesn't necessarily mean they should be combined into a single appliance. The oven and the blender, for instance.
Sometimes, however, combinations can produce wonderfully efficient and effective results. In this column, I would like to explore possible criteria to use when considering the merging of classes within an application, roles on a project, or even entire business processes, by drawing the successes and failures of "refactoring" in the past.