So here’s what this looks like from the rooftop:
You’ll see lots and lots of directories there, which reflects my impulsive nature. There’s stuff like NodeJS there (which I left half-way), zeromq (which I never even got started on), Go (which I did finish, by the way!), and more.
But that’s not all.
The real point is that inside this shallow hierarchy, I maintain a hierarchy that reflects my learning progress. At the same time, I make sure to write copious comments.
Here’s what I mean. I currently happen to be learning Design Patterns in PHP, and here’s what that directory looks like:
Notice that the directories have been numbered as well. That’s because that’s the order in which the design patterns appear in the book. It helps because these concepts build upon the previous one usually, and so are naturally aligned for easy revision.
And here’s how I typically comment:
<?php require_once 'ElectronicNotifierFactory.php'; /** * Unlike the Simple Factory pattern, notice that we are no more relying * on a single class, but calling different classes that we know follow * the same interface. The advantage is that this way, we can keep adding * more factories without having to modify the original class. That's a * BIG advantage as far as the Open/Closed principle is concerned. Note that * if we were to do this via the Simple Factory pattern, we would end up * having to modify the original class, and then we'd have the problem of * having to communicate the extra possibility to all the clients using * that library. */ $mobile = ElectronicNotifierFactory::getNotifier("SMS", "07111111111"); echo $mobile->sendNotification() . PHP_EOL; $email = ElectronicNotifierFactory::getNotifier("Email", "firstname.lastname@example.org"); echo $email->sendNotification() . PHP_EOL; /** * And here's an example use case -- adding another type of notifier */ require_once 'CourierNotifierFactory.php'; $post = CourierNotifierFactory::getNotifier("Post", "13 Friday Street, SF1S 3ZZ"); echo $post->sendNotification() . PHP_EOL; /** * While the textbooks tout this pattern for upholding the sanctity of the * Open/Closed principle, they don't say what would happen if we wanted to * add a new type of electronic notifier, say, Socket notifications. Could * this be symptomatic of the underlying problem that has causing a gradual * shift from Object Oriented programming? */
You’ll note that the comments include my learning from the book, as well as my doubts and apprehensions. This helps me a lot the next time I want to go through Design Patterns quickly. All my learning is frozen in time, and if I have answered these questions by then, I simply remove the comments and move on. All in all, it’s a working mini-book in itself that other people can read from and save time. 🙂
And oh, just in case you were wondering, the Design Patterns code is available on my GitHub.