What Design Pattern To Use?

How would you name a class that has a database and a bunch of related methods?

— Hey Alice, I was wondering if you could help me with one programming question. Namely, the second hard problem in computer science.
— Sure, what are you trying to name?
— I made a class which holds database and provides a set of methods related to database things.

— Why not name it Repository?
— Well, the Repository is actually a client of this class.
The component I’m working on right now provides reliable access to Coffee. One part of it is CoffeeRepository with usual search-find-get-whatever methods. This CoffeeRepositoryholds database and a bunch of things related to it, such as retry count, table name prefixes and suffixes, and so on. So I thought it could be a good idea to move all that low-level mechanical stuff to its own place and now I’m wondering what would be a good name for this place.

— So this class is an implementation detail internal to CoffeeRepository?
— Yes, absolutely.
— Then it actually doesn’t matter how you name it. You could name it even LowLevelMechanicalCoffeeRepositoryStuff, and it would be fine. I’d name it something like CoffeeDatabaseUtils, and move on to work on things that are important.

— Yeah, that’s sort of what I did. I named it CoffeeDatabaseHelper and code is in review now. But this case still puzzles me. It’s like a song that you’ve definitely know you’ve heard somewhere, and you are trying hard to remember where exactly have you heard it. There must be a design pattern for that use case; it’s just that I haven’t identified it yet.

CoffeeDatabaseHelper is just ok. The bigger the scope of the object, the more important it is to give it a good name. If that’s an internal thing then *Helper is fine
— Yes, this naming puzzle isn’t very practical, but that makes it even more exciting. Don’t you agree that the most beautiful things have no application in the real world whatsoever?

— Ok, fine. What does this class do?
— As I said, it holds database and related configuration, and also provides methods to get the database itself (i.e., getter), names of the tables, and columns.
— Why would any component need to know the names of the tables?
— Because our CoffeeRepository constructs SQL queries, and we need column and table names to do that. It might have been fine to keep it in CoffeeRepository if these names were constant values, but they are created dynamically. E.g. table name is <Table prefix> + <Table name>, but sometimes it is <Table prefix> + <Table name> + <Table suffix>. Column names are constructed similarly. Don’t ask me why do we do that, it’s just how it was before, and now it would be too much effort to migrate. Right now, all these methods are in CoffeeRepository, and I want to move it out.

— Right. Remind me please, why do you think CoffeeDatabaseUtils (or CoffeeDatabaseHelper) is not a good name?
— First of all, I wouldn’t expect *Utils class to hold state. And here we are holding database and its config. In my opinion *Utils is more like a collection of static methods — WriteToFile, ExtractDateFromId, GenerateBackupFilePath, and so on. Also, *Utils is too generic. You could name it Random*Stuff, and it would be even more honest than naming it *Utils.

— Well, what you have described is basically random stuff, isn’t it? You are trying to clean your repository up and move all irrelevant things to a separate place. There you are making an assumption that all these things belong to the same set, and it’s ok to put it in one class. Sometimes that is the case, but sometimes it is not. For instance, how about a class named CoffeeTables which would provide tables and columns names?
— Hmm, CoffeeTables is actually good. There is one issue though — it doesn’t make sense for CoffeeTables to hold database.
— Yes, you would have to keep database separately.
— And then I would have to keep config like retry count or query timeout also separately, probably in a different class like CoffeeDatabaseConfig. And method checkPermissions() would have to have a whole separate class CoffeeDatabasePermissionChecker.
Then it sort of defeats the whole purpose of this exercise. The point is to make CoffeeRepository simpler, but instead, we are creating a few new entities — CoffeeTables, CoffeeDatabaseConfig, CoffeeDatabasePermissionChecker. It might be good from a pure design point of view, but to be honest, it seems a bit overengineered.

Good API should be as simple as possible. Entities should not be multiplied without necessity. I‘d like to try to put all of that into a single class, and I believe there is a pattern for it. But which pattern?

Proxy? No, proxy gives you an identical interface that is sort of a cheap and lightweight placeholder for a real object. E.g., in some countries, you could still use the retro method of payment called checks: you write down how much money you are giving to a person on a piece of paper, and this person could go to a bank and withdraw this amount from your account. This check is a proxy for the amount of money.

Adapter? It’s not an adapter either. An adapter is when you want to do the same thing using different means. Say, you are writing a post, and you want to share it on Facebook, Twitter, Instagram, Telegram channel, and other social networks. There could be an app where you write your post, click “Publish,” and it does all the publishing to all the platforms — each of the classes that would talk to a specific platform’s API would be an adapter. That’s not the case here.

Decorator? Decorators usually silently add some behavior to an existing interface. A good example of a decorator is ATM skimmer — it looks like an ATM card reader, but it also sends card details to whoever installed the skimmer. We do add the behavior here, but we add it through new methods, so it doesn’t look like a decorator fits our case.

Facade? That seems to be a more or less good candidate. The pattern is supposed to hide the complexity and provide a simplified interface. E.g., a credit card is a facade to a bank account. It sounds like what we are trying to do here.

You know what, I think the facade is actually not a bad choice.

— Do you think CoffeeDatabaseFacade is better than DatabaseHelper?
DatabaseHelper a bit better than DatabaseUtils in a sense that it won’t be such a surprise if *Helper would hold some state. But to me, it still feels like CofeeDatabaseWhatever name.
I mean let’s say you are reading the code and you see the class named CoffeeDatabaseHelper. What would this name communicate to you? Sure, that there is something related to the database in this class. Is it a CLI command to make a dump of the database? Could be. Is it a set of methods to provision a few instances of Postgres for this database? Why not?

CoffeeDatabaseFacade doesn’t sound like an informative name either.
— I wouldn’t say so. Would you expect CoffeeDatabaseFacade to contain devops code? Probably not. Granted, when you see *Facade it’s unclear what happens there, and it’s an odd name. Though it should, in theory, tell you that it has something to do with database, it’s specific to Coffee, and it provides a simplified interface to something complicated. But don’t you agree that the description of the pattern fits well here?
I think you could say so. Not that name generation is something really complicated from an engineering point of view, but you could say it’s complicated from a business logic point of view.

— All right, so it is the facade then. But I do agree that *Facade is an odd name. What do you think if I would name the class CofeeDatabase? And I would mention facade in the comment:

// CoffeeDatabase is a facade for |database|.
// It holds |database| instance and provides methods to get table
// and column names, settings like retry count or timeout, etc.
class CoffeeDatabase {
// ...

— I wouldn’t say it’s the best name, but I can’t say it’s too bad either. Let’s say it’s ok.

— Hey, Bob, how is that CoffeeDatabase class that we discussed? Have you renamed it?
— Well, no. As you pointed out in the very beginning, this class is an implementation detail. CofeeDatabaseHelper is a reasonably good name, and I didn’t want to spark a debate about the best name for an internal component. So, no, I haven’t renamed it. But I still find our discussion super valuable thought experiment. Thank you!

Software engineer @ Google

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store