00:44 Consider this class that abstracts a file. Its interface includes a method for reading a file, a method for writing a file, one for compressing a file to ZIP format, and one for decompressing from ZIP format.
Instead of having a single file manager, this module implements the same functionality as two different classes. The
FileManager class abstracts the reading and writing of the class having the read and write methods from before, while the
ZipFileManager contains the compress and decompress methods.
02:08 This isn’t just because they’re smaller, but because you can separate out expected behavior. For example, if you think back to my bad file manager, what does it mean to read or write to it? If it’s still compressed, does the class implement that, or would it muck things up?
02:25 Single-responsibility doesn’t mean only a single method. You still want all the methods that make sense for the data on the class. Assuming you pick the right data abstraction, the better file manager needs both the read and write methods, but mixing in compress and decompress makes things messy.
The other is for compressing and decompressing. That’s not to say you couldn’t come up with a better abstraction. You could could build a version of the
Zip class that only implements read and write, decompressing and reading or decompressing and writing, then compressing back when it’s done.
Uncle Bob’s paper on the topic tells a story where he was writing code for a multipurpose printer. Originally, he just had a
Printer class, but maintaining the fax machine and scanning functionality in that class didn’t make a lot of sense. So instead he split it up into three different classes.
Become a Member to join the conversation.