Jumping around between multiple languages can help you notice some differences between idioms and best practices in different languages. One of the more interesting differences has to do with one function doing multiple things. Continue Reading
Python
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
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
Programming Ideas With Jake 