Earlier this semester in my Software Design class, we had an assignment where we were to choose to write a report on either the Proxy, Facade, or Decorator design patterns (or any combination of the three, for extra credit). I had chosen the Decorator pattern, and due to the amount of assignments I had due I never went back to examine Proxy or Facade. So I’m here to do just that with the assistance of Sourcemaking’s article on it, starting with Proxy.

The Proxy is a structural design pattern that adds a wrapper to an object so that the object itself doesn’t suffer from excess complexity. There are actually a large number of reasons where this is useful. Sometimes objects get excessively resource heavy, and you don’t want to instantiate them unless absolutely necessary. Sometimes you’d just like an extra layer of protection from the access of an object for the sake of security or for general ease of use. Consider getter and setter methods for an example — you don’t want open access to the data within your object, so you make the data private (hidden from outside access) and you instead create public methods for retrieving and change the data of the private variables. In a way, getter and setter methods are mini proxies. Of course, the difference is that proxies are meant to be entire objects in themselves.

For a real-world example I’ll reference Sourcemaking’s article. In order to make a payment, someone would use the funds that they have in their bank account. Instead of needing to add methods such as “makePayment()” to their account and increasing the Account’s complexity, it is possible instead to pay with a check which can indirectly access the funds of the account. In this example, the check is the proxy to the Account class. Here’s a UML-like diagram:

The Proxy design pattern serves many purposes and is perhaps one of the easiest design patterns (in my opinion, of course) to understand and use. It’s very similar to Decorator in structure (which I did a project on earlier this semester) but its’ implementation is slightly different. Decorators are used to add new functionality to an object, whereas the Proxy is designed to encapsulate existing functionality into another, “adjacent” object.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

I’ve been discussing AntiPatterns quite a bit lately, so I elected to switch it up and talk a bit about Anti-AntiPatterns, aka Design Patterns. As a quick recap: If AntiPatterns are common bad practice traps that developers/teams can fall into, then Design Patterns are good practices which help guide them to either avoid AntiPatterns, or to lean towards a more efficient solution.

One design pattern we’ve used many times in my Data Structures class is the iterator, and personally feel as though it was never fully explained to the class as to what an iterator even really is, let alone why we were writing one. This post from Sourcemaking.com helped a lot in terms of learning what the use of them is.

As covered in the article, there has been a push in recent programming towards something called “Generic Programming”, and the iterator is a core idea within it. An iterator is an attempt to abstract out the traversal of data items in a data structure into a separate thing. The usefulness of this is outlined by an example given in the article:

“As an example, if you wanted to support four data structures (array, binary tree, linked list, and hash table) and three algorithms (sort, find, and merge), a traditional approach would require four times three permutations to develop and maintain. Whereas, a generic programming approach would only require four plus three configuration items.”

– Sourcemaking.com

So essentially, your iterator is an object in itself that handles the job of traversing through the objects in a list. A real-world example of this may be the AM/FM radio controls in your car. The radio stations are the objects in a list, with their station name and frequency (or channel, I suppose) as their data. The iterator would be your “scan” button, which skips over the stations with fuzzy signals in order to reach the next one whose frequency is available to you, while all you did was press the one button. Each station is a data point in your list (your data structure) with a station name and a frequency. You, the driver, don’t need to know anything about the details of the stations you’re scanning over, because the iterator (the scan button) handles that for you when finding the next available station.

The article from Sourcemaking has several really great UML diagrams and other examples to pick apart which help elaborate on the subject even further. I highly suggest visiting their website to read more about it — they have detailed explanations on almost every type of AntiPattern and Design Pattern I’ve looked into so far.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Design Patterns have grown to become a standard in the field of Software Development ever since the Gang of Four published their book, Design Patterns: Elements of Reusable Object-Oriented Software in 1994. However, some people in the field of Computer Science have leveled criticisms towards Design Patterns for a few reasons, even if it is widely accepted that they are tools in the belts of developers at this point.

