For this post, I wanted to talk about code smells. I picked this topic since it was related to my software construction course, and I believe I could benefit from diving into it some more. In my course, I feel like I learned much more about design smells, but not as much relating to code smells. A code smell is a characteristic or surface indication that shows there may be a deeper underlying problem with a code. Typically, they’re easy to spot, but I wanted to learn more techniques to look for these problems. In the past, I’ve discussed refactoring, and this ties into that nicely. Learning more about code smells will allow me to become better at refactoring. In order to learn some more about code smells, I listened to episode 88 of the Complete Developer Podcast which was all about code smells.

In the podcast, the hosts discuss what code smells are, as well as methods and techniques to find code smells. I was already familiar with some of the smells mentioned in the podcast, which makes sense. I’ve been guilty of many of these as I first started learning code. Naturally, as you learn to code, refactor, and improve, you start picking up on some code smells, even if you don’t have an exact word or phrase for what the code smell is. I was much more interested in the podcast when they started discussing object-oriented smells, since this is much more relevant to what I’ve been studying most recently.

The most interesting smell I thought the hosts discussed was the Refused Bequest smell. Simply stated, refused bequest can occur when a subclass only uses a portion of properties and methods inherited from its parents. Unneeded methods can go completely unused or in some cases, give off exceptions. This is something I had never given much thought to, but it makes sense after hearing the hosts discuss it. I usually try to reuse my code as often as I can, so I could see myself making this type of error where I try to tie classes together through inheritance just to reuse my code. I’ve learned about delegation and using it rather than inheritance, but it’s not something I’m as comfortable with as I’d like. This segment in the podcast led me to go back and study delegation some more to improve my grasp on it.

From the blog CS@Worcester – Derek's Design by dereksspace and used with permission of the author. All other rights reserved by the author.

This semester, I spent a lot of time learning about object-oriented design. As my interest grew, naturally I wanted to learn more. In order to better my understanding of object-oriented programing, I listened to episode 142 of the Complete Developer Podcast on SOLID Principles. This podcast talks about about each of the 5 core principles of SOLID and how they’re implemented. The focus of SOLID is to make maintaining and extending code easier as a project grows. Proper use of SOLID design principles attributes to low coupling, high cohesion, and high encapsulation. It also helps to cut back on the need of refactoring, as well as avoiding code smells. SOLID stands for Single Responsibility Principle, Open-closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle.

The podcast reflects that SOLID design principles aren’t mandatory law, but rather should be utilized whenever they can to help improve code. The allow the code to be more flexible, but increase the complexity of the overall code. Personally, I felt that the Single Responsibility Principle was the most significant principle discussed in the podcast. To simply describe this principle, SOLID founder Robert C. Martin describes it as “A class should have one, and only one, reason to change.” In turn, following this principle can make software easier to understand and implement. Personally, this is something I tend to follow most of the time. However, there are times that I’ve tried to fit too many functions or responsibilities in a class. It doesn’t necessarily break the code, but I understand how it could make it harder to build off as the project grows.

I felt that many of these design principles tied into one another nicely in one way or another. For example, I could see a clear correlation between the Open-Closed Principle and the Single Responsibility Principle. The main idea behind the Open-Closed Principle is that objects and entities should be open for extension but closed for modification using object-oriented features such as interfaces, subclasses, and inheritance. While Single Responsibility Principle allows for modification to fix bugs, it explains how code can still be extended so long as each class has one sole responsibility. In this regard, I felt both design principles key emphasis is to avoid needless complexity. I think having this understanding now would have been beneficial for some of my prior classes, but I’m excited to have further knowledge of these tools to use in the future.

From the blog CS@Worcester – Derek's Design by dereksspace and used with permission of the author. All other rights reserved by the author.

Earlier this semester, we worked on an assignment regarding design patterns. I found this interesting as I took a deep dive into learning more about facades. As I’ve gotten deeper into the computer science program, assignments and projects have naturally gotten bigger and bigger. I was excited to learn more about facades, because it relies on two aspects important to large scale projects: simplicity, and restriction. It can make complex projects a bit easier to follow, as well as limiting what a client has access to.

While I learned a lot about facades through this assignment, I felt that I didn’t personally study enough about the other gang of four design patterns. To familiarize myself further that what I learned in class, I listened to episode 34 of the “complete developer podcast”, focused on design patterns. It wasn’t a thorough as I would have liked, but I was able to familiarize myself a bit more on behavioral and creational design patterns. Having studied facades closer, I was already a bit familiar with structural patterns. From their explanation, these 3 types of design patterns have a lot of cross over but tend to be categorized separately primarily for human understanding. I would have liked if they discussed some actual pattens within the creational, structural, and behavioral categories, such as certain ones they use more often than others.

One key takeaway I had with this podcast is how universal these object-oriented design patterns are. One of the hosts was appreciatively saying how he’s a .net developer but could talk to a Java or Ruby developer about any of these design patterns. They may not be familiar with the language, but they would be able to follow the structure of the code. The patterns themselves aren’t that complicated, but they’re capable of facilitating much more complicated programs. I also thought it was interesting, they referenced how some languages don’t need these patterns depending on the level of abstraction built into it.

I found their criticisms of design patterns to be the most useful to me. The hosts discussed certain misusages of design patterns, and these are things I can keep in mind going into the future. In particular, as some programs evolve, they may require a different design pattern than what’s originally implemented. What I take away from this is that it’s important to diagram your project before you get too invested in it. A simple UML diagram can likely show you if you’re using the right pattern, or if you’d need to change as you get further into the project.

From the blog CS@Worcester – Derek's Design by dereksspace and used with permission of the author. All other rights reserved by the author.

I have already written two separate blog posts on the topic of Class Diagrams (UML and ER) so it only seems right that I revisit how they relate to hierarchies in programming. During this semester, we transitions from UML Class Diagrams into hierarchies with class assignments and a homework project about ducks. The fact that the assignment was based on a program about ducks sounds funny, but it was actually a great example to work with for learning hierarchies better. Some ducks can fly, swim, quack, or squeak depending on the type of duck (including rubber ducks etc.). This is perfect because although all the duck types are considered “ducks,” they all cannot do the same things. This means that programming classes for the different ducks was extremely efficient if it had a good hierarchy for the classes. Rather than hard-programming what every duck could do one at a time, the hierarchy allows the programmer to write much less (as well as have a much easier time adding or deleting duck types). Obviously since all the ducks where considered “ducks” the main class we had to write was just the duck class. Every other class extended off this class and inherited functions from that class. If some ducks shared similar actions and properties, then they would be grouped together under another class and so on. This often creates a web/tree shape if the program where to be drawn out in a diagram. I have learned about hierarchies and their benefits and importance before this semester, but revisiting it is always good for me, especially since I have a bad habit of trying to hard-program things if I am not getting the hierarchy to work the way I want it to. For this post, I did not use a link, but I certainly would still recommend looking around the internet or in books to find all the information about this very important topic of computer programming. All of the studying, researching, and practicing is valuable!

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.