Hey everyone! It’s my first post of the new year! Usually, I do a bunch of book reviews at the beginning of the year, and I will certainly do that in upcoming posts. UPDATE: No, I won’t. Not this year. Sorry.
Also, don’t worry that I may have given up on my video series; I haven’t. I’m simply being a moron and doing other, less important things in my free time. I’m sure I’ll whip myself into shape soon enough.
Lastly, I’ve received a bunch of free copies of my book from Apress, so I’ll be coming up with some way to give those away sometime soon.
Onto THIS article now.
I need to start this article with a disclaimer: this isn’t really even a good idea. It’s really just a thought experiment that I did, and I’d like to show you how it could be done if you ever wanted to do it. Continue Reading
This one’s gonna be short. Honestly, I don’t know how last week’s article about static methods went so long.
Singletons get a bad rap, being called Anti-patterns, and for good reason. The biggest reason given against Singletons is that they’re global state, which is bad. If you want a stateful “Singleton”, there are ways to restrict the application to only having a single instance, even if the class can have multiple instances. While this still largely equates to global state, at least it opens up the possibility of test doubles and makes the “Singleton” itself that much easier to test. Continue Reading
Back in my delegate decorator article, I mentioned some weaknesses of the delegate pattern as a substitute to inheritance. The decorator solved one of those problems, but the other is still a problem. The problem comes when using something akin to the template pattern. Continue Reading
As many of my readers will likely know, my favorite design pattern is the Decorator Pattern, but I don’t think I’ve mentioned what my second favorite pattern is. This is understandable, as I have a difficult enough time picking favorites usually, let alone second favorites. Well, my second favorite is sort of a toss up between the Factory Pattern and the Strategy Pattern. I almost HAVE to choose the Strategy Pattern though, since the Factory Pattern is essentially a specialization of the Strategy Pattern.
Today, I am going to present an interesting idea about implementing the Strategy Pattern in Python that doesn’t involve making instances of a class or using functions as the strategy object. Continue Reading
Sometimes, you may hear about dependency injection done via a getter method, which subclasses override or mock frameworks fake for testing. It allows the class to have a set dependency that is actually hard coded, but can be “injected” if need be. Continue Reading
Recently, I posted about how you can use composition instead of inheritance, and in that article, I mentioned the Delegate Pattern. As a quick description, the pattern has you inherit from the parent interface (or, in Python, you can just implement the protocol), but all the methods either redirect to calling the method on an injected implementation of interface/protocol, possibly surrounding the call in its own code, or it completely fills the method with its own implementation.
For the most part, it is like manually implementing inheritance, except that the superclass in injectable.
Anyway, one of the more annoying parts of implementing the Delegate Pattern is having to write all of the delegated calls. So I decided to look into the possibility of of making a decorator that will do that for you for all the methods you don’t explicitly implement. Continue Reading
Quite a while back, I posted about how, despite the fact that you should prefer composition over inheritance, you can best design classes for inheritance. Now, I wish to give some examples of how you can take your code that uses inheritance and change it to use composition instead, which will often actually make your code more flexible.
The code will be in java, but the concepts can transferred to any language that is object-oriented. Some languages might have constructs that make parts of this easier, too (Kotlin’s Delegates).
One thing is important to remember, though: Even if you switch “completely” to composition, you will still have some inheritance. This inheritance will be from interfaces and interface-like classes only, though. It barely counts as inheritance, really, since all it’s doing is restricting itself to an API and not inheriting implementation details. Continue Reading