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.
java
All posts tagged java
Disclaimer: This is going to come off a bit ranty. I’m not as frustrated by the “problems” I bring us as it sounds; rather, it is used to emphasize why my thought processes did what it did. I’m not even going to be using header titles, which is weird for me 🙂
I’ve had a recent thought process about calling functions. It has been ceaselessly frustrating to me how functional languages (and even other languages at times) accomplish a certain goal.
That goal is chaining calls. Continue Reading
Today’s article is something a little special. It’s the first article where I use code from my current personal project for examples. You will be getting “real world” examples and not silly, made-up examples like my Scientist and Pen example in my factories article.
Back in January, I wrote a post about some changes I would love to see in the Java language that would make me like it a lot more (and would make it more modern). A lot of people suggested a lot of JVM languages, but I largely dismissed them because that’s not what I was looking for. I wanted Java to be different in these ways, since I’m not likely to convince my workplace to let me use something other than Java. And besides, most of the JVM languages suggested have some syntactic ideas that are simply difficult for my eyes to pick up on.
But…
But, then I found Kotlin. It’s a JVM language made by JetBrains, the creators of IntelliJ, PyCharm and a few other IDEs and tools. For the most part, I feel like these guys read my mind about what I wanted from my language. They missed a few things on my post, but they have so many things I had forgotten or didn’t even think about. Continue Reading
The Law of Demeter is an interesting programming principle. It’s the only one I know of that has a near-mathematical definition:
Any method m of an object O may only invoke the methods of the following kinds of objects:
- O itself
- m‘s parameters
- Any objects created/instantiated within m
- O‘s direct component objects
- A global variable, accessible by O, in the scope of m
In case you didn’t realize, this list doesn’t allow you to call the methods of anything returned by any of the methods allowed. It essentially prohibits chaining of method calls. I’ll give some exceptions to that in a bit. Continue Reading
Programming Ideas With Jake 