Whoa! Two days in a row, I’ve found some good posts worth sharing! Today’s article presents somewhat of a counterpoint to an older blog post I’d read about classes never being named after what they do, but what they are; that they should always be actual objects in the real world. I never could quite bring myself to accept what this person had said, especially about Factories being a bad thing (I wish I could show you guys the article). Now, this new article actually articulates a defense against the opposite. I hope you all enjoy it!
When I first laid eyes on Java 8’s Stream API and found out that it worked lazily (then found out what that meant), I was blown away and utterly baffled. It didn’t seem possible at all. Eventually, I was able to wrap my head around it, realizing it was done with my favorite design pattern: the Decorator Pattern!
In this post, I’m going to go through and write up a simplified implementation, only going through the
reduce() methods. We’ll also be ignoring the ability to parallelize the calls. Lastly, for the sake of readability, I’ll be ignoring
extends in the generics. 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
If you have seen my most recent post about explicit currying in python, you may remember that I hadn’t bothered to wrap my head around trying to use keyword or default arguments. Also, as the title of my article stated, you had to very explicitly design the function to be curried, instead of having something reusable.
Well, some people cleverer than me took a good whack at it and here’s what they’ve got:
Currying in Python – from the Computer Science blog. He goes over every step of the way towards making a function that could be used as a decorator (though he doesn’t seem to know what a decorator is; he’s new to python) to transform normal functions into curried functions. It’s not especially pythonically written (again, he’s new to the language), and it’s big, but it works.
KISS Python Curry – a github python module by
I love the decorator pattern. It’s the epitome of composition over inheritance and the greatness that can come from it. It also has potential for fluent APIs. In the following article, the writer presents a generic decorating method that I really like, for times when you may extend the list of decorators in the future and you don’t want to add additional methods for them.
Check it out!
Python is a beautiful, easy-to-read language. It’s also (usually) easy to write, most of the time. For the most part, it’s simple to make sure that your classes work well with the language by implementing several “magic methods”, but this gets tedious to do for a few of them.
A nice annotation that Kotlin comes with is the
data annotation, which, when used on a class, will implement the
toString() methods for it, based on the properties passed in through the constructor. I wanted to do something similar to this in Python, since implementing
__repr__ can be tedious. Also, including such method definitions make your class look less appealing (those double-unders are a bit unsightly).
Let’s look at how this can be done. Continue Reading