Practical .NET

It's Not the Names that Matter

As you work with other developers (and seek advice from experts) you need to make sure you're discussing what matters rather than arguing about terminology.

• By Peter Vogel
• 09/01/2016

I was teaching Learning Tree's Design Patterns and Best Practices course when, as often happens, one of the class' participants brought up a problem he was facing back on the job. Over the break, we worked through a potential solution and, as we finished, the participant asked, "Would you call this an example of the façade or the state pattern?" I said that, depending on what parts of the solution you focused on, you could call it an implementation of either pattern. This was followed by a long, skeptical silence.

The point I tried to make to that participant is that the name doesn't matter. What matters is that design patterns provide a toolbox that a developer can draw on to create a solution that addresses the real needs of the problem. Design patterns aren't a rigid specification that can be applied blindly. It's like watching Tiger Woods play, back at his peak: The man was frequently inventing his own golf strokes to solve particular problems.

The relative unimportance of names has been part of design patterns since the beginning. The book that inspired the original Gang of Four's design patterns book was a book on architecture: "A Pattern Language: Towns, Buildings, Construction" (Oxford University Press, 1977). That book explicitly encourages its readers to combine patterns and to pile them on top of each other to create new solutions. The result wouldn't be any particular pattern: It would be a house that meets the needs of its occupants.

The real world is a messy place. Most categorization systems do not turn out to be buckets providing a single spot where every instance can be dropped. Instead, most categorization systems are markers on a continuum. Many (perhaps, most) cases will cluster around one of those markers; many cases will fall somewhere in between the markers. There will be all sorts of cases where everyone will agree about what name should be applied to specific cases … and many cases where reasonable people could disagree about where the case goes.

A Database Digression
In fact, being fanatical about applying names can distort reality, something that relational database design demonstrates. When you apply the best practices in relational database design theory you usually end up with a lot more tables than you started with. To prevent all of those tables from becoming overwhelming, designers organize them into categories: These tables are "entity tables" while these other tables are "lookup tables," for example.

One set of tables is regarded as "special." In relational database theory you sometimes have to support many-to-many relationships (a customer stays at many hotels; a hotel is visited by many customers). To support that in relational database design, you create a table with two columns, with each column holding the primary key value from one of the tables (in my hotel example, that would be a table with two columns, one holding the CustomerId, the other holding the HotelId).

I actually had to figure this out on my own when I was designing my first relational database sometime back in the middle '80s. When I did, finally, come up with this table design, I looked at my solution and thought, "That's an odd table." The person in the company I worked for who was responsible for implementing changes in our database thought it was odd, too -- I got a call from him asking why I had designed this funny table that didn't have any actual data in it.

When I eventually did read a book on relational database design, I discovered that these tables had a special name: They're called "intersection" or "union" tables. I also discovered that I wasn't alone: Everyone else seemed to regard these tables as some sort of freak of relational design theory.

But, really, they're not. If you think of sales orders and products, for example, you know that a sales order contains products and a product appears in many sales orders (at least, you hope so, because otherwise you'll go out of business). The table that implements that many-to-many relationship contains the SalesOrderId and the ProductId. Interestingly, no one regards this table as "something odd"… probably because it has a great name: It's the SalesOrderDetails table. Part of the reason is that the table contains more columns than just the two Id fields: It also contains the quantity of each product being bought, for example.

In fact, my Hotel/Customer table would probably end up the same way: Each row in that table would hold a CustomerId and a HotelId but would also hold the date the customer arrived and the number of nights the customer stayed. This table would end up being called something like CustomerStay.

Now, if someone were to ask me if the CustomerStay table or the SalesOrderDetails table was an intersection table or an entity table, I could answer, "Yes!" But my point is that it's the right table for the problem and the category name you apply to it isn't the critical part of the design.

Back to Objects
We have a similar problem in object-oriented design, thanks to applying the SOLID principles (and, most especially, because of applying the S in SOLID: the Single Responsibility Principle): We end up with an overwhelming number of objects that talk to each other. To handle the quantity of objects, though, we define categories and organize our objects into them.

There are numerous systems for organization objects: "presentation," "business," "data access," "repository," "model," "domain," and "service" are just some of the words that get used for these categories. Often, developers end up using these words in long discussions about which objects should get which functionality.

It hasn't helped that there's no Central Authority for Terminology that ensures that what each person means by "service layer" is what everyone else means by "service layer." And, often, the names that different developers use don't come from the same categorization systems. One person will be discussing what goes in a domain object while another is asking about what should (or shouldn't) be done in a service object.

The point, however, is not to argue over the name. The point is to appreciate why the categories exist, to know what problems each object in a category is supposed to solve, to understand how the practices associated with that category both solve and prevent problems. If you understand those issues then you're in a position to discuss whether you've actually solved the problem forever or just created a bigger mess waiting further down the road.

And that's actually a discussion worth having.