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
Python descriptors are a fairly powerful mechanic, especially for creating properties. The built-in property descriptor/decorator works very well for defining properties, but they have a small weakness in my eyes: it doesn’t have defaults for simple usage. Yes, not supplying the property class with all methods does have the decent default of not allowing that usage, but I mean that it doesn’t automatically implement some form of backing field. Backing fields are done completely explicitly by you.
This is not a problem in some cases. In fact, it makes the property class exceptionally versatile, but at the cost of my explicitness on the part of the user. It has its uses, and it’s great at them. But I have need for something a little less versatile, more specialized, and more implicit.
I strongly try to make as many of my classes immutable as possible, avoiding side effects. Because of this, I want my class attributes to be read-only. There are two existing ways to deal with this. The first is to simply document that I want the attributes to be left alone. This is valid, and has a sort of simplicity to it, but sometimes I like to back up those intents with something a little more restrictive. The second option is to use a property without defining a setter. This is actually a very good option, but as I said while leading up to this, it’s highly explicit. I want a property that is designed for the express purpose of being read-only. 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
First, I’d like to thank everyone who took my survey from last week. It wasn’t important (and, according to some of you, it was ‘dumb’), but it was something I was curious about I’m glad I got all of your feedback. The results are in: Continue Reading
I’ve got a shorter one this week. Partially, that’s because I was part way through a post before deciding to scrap it. Partially, it’s because I’ve written a few mid-week blurbs this week. Lastly, it’s because I don’t think I could stretch this article to be all that big. :)
Naming Functions
Generally, people are told to name methods and functions as verbs. If it’s not a verb, it’s a noun, and therefore an object (assuming it’s an OO language). In most cases, this is true, and, if you’re not sure whether to use the simple verb form or the form I’m about to mention, you should go with the verb form to be safe. Continue Reading
I wrote a poll to see what people what people’s preference was concerning functional composition.
