SOLID is an acronym for a set of important design principles. Paired together they create a framework for worry free code, and by “worry free” I am speaking of code that would trouble you if any changes needed to be made. In the world today things are constantly changing and being updated and so should your code. If that’s the case then any code you write should have the ability to be edited without causing a complete overhaul of your whole program. Basically what you want to avoid is trickle down effects, and unlike trickle down economics, this is real. If you change one thing or responsibility of a class or variable and that causes a cascade of continuous changes and troubles, then you are experiencing this trickle down effect. To help with this issue is the first design principle in the acronym, Single Responsibility Principle.

Single Responsibility Principle is exactly what it sounds like. Give your classes and methods a sole responsibility so that if they are changed it will only effect that method or classes responsibility. If a class or method handles multiple responsibilities then changing the design of one part may be cause to change the entire entity. 

A crude example would be a Rectangle Class. Let us say you have a constructor to build a rectangle object and all it does is take arguments for height and width. However, you also add if and else statements in the constructor to see if the dimensions make a square and printing a confirmation message if it is. Perhaps you even write “if (myShape.isSquare())..” to send the object to a method to, but this is giving the constructor more than one responsibility. If you decide to change the placement of the square check then there will either be duplicated code or you will have to edit the constructor to pass the isSquare result to other methods. Doing any of this would result is test case changes if you were testing the code. In this scenario it is best to have the constructor just be the constructor and to dedicate the square check to its own method like isSquare. In this case if changes were made then only a single class would require changes and not several that are connected in a convoluted fashion.

I think the Single Responsibility Principle is a must know. I remember beginning coding is CS140 and Data Structures and I would try to get as much done in as few methods as possible by cramming in multiple functions into them. I thought the less methods the better but I was so wrong, it’s worth so much more to have many separate methods and classes that each have a sole function. This way code is organized, easy to arrange, and simple to implement or change.

SOLID Design Principles Explained: The Single Responsibility Principle. (2018, December 17). Retrieved from https://stackify.com/solid-design-principles/

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

There are many design patterns that assist in building software architecture. They fall into four categories: creational; structural; behavioral; and concurrency. Each of these groups has many specific design patterns, but to focus on more than a single pattern in a blog post would be remiss.

The Coding Blocks Podcast has a series on design patterns, the first of which discusses creational patterns, which are described in the “Gang of Four” book, “Design Patterns” [1]. While the hosts find the overuse of these design patterns humorous, they admit that seeing the word “Factory” instantly describes code at a higher level. Furthermore, design patterns assist in adhering to other object-oriented design principles.

[Design Patterns] help make a system independent of how its objects are created, composed, and represented. 

– Design Patterns, Gamma, E., et al

I have come to strongly dislike nested if statements, checking if a subclass is an instance of a superclass, and switch statements. Clean Code by Robert Martin [2] has influenced that a lot, because it made me realize there’s a better way.

Imagine an app that asks the user what kind of Car they would like. This car needs to drive(), brake(), and calculateFuelCost(). Assume there are dozens of types of Car, each implementing the Car interface with these methods. The app will need a bloated switch statement to make all of these concrete classes, depending on user input.

The idea behind the Factory design pattern is that there is a separate class that creates concrete objects, but returns an abstraction (an abstract class or interface). You don’t need to scatter logic across an application that determines which type of “Car” should be created, for example. In fact, you don’t even need or want to know what kind of car it is, once it’s created. A CarFactory class returns an Abstract Car or a Car Interface. In the case of an interface, concrete classes such as ElectricCar or HybridCar implement the Car interface.

The result is an application that can create a CarFactory, tell it what kind of car the user wants, and then manipulate the returned interface as needed. And no matter the concrete object it gets back, it can be treated the same. This separates the application logic from specific implementation of concrete Car classes.

So when your application needs to add a FlyingCar option, a concrete class can be created that implements the same Car interface. The application only needs to tell the CarFactory to create a new FlyingCar object. The rest can be treated identically, because the CarFactory returns an interface with all the required methods.

As stated in the podcast episode, if this is confusing it means you’re learning. These patterns are not trivial to learn, and require many more examples and plenty of UML diagrams to fully understand the idea behind the pattern.

[1] Gamma, E., et al. Design Patterns:Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.
[2] Martin, Robert C., et al. Clean Code: a Handbook of Agile Software Craftsmanship. Prentice Hall, 2016.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.

Hi dear readers and welcome back to my blog. Today I am going to talk about another Pattern that I read from the book Apprenticeship Patterns. This blog post will be about familiar tools.

Once we start working or coding on our own we start to like and choose which tools we like and which ones we do not. It is just a matter of time for us to figure it out. Once we do though, its hard to switch. When I started coding, I was only learning tools that were recommended from our professors in school and as I was ‘scared’ to experiment I always choose not to switch even if I didn’t like it. Going to work and school at the same time was amazing as I was facing new tools in both environments and I was able to tell which ones I liked and found more useful and made me more productive. And as the book says, once you find your favorite tools, its hard to switch!!

This chapter talked about how all of us have our own favorite tools and we find it hard to switch even if the productivity sake is in risk. It would be our decision on weather to give up our tools or not but we have to face consequences. At the same time, just because a tool is great for you don’t mean it will  be great for someone else. Something that you might find easy, might be hard for someone else.

There is one example I would like to give for this Pattern. I started to use Eclipse on my second semester of Computer Science and I wasn’t crazy about it, but as we had just transited from BlueJ was very cool. Two semester later is when I started my job and over there the developers were using more advances IDEs and I was very excited to learn and get familiar. Eclipse went out of my list right when I learned about Illuminated Clouds. Very ‘smart’ IDE! However, Eclipse was still the only option in school and I was hating it and started to recommend to other people. Some of my friends found it very useful to use and some others already loved Eclipse for what it was.

Last but not least, I really liked the recommendation from the book that was suggesting to have developers create a list for all familiar tools and keep researching is the list was smaller than 5. All of us will probably change lots of jobs and lots of companies will have their tools, but its always good to have your own area of expertise.

Hope you guys found this blog useful…Stay tuned for the next Pattern from this cool book!

From the blog CS@Worcester – Danja's Blog by danja9 and used with permission of the author. All other rights reserved by the author.

This method talks about how indulging in your own artistic nature isn’t always the best option even if you think the product would turn out better if you did it this way. If you are being paid to build something that will solve a problem, this method of Craft over Art explains you need to really consider the situation at hand. In this method, the situation that is discussed is that you believe that you are able to do something outstanding and fantastic that will impress your colleagues. In this situation, you are building something for a user. You shouldn’t be indulging in artistic expression. A lot of the times when we are handed with a task, we can sometimes think about the most outstanding ways to do something, rather than just to get the task done. This can go two ways. Doing something outstanding for a task can be great and have it’s benefits, but what will it cost the effectiveness of it? On the other hand, we can do the task at hand and that will be that. We won’t be able to put any personal expression in it, but is that a bad thing? Of course it isn’t a bad thing. This method seems to be very similar to function over form.

It is a matter of situational awareness. This is something I really enjoyed from this article. Make more straightforward choices and do not try to “sugar coat” solutions. As soon as you start making unfavorable trade offs in certain scenarios, the outcome will not always be as you like. in other words if you want a straightforward answer, you should provide a straight forward solution. Even though this isn’t always the case, I learned that you should always try your best to just try and perform the basic tasks first without adding anything extra or unique. Quality takes time, but having the correct operations in a product is what can make all the difference.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.