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
Opening disclaimer: this isn’t always a good idea. I’ll present the idea, along with some of the reasons why it’s a good idea, but then I’ll talk about some instances where it’s not so great.
As you may know, I’ve been dabbling in Python nearly as much as I’ve been working with Java. One thing that I’ve liked about Python as soon I found out about it is generators. They allow for lazy operations on collections, so you can pass iterators/generators around until you finally actually need the final result of the operations – without affecting the original collection (under most circumstances; but you’re not likely to affect it accidentally). Continue Reading
First Things First
First off, I’d like to open this article by letting you all know that, as of Sept 9, 2014, I am a certified Java programmer. I passed the level 1 Java SE 7 certification. Pretty soon, I’ll start studying up for the level 2 test, which I’ll probably take early next summer. What this means for all of you is this: I supposedly know what I’m talking, so you should definitely listen to everything I say 🙂
Yeah, level 1 isn’t that big of a deal. It mostly just means I know how the language works; it doesn’t mean I’m actually any good at programming with it.
Also, I just wanted to let you all know that I hope to make this blog do a post every week, on Saturdays. Time will tell whether I can keep up that pace, since I work full-time and do 1 or 2 posts in a gaming blog each week already, too. If you’re interesting in tabletop RPGs, you should check it out. Continue Reading
Singletons often instantiate themselves lazily, and sometimes, if the object is heavy enough, class fields can be instantiated lazily.
Generally, when going the lazy route, the getter method (or accessor) has to have a block of code that checks whether the object is instantiated yet (and, if it isn’t, it needs to be instantiated) before returning it. This check is pointless once the object has been instantiated; it only serves to slow down a method that’s already (usually) blocking with synchronized or a Lock. Let’s look at a way to remove that code, shall we?
I didn’t come up with this. I got it from Functional Programming in Java by Venkat Subramaniam. I highly recommend both the book and the author. Everything I’ve read by Venkat was well-done and easy to learn from. Continue Reading