A legitimate criticism of them seems to be that many of the patterns are heavily language dependent, as some languages have easier work arounds for problems that present themselves in others. Peter Norvig, a director of research at Google, showed that 16 of 23 patterns from the Design Patterns book can be replaced solely by implementing them in Lisp or Dylan rather than C++ (page 9 of this PDF). Part of the argument here is that if languages don’t have the same design patterns, then those languages that do have more design patterns are requiring that developers find work arounds for their missing features.

Another issue that many seem bring up is that the emphasis on using design patterns results in developers relying on them too heavily. Similar to the Golden Hammer AntiPattern, once a developer (or team of developers) becomes comfortable with a tool or concept they end up attempting to cram the problems they’re given into some implementation that would allow them to use the solution they’re comfortable with. In this way, even if Design Patterns are intended with the intention of writing code in good practice, if they’re implemented when it isn’t necessary it can quickly turn sour.

The idea behind Design Patterns is that, if they are used correctly alongside correct Object Oriented Design principles, the patterns should emerge naturally. If you ever find yourself asking, “How can I use the Singleton Pattern here?”, then you’re misusing the tool in your tool belt. They are better viewed as teaching methods for successfully upholding good design in complex situations, in a way. If you’re writing code and it dawns on you that what you’re attempting to write is similar to a pre-existing design pattern, then you have a direction to follow. This article in particular gives a great example of an application of the template pattern, and shows how you’d get there in a natural way as opposed to forcing a pattern on a piece of code. 

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Another day, another blog post about a concept from Sourcemaking.com, this time on the Golden Hammer AntiPattern.

Software Development is a field that requires continuous learning throughout your entire career. With the sheer amount of tools at your disposal, it can be daunting to try to expand your skillset. However, knowing how to utilize as many tools as possible is important to help make an effective and well-rounded developer. Not only that, being brave enough to drop the tried and true way of doing things for newer, more effective solutions is an important soft skill to have as a team.

We’ve all heard of the expression, “If all you have is a hammer, everything looks like a nail.”, and that’s the exact origin this AntiPattern. When a team fails to develop their knowledge and expand their skillset, they often fall back on the same process that they’ve used in the past. Sometimes, a significant financial investment has been made into training the team to use a specific product, and so they don’t want to let that methodology go to waste. That’s fine, except for the fact that there is a unique way to approach nearly every new problem that developers come across. Reusing old system design is a sure fire way to cause more problems than necessary for the development process.

There are countless issues with this approach — it’s like trying to fit a square peg in a round hole. In a way, teams will end up warping the problem in order to make their solution work, as opposed to designing a good solution for the problem. It’s self limiting too, because teams will only end up choosing problems that they feel comfortable with, relating back to approaches they have taken in the past. Not only this, but if the Golden Hammer is a particular product or tool made by another company, then the team can find themselves at the mercy of that company to continue support for that product.

Not only does this AntiPattern require a tremendous amount of refactoring (usually, a complete reworking of the product is necessary), it requires a change in the philosophy of the developer(s). Each and every member of the team needs to be focused on expanding their knowledge of shifting trends in technology, and there must be an emphasis on the exploration of new tools in the workplace with some leeway in deadlines as a result.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Many AntiPatterns seem to arise when code structure is ignored and foundational concepts like those of OOPs are forgotten. Spaghetti Code is perhaps the most common and widespread of these, since it can come about so easily in nearly any program regardless of the language or paradigm. In a general sense, it is unstructured code that is difficult to read, edit, or use.

Spaghetti Code involves a very cluttered, messy design (or lack thereof). There are many moving parts which seem disorganized and generally readability is extremely, low even for the original developer. It’s much more easily found in procedural paradigms as Object Oriented paradigms were made partially to avoid this problem in particular. If Spaghetti code is found in an Object Oriented system, the structure often reflects that of a procedural program.

I’ve written about The God Class before, which is a concept that stems from similar errors, except in a slightly different form. Spaghetti Code differs from this in that the God Class has one central core class that makes extending and modifying anything more of a challenge than is necessary. Spaghetti Code generally has several large classes which run in a single, multistage process. Sometimes this kind of messy code can be found within other AntiPatterns, such as Lava Flow. Dead ends of routes taken with old projects can result in a jumbled mess of irrelevant code that is hanging around for no reason other than it is difficult to read.

