Some of you who follow me may have noticed a tendency of mine to “hack” programming languages more than really use them (other than reflection via annotations in languages such as Java; I hate that stuff), and today is no different. Today, we look as using what would be normal higher-order functions as Python decorators to create new functions that encapsulate the idea of both the higher-order function as well as the passed-in function under one name. Continue Reading
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.
object.methodCall() // Vs functionCall(object)
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
Hello, dear readers, and welcome to my thoughts on the MVP (Model-View-Presenter) pattern, which I finally got around to learning. I had tried before, but everybody always explained it so abstractly that, even when compared to MVVM abstractly, I couldn’t tell what it was. But I recently got to see the pattern being implemented in some live-coding episodes I don’t really have a whole lot to share; I’m focusing on one mini anti-pattern within the typical implementation that I’d like to provide alternative ideas for.
General Thoughts on MVP
First, I will give you my overall thoughts on MVP. My first thought about it is, “Is this really any different than MVC?” And truly, MVP is pretty much what I had always thought of MVC to be. The problem wasn’t MVC, in my opinion, but what so many people had come to think MVC was. Having heard what Uncle Bob has said about MVC, it’s clear that there has been severe “evolution” to the community’s understanding of MVC, but the MVC I was taught in college is almost exactly the same thing as MVP, with all the differences being negligible compared to the differences between my understanding of MVC and so many others’ understanding.
Beyond all that, though, I do like MVP, overall. When done correctly, it follows the Clean Architecture. Unfortunately, many people’s understanding of a domain model (or “entity” in Clean Architecture) goes against what I follow, which is akin to Domain Driven Design’s understanding, which I believe Uncle Bob (the creator of Clean Architecture) leans toward as well. With that said, I’m fine with letting others do that part however they like, since there are so many conflicting ideas about it. Really, the pattern is fine, except for the one anti-pattern I’m focusing on today.
Cyclic References in MVP
From what I’ve seen, everyone implements MVP with a cyclic reference. And I can understand why, it’s the simplest and most obvious way to implement the pattern. Almost no matter what system you develop in, the View is also going to be the system that receives events, and for the events (or commands derived from the events) to get to the Presenter, the View must have a reference to the Presenter. This is all as it should be. The problem comes from the fact that the Presenter is then expected to give commands back to the View after doing its business with the Model. Typically, this is done by a simple method call on the View object that is stored on the Presenter. Boom! Cyclic reference. The View holds a reference to the Presenter, which holds a reference to the View.
How Do We Get Around This?
The most obvious way to get around a cyclic reference is to instead pass the View in as an argument to the Presenter’s methods. This is simple, straightforward, and just a tad tedious (that’s a lot of typing “this”), but if you care about avoiding cyclic references, this is certainly a way to go.
Another way to go is to return some sort of command object. This is sort of old-fashioned OO and would likely require a lot of type checking and casting to determine which kind of command is returned and grabbing the data needed to do it. I would not recommend this.
A “solution” that I’ve seen someone use is to make the reference to the View a weak reference (one that isn’t counted by the garbage collector). While this gets around the biggest reason why cyclic references are bad, it doesn’t actually get rid of the cycle. If you don’t really care about cyclic references, I would still recommend doing this at least, and if you’re doing MVP in Android, I recommend checking out the android-arch-sample repository on GitHub, as it shows how someone can use a weak reference as well as some other scaffolding to make it so the Presenter replaces its View object when there’s a configuration change (such as rotating the screen), since configuration changes cause the Activity (which doubles as the View) to be destroyed and rebuilt. It also has the single greatest use of a stateful Singleton I’ve ever seen. There’s a way around it needing to be a Singleton, I’m sure, but I don’t actually want to get around it, it’s so clever.
So, what do I think is the best solution to avoiding cyclic references? Lambdas. It’s similar to the command solution, but instead of returning a command, you returns an anonymous function via lambda or method reference which the View will then call, passing itself in as an argument. It’s more functional, and not just because it uses higher-order functions. Rather, it’s more functional because the Presenter methods now have something to return. They can be pure (though they’re not likely to be because the model will be accessing some sort of mutable data store, most likely), since they’re not calling the “void” methods on View. It leaves the impure functions to be called at the outermost layer, the View, which is ideal.
What Do I Really Think?
Now, having said that I think that lambdas are the best solution, I’m not actually convinced of that. Theoretically, it’s the best, since the Presenter never has any reference to the View, but is it actually?
- It relies on the View to call the returned function, which it can totally ignore doing, and easily forget to do.
- Even using lambdas isn’t likely to keep the Presenter pure because it accesses the Model, which is likely to use a mutable data store.
- All you’re really doing is moving the same calls you were going to make anyway, but not they’re in a lambda or method reference.
My actual suggestion, until I can come up with a better idea or better reason for something else, is to pass the View in as an argument. That is, unless you’re using Android (it’s the only system I know of that destroys and completely rebuilds its Activities – or equivalent), where I recommend following the pattern in the android-arch-sample repository.
Until next time, thank you for reading.
Kotlin doesn’t have true pattern matching, and that’s fine. In order to make matchable classes in Scala, there is an awful lot of overhead required to make it work, and I highly respect Kotlin’s goal of not adding much overhead anywhere. But that doesn’t mean we can’t try to make our own way to get something closer to pattern matching. Continue Reading
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.
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
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