Man, I’ve had this idea in my head for more than a month now (luckily I wrote it down, too), waiting until the day I wrote this post. I didn’t write it because I was busy with the move and new job, but now things are finally settling down!
Here’s the thing: When you really dig into it, proper object-oriented programming and functional programming are pretty similar. The biggest difference is that object-oriented programming likes to use encapsulation to hide the real data behind facades of objects – requiring you to define methods attached to the type that know about private details – while functional programming is quite up front about it all – making it so that you generally get switch-like structures (but WAY better) that allow you write one function to handle all of the different types.
A side-effect of this has been two different ways to call functions: as methods and as stand-alone functions.
Actually, the second kind could be procedural or functional in style. It’s impossible to tell without more arguments.
Due to functional programming loving to compose functions together, it likes to have the “subject” of the function as the last argument so that the function could be curried or partially applied to a base function that could be composed with other functions that work on the same type or output type. It’s really cool and really handy. But with procedural style, the tendency is to put the “subject” as the first argument in order to show its prominence.
object.methodCall(argument) // OO style
functionCall(object, argument) // procedural style
functionCall(argument, object) // functional style
Interestingly, Python methods are actually explicitly defined in the procedural function style, but are called in the OO style (usually). This sparked an idea within me, which, with knowing how so many other languages do functions, guided me to today’s idea. What if you could define a function in a single way, but use it in any of the three ways listed above? Continue Reading
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!
Today, we’ll be talking about something controversial: static methods. I have yet to read anything that says static methods are good and useful, other than Effective Java recommending them in the use of static factory methods. There are some really interesting (and somewhat dumb) arguments out there against them that rarely, if ever, even get explained. Notably, I’m providing a rebuttal to the article, Utility Classes Have Nothing to do With Functional Programming.
Today, we’re going to look at the good and bad of static methods; what they’re good for and what they’re not.
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
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!
It’s a fairly well known refactoring pattern to replace conditionals with polymorphism. If you’re not familiar with the pattern, you can check it out here. But that basic solution can start to break down once there are multiple fields in the class that conditional checks are based off of. We’ll look into some possible ideas on how to work with these possibilities.