Home > Articles > Programming

Refactoring Classes, Objects, and People: Part 1: The Decision Process

  • Print
  • + Share This
The long-brewing trend toward increasingly "value-added" products and approaches has hit hardest in the world of information technology (IT). Bob Grogan attempts to tackle the distinction between synergy and collision, and possibly set guidelines to identify each.
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.

  • + Share This
  • 🔖 Save To Your Account