Author Archives: jwblash

AntiPatterns: The God Class

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.

The Testing (Automation) Pyramid

The Testing Automation Pyramid (sometimes just called the “Testing Pyramid”) is an Agile methodology that involves a heavy reliance on Unit Tests as opposed to UI-based testing. It’s referred to as a “pyramid” because the width of the layers in the pyramid refers to the ideal number of tests per layer. The bottom, widest layer is Unit Testing, the middle layer consists of service-related tests, and the tip of the pyramid represents UI Tests. A picture of the structure is shown below, sourced from Martin Fowler’s blog.

test-pyramid
Moving up the pyramid, the type of testing done costs more resources to execute and more time to assess.

Part of the reason why UI testing takes significantly more resources is because it involves interacting with and logging the operations of the interface in order to see where something may go wrong. Running through the operations of the UI to see where it breaks takes a very long time, as there are so many levels of abstraction between the UI and the underlying infrastructure, and so much functionality within User Interfaces. On top of this, as the product is updated and refactored, tests derived from the original UI interface becomes obsolete, making the lifespan of higher-level tests shorter than those aimed towards the low-level structure of the system.

This is why Unit Tests are so good. They’re a cheaper (in terms of both resources and time) alternative, and they provide a means of testing the actual root of the issue. Unit Tests are preventative and they ensure that a bug presenting itself in the UI level stays fixed, rather than allowing the bug to manifest itself in a variety of different ways.

There is quite a bit of criticism of this model, as if it goes unchecked it ends up as the so called “Ice Cream Cone” anti-pattern, where a small layer of exploratory manual testing above the UI testing layer ends up becoming mandatory manual testing, which becomes both a resource and a time sink. This is far better explained by viewing Alister Scott’s blog post on it over at his blog, WatirMelon.

Martin Fowler, whose blog I found this concept on and referenced earlier, summed it all up in a pretty wonderful way: “If you get a failure in a high level test, not just do you have a bug in your functional code, you also have a missing or incorrect unit test.” Martin’s blog post elaborates on the idea much better than I’m able to, and his blog is extremely readable and has really great content. I’ll definitely be using it as a resource in the future.

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

Your Interfaces Are Your Responsibility

This week, I looked through the Google Testing Blog and spotted a great post regarding your job as a programmer in writing good interfaces. I thought it touched on some great points and used some great examples, so here I am, writing about it. The blog post is part of a series of posts from Google called “Code Health”, which essentially outlines some of their standards for code quality.

“Code Health: Make Interfaces Hard to Misuse” uses an example of an empty Vector which has a “num_slots” slots available for use. Marek Kiszkis, the author, outlines two ways to write this class. The first way relies on the person who implements it to manage the expansion of the number of slots of the vector. They must check the slots remaining before adding into it to ensure that it has the room for a new item. The second way the Vector class is written has the Vector automatically expanding by a certain number of slots as items are added in. The implementer has very little control over the function of the Vector, however the Vector’s lack of flexibility can be a desirable outcome, as misuse much more difficult. The author provided a few different examples beyond this of easy-to-misuse Interfaces, such as requiring the caller to run initialization functions, perform cleanup, etc.

The article is finished off with a reminder that, while making interfaces this way is a good thing, you still need to be selective with this methodology. Sometimes writing an interface in a “overly-defensive” way will result in needlessly complex code, where implementation is more difficult to execute than necessary. The documentation is equally as important as the structure of the code, and keeping that in mind will help you write usable, stable, and effective code for others to utilize.

I found this blog post surprisingly relevant to my current course-load. In both this class (CS-443) and the Software Architecture & Design class (CS-343), will be implementing interfaces much more frequently than we have in previous courses. Having a better understanding of safe and effective ways to writing them will be extremely useful in the long run.

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

The Importance of Names

I’ve heard a lot of great things about “Clean Code” by Robert “Uncle Bob” Martin, and when I saw that the Coding Blocks Podcast had done a small series reflecting on the material of the book, I jumped right in.

Clean Code (although I haven’t read it yet) is a book that aims to set a standard in software craftsmanship, so that code isn’t lost as a result of being difficult to reuse, refactor, or even… well, read. The podcast reflected on Chapter 2 of the book, Meaningful Names. Allen Underwood and Michael Outlaw discussed major points that the chapter touched on and their personal experiences with each.

The segment that may have had the most impact on my outlook towards this subject was one of the first ones in the podcast — that the names of variables and methods should be as descriptive as possible, so that you don’t necessarily need to write a comment that explains what it does. This seems self explanatory, but I’ve already caught myself feeling compelled to comment every variable I declare in order to explain the differences between nondescript declarations like numDays and dayNum. Even if it’s just a small personal project, getting in the habit of writing effective variable names is a practice to start sooner rather than later.

They made another great point later on during the show too — Don’t be afraid of long variable/method names! So far in my educational experience, I don’t think I’ve needed to bother with a program that was more than ~500 lines total. In this case, it’s pretty easy to scroll to find what you’re looking for in each class. However when you’re dealing with a full software program, having a variable name that is easily searchable can save an enormous amount of time.

Certain topics touched on, like the “Hungarian Method” for example, I was completely unfamiliar with. I think standards like that may have been more niche or were perhaps prevalent before my time writing code. I agreed with what they said about it in the podcast, and I think the idea of a common naming convention is a good one however having code that is clear and easily readable is a better alternative.

This series of podcasts were really good, so I’ll likely be writing about it a lot more in the near future. There was a whole lot more that they went over, and it definitely made me interested in reading this book.

Here‘s a link to the episode on their website, check it out!

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

CS-343 Introduction

Hello! My name is James and this is my introductory post for CS-343, Software Design, Construction, and Architecture.

See you all in class!

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

CS-443 First Blog Post

Hey All! My name is James. This is my my introductory blog post for CS-443, Software Quality Assurance & Testing. I actually don’t know much about this subject and I’m excited to change that.

Here’s to a great semester!

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