Let’s assume a project has to transform data from one form to another; this could be updating a configuration file during a software update, loading XML to store into a database, or any of the other million things that this problem applies to. For the sake of simplicity, we’ll assume the theoretical project needs to convert strings from mixed-case to uppercase.
We’re good programmers who know about object-oriented programming and making things classes, so let’s make a class! Because C++ already uses transform, we’ll use the term translate.
class Translator {
public:
void translate() {
std::string input;
std::getline(std::cin, input);
while(std::cin) {
std::transform(std::begin(input), std::end(input),
std::begin(input),
[](auto v) {
return std::toupper(v);
});
std::cout << input << '\n';
std::getline(std::cin, input);
}
}
};
And it works, so good for us. But if we look at it in terms of SOLID, how’d we do?
- Single Responsibility Principle — Partial credit. The code only translates, but everything related to translating, from getting data to spitting back out, is in a single function.
- Open/Closed Principle — Fail. We’re closed to modification, but we’re definitely not open for extension. The only way to leverage this code is to take all of it, so it’s not easy to extend and specialize.
- Liskov Substitution Principle — Not applicable; we’re not dealing with inheritance or type substitution.
- Interface Segregation Principle — Fail. Our class is doing at least three things, plus a loop.
- Dependency Inversion Principle — Fail. Dependencies (strings, iostreams, and our specific mutation) are baked into the code.
So of the four principles that apply, we failed three and got partial credit for one. We can do better. For now, let’s break translate into multiple discreet chunks.
class Translator
{
public:
void translate() {
auto input = read();
while(input) {
mutate(input);
if(input) {
write(*input);
}
input = read();
}
}
private:
std::optional read() const {
std::string input;
std::getline(std::cin, input);
if(std::cin) {
return input;
}
return std::nullopt;
}
void mutate(std::optional & value) const {
if(value) {
std::transform(std::begin(*value), std::end(*value),
std::begin(*value),
[](auto v) {
return std::toupper(v);
});
}
}
void write(std::string const & value) const {
std::cout << value << '\n';
}
};
This is better for all the reasons we’ve heard a million times, but we haven’t scored any better with SOLID. Everything about this translation is still baked into a single class, and just because we’ve broken the work into smaller pieces doesn’t mean we’ve made it more generic. What we have done however, is set ourselves up for that step.
template <typename T>
class Reader {
public:
virtual std::optional<T> read() const = 0;
};
template <typename T>
class Mutator {
public:
virtual void mutate(std::optional<T> & value) const = 0;
};
template <typename T>
class Writer {
public:
virtual void write(T const & value) const = 0;
};
class Translator : public Reader<std::string>,
public Mutator<std::string>,
public Writer<std::string> {
// ...
};
Now we’re on to something! We can move translate into a new function, free from Translator, and have it operate on interfaces.
template <typename T>
void translate(Reader<T> & reader,
Mutator<T> & mutator,
Writer<T> & writer) {
auto input = reader.read();
while(input) {
mutator.mutate(input);
if(input) {
writer.write(*input);
}
input = reader.read();
}
}
This looks a lot like good object-oriented code form the C++98 era, plus some modern features to simply our lives. Let’s look at our SOLID score now:
- Single Responsibility Principle — Mostly Pass. We still have one class that does everything, but it’s a combination of three single responsibility classes.
- Open/Closed Principle — Pass. We can inherit from Translator and replace any of the member functions with our specific version.
- Liskov Substitution Principle — Pass. We’re holding the (implied) contracts of the abstract base classes.
- Interface Segregation Principle — Pass. We have three simple interfaces that provide specific bits of functionality.
- Dependency Injection Principle — Pass. translate operates on interfaces, meaning we can easy provide different implementations.
So we’re done! We didn’t get a perfect score, but that’s trivial enough to fix, and the only reason not to do so is if somebody had a hard dependency on Translator performing all these operations directly. Now let’s put our generic code to work and translate strings that come over the network!
class NetworkReader : public Reader<std::string> {
public:
std::optional<std::string> read() override {
/* network stuff */
}
};
The bold part is the only non-boilerplate we’re writing, and this is a simplified example; in real code, we’d need some way of getting a network socket, and whether that means NetworkReader handles that or accepts a socket, it means we need a constructor (more boilerplate).
What would be nice is if we could use lambdas, since that’s a huge reduction in boilerplate. That could look something like this:
auto networkReader = [s = std::move(socket)]() {
/* network stuff */
};
Can we get translate to work this way? Sure!
template <typename R, typename M, typename W>
void translate(R && r, M && m, W && w) {
auto input = r();
while(input) {
m(input);
if(input) {
w(*input);
}
input = r();
}
}
Now we take lambdas just fine. And regular functions. And function objects (which are really just lambdas). Really, anything that implements operator () fits right in. But without classes we’re going to fail SOLID. Time to see how bad we do:
- Single Responsibility Principle — Pass. Actually, the inputs can’t possibly have multiple responsibilities now, so it’s hard to fail this.
- Open/Closed Principle — translate definitely meets this. It can be customized by passing in different invokable things, plus template specialization means there could be an entirely different version of translate if some piece of code needed it.
- Liskov Substitution Principle — Definitely. The networkReader lambda above can be passed in without any changes to translate, the mutator, or the writer. All any of them have to do is provide an appropriate interface and they’ll slot right in.
- Interface Segregation Principle — Because we’re operating on things like functions, it’s effectively impossible to violate this.
- Dependency Injection Principle — translate knows nothing except how to leverage the invokeables; providing mocks and tweaking behavior with different arguments is trivial.
That actually went pretty well. This version manages to satisfy all five of the principles even though it has no dependencies on any classes. We also have far more generic and flexible code, plus the use of templates means the compiler can aggressively optimize (most lambda calls should be perfectly inlined).
What about our legacy code, like Translator, that’s already a class. We can’t just rename member functions since tons of code depends on those, right? And what if we need the same parameter list for multiple operator () overloads? That’s gotta be a drawback of this approach, right?
Let’s add a template function:
template <typename R>
auto make_reader(R && r) {
return [r_ = std::forward<R>(r)]() { return r_(); };
}
And a specialization:
template <>
auto make_reader<StringReader>(StringReader && r) {
return [r]() { return r.read(); };
}
Well that was simple. There’s a bit of work to deal with something that doesn’t match the expected interface (operator ()), but since that should be the exception it’s not a big deal. Also, this is far less boilerplate to deal with than the alternate method of inheriting an abstract base class and overriding a function, especially if the lambda captures variables.
The moral here is that classes are only one method of abstraction, and that C++11 opened the door to make alternate methods approachable for mere mortals (14 and 17 made this even easier with things like auto as lambda parameters and automatic type deduction for function return types).
If you’re still using classes for all your abstractions, then you’re stuck in the world of C++98. Or Java/C#, which is arguably worse. Embrace the new features, especially the ones that help when it comes to writing generic code (auto, lambdas, and variadic templates are the big winners here).
For the curious source for all these examples is available on Github.