Blog.CBojar.net

When I'm doing design and refactoring, part of me worries that I'm just creating a mess of objects and classes. One of the kinds of mess that I feel I make the most are lateral abstractions. What I mean by lateral abstraction is an abstraction that is at the same level as the code I abstracted it out of. It doesn't add very much to the conversation, and it doesn't introduce a finer vocabulary than was already there. When looking over the code I wrote in Writing a Better Code Narrative , I get a slight feeling in the back of my head that some of that code is lateral abstraction. Without re-posting all of the code (which can be found here ), I started with a CommandParser class that read a string of character commands and "executed" those commands to produce a new output string. The original code was intentionally hairy, but I refactored it down into a series of Command classes to encapsulate the individual behaviors, and a CommandFactory to encapsulate the...

I recently just finished reading Growing Object-Oriented Software, Guided by Tests (or GOOS for short) by Nat Pryce and Steve Freeman. I highly recommend every developer pick up a copy and give it a read. It is full of great advice for building a well-tested, high quality application. I wanted to pick out two particular gems I found towards the end of the book that I felt are really powerful. [W]e like to have names for the relationships between objects as well as objects themselves. As the legends say, if we have something's true name, we can control it. – Growing Object-Oriented Software Guided by Tests , page 244 (authors' emphasis) They are talking specifically about preferring to mock interfaces rather than concrete implementations, but this concept bubbles up generally throughout the book. They use interfaces extensively, even noting that their use is above average, to tease out concepts and relationships in the code. Many in the community feel that interfaces are j...

I am currently reading through Growing Object-Oriented Software Guided by Tests by Nat Pryce and Steve Freeman. It is a great read and I highly recommend it. They describe a methodology for building high-quality software from the ground up, using all levels of testing to ensure that quality and functionality. Early in the book, they cover many concepts that are commonly heard in the developer community, including YAGNI and refactoring . Later in the book, they use a "real-world", messy example to demonstrate their methodology. At the end of chapter 16, about halfway through their real-world example, something struck me in their observations for the chapter. They are leaving the example in an ugly state in need of refactoring. In their observations, they state: So now that everything works we can get on with more features, right? Wrong. We don't believe that "working" is the same thing as "finished." … [W]e can either clean it up now, while it...

I was answering a question on Programmers.SE the other day, as I am wont to do from time to time, and something interesting struck me. As I was constructing my answer, I found myself looking for a design pattern to name that would be apropos for the situation (I settled on the command pattern ), and while I was grasping for the right one, I thought, I want the one where we put an object in between. It hit me: that's almost all of them! That's right, nearly every design pattern is basically just "create an intermediate object to encapsulate what you want." For example, we have the command pattern: create an object that calls behavior in the way that we want. We have the adapter pattern : create an object that transforms what we have to what we want. We have the strategy pattern : create an object that will polymorphically perform a behavior we want. As I realized that, I felt like, while design patterns offer a great way to name and model a certain solution when...

In many languages, interfaces and abstract classes serve as constructs for abstractions. Other languages rely on duck typing for the same purpose. Either way, we hide the underlying complexity of implementations under simpler façades. Though we may use these abstractions, all too often we don't trust these abstractions. Developers frequently talk about how they can't use an abstract type. They need to know exactly what concrete type of object they are dealing with. But in many cases, we don't or even can't know. It's possible that it is some second- or third-party type that we've never seen. How could we possibly trust some unknown code that is just shoved willy-nilly into ours? But do we really need to know the concrete runtime type? Knowing can simplify debugging. When I need to chase a bug, I need to know where to look. If it is in some indeterminate subtype, how will I be able to track it down? This is a legitimate concern. But tools help there. Mod...

Recently I received a SunnyPeak Google Cardboard Viewer as a gift. The technology is pretty cool, allowing for any Android device to act as an inexpensive VR headset. There are a number of apps that provide interesting 3-D environments to explore. The challenge I ran into was that Google Cardboard does not work correctly on my Samsung Galaxy SIII. Instead of taking up the whole screen, the images take up only a part of the screen . A simple fix would be to change the settings in the Cardboard app, but Google made life way more "convenient" by allowing the settings to be changed only through scanning a QR code. After some Googling around, I came across a post where someone else was having the same problem. In the comments, someone had the answer . In short, the comment gives a link to a page to generate a settings QR code, and the settings to put in. After following the instructions, the app configured itself correctly and it worked great! If you are having the same probl...

Writing code is like writing a book in a lot of ways. Like a book, code is read far more often than it is written. Therefore, like a book, code should be written in a way that gives it a clear narrative. By having a clear narrative, one can follow the code and understand it without too much head scratching. There is a lot of code out there that doesn't have a clear narrative. It meanders and backtracks, leading to confusion. One of the biggest contributors to confusing structure is the complex if statement. if 's and else 's take the story back and forth, and all over the place. There are many tools in good design to fight the confusing tendencies of complex if 's. One that changed the way I write my code significantly is the guard clause . Rather than wrapping a whole bunch of code in a big if , we reverse the condition and return early. Rather than worrying about the condition the whole way down, we can conceptually just eliminate that case as early as possible. Gu...