So what can we do about it? Well, like many other AntiPatterns, the best solution is to take a preventative approach. Make sure that a clearly defined structure for the program is outlined before starting to develop. Make sure that when modifying the existing code, the developer adheres to the structure in place. If you’ve found yourself in a position where you need to refactor Spaghetti Code, it could potentially be a case of diminishing returns where trying to “fix” the program is more difficult than rebuilding it from the ground up. This is a massive waste of development time and money, since if a clear goal were in place to begin with the problem could have been avoided all together.

At the end of the day, a clear vision and game plan for the software you’re writing is the most important piece of development. Without a path to follow, problems become difficult to solve and solutions become difficult to implement — especially when developing a large scale software system.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

If you’ve ever contributed to Open Source projects (or ever tried to code pretty much ever), the concept of Lava Flow probably isn’t very foreign to you. 

Throughout the course of the development of a piece of software, teams take different approaches to achieve their end goal. Sometimes management changes, sometimes the scope or specification of the project is altered, or sometimes the team simply decides on a different approach. These changes leave behind stray branches of code that may not necessarily align with the intent of the final product. These are what we refer to as “Lava Flows”.

If the current development pathway is a bright, burning, flowing stream of lava, then old, stagnant, dead code hanging around in the program is a hardened, basalt-like run-off that is lingering in the final product. 

Lava Flow adds immense complexity to the program and makes it significantly more difficult to refactor — in fact, that difficulty to refactor is largely what causes lava flow in the first place. Programmers don’t want to touch code that they don’t fully understand because they run the risk of interfering with the functionality of the working product. In a way, the flows grow exponentially because developers create loose work arounds to implement pieces of code that may not even need to be implemented at all. Over time, the flow hardens into a part of the final product, even if it contributes nothing at all to the flowing development path.

So what can we do about this AntiPattern? The first and perhaps most important thing is to make sure that developers take the time to write easy to read, well documented code that is actually relevant to the final project. It is far more important to take a preventative approach to Lava Flow, because refactoring massive chunks of code takes an exorbitant amount of time and money. When large amounts of code are removed, it’s important to understand why any bugs that pop up are happening. Looking for quick solutions without have a full grasp of the problems will just continue to accentuate the original problem.

I found out this AntiPattern through SourceMaking.com’s blog on it, which delves much deeper into the causes, problems, and solutions involved with this it. I strongly recommend checking out that post as well, as it is far more elaborate than mine and gives great real-world examples along with it.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

We can all remember back to writing programs in our Intro to Programming course, where (if you were learning an OOP language like Java) you placed nearly everything into the main method just for the sake of learning. Projects continued to be approached like that for awhile, until you learned about inheritance and class hierarchies and why putting everything into main is actually not the best idea. It removes the basic principles of OOPs and essentially turns the project into a procedural program.

That is essentially what the God Class, AKA the Blob, does. Any related classes that are used are generally there to store data, and there is a big central class that is core to the functionality of the program. The God Class contains both operations and data relating to an extremely large amount of other classes, and acts as a controller for all of them. They generally seem to arise when time constraints and specification demands are placed on people who already have a shaky foundation in OOP principles. Either that, or often times when writing code developers will add small bits and pieces to existing software that they’re using, and some classes (especially controller-type classes) end up getting a disproportionate amount of these small changes over time.

In terms of drawbacks, there are a lot. It makes updating infrastructure far more complex than necessary, and it makes seamlessly fixing bugs in that system extremely difficult. Blobs are hard to test since there are just so many operations that work together within them, and when you create an object in memory there may be a significant portion of its’ functionality that you’re neglecting which soaks up running times.

So what can we do to refactor a God Class when we see it? First, find methods within the God Class that deal with one another and group them together. If developers have been slowly adding functionality to a controller that has resulted in a Blob-type class, then there should be a good amount of operations within it that could be grouped together. Then, either move those groups of operations into classes which they call upon in some way or create new, smaller classes which perform in the same way. Through doing this, you can extend the functionality of existing classes and reduce the complexity of your Blob. In the long term, reducing God Class complexity will assist in future testing, refactoring and will prevent annoying bugs from popping up that intrude on your beautiful OOP system design.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.