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.

No one likes messy code, and everyone likes simplified code, so I was interested in learning more about refactoring. While the idea of enhancing code sounds fairly intuitive, I wanted to learn more about tips and practices to use when refactoring code. In the past, I’ve been guilty of leaving my code in rough shape, until after I finished. While my habits have improved, I still have a lot to learn in these regards. To help learn some refactoring methods and practices, I listened to episode of 78 of Full Stack Radio, with guest Ben Orenstein. Orenstein, dubbed “one of the refactoring guys”, formerly worked at Thoughtbot in Boston, and now offers a course on refactoring, as well as gives lectures on the subject.

What I really liked about this podcast with Orenstein is how direct he was with all his tips. None of his advice sounded complicated, because he used very simple, explicit language. In fact, this type of language demonstrated one of his tips: “make the implicit explicit”. For example, give full words when naming object. If there’s an intermediate equation in the middle of a method, leave comments or naming conventions that clearly state why it’s there and what it leads to. Too often, I’ve used vague abbreviations in my naming conventions. While in most small-scale programs, this isn’t an issue, I realize this could be very problematic on larger projects.

“first make the change easy, then make the easy change.”

One of the best tips I thought Orenstein offered during the podcast was preparatory refactoring, or to refactor code before making changes, rather than refactoring while making changes. In this regard, your preemptive changes can cause you to have to make less changes further down the line. He gave an example of once refactoring code prior to a new feature being implemented. In the end, the new feature was pulled and not implemented, but his refactoring in advance still improved the codes functionality.

I feel like I took a lot away from this, from small tips to things I never thought about. Something that caught me slightly off-guard was when Orenstein talked about not wanting to return null values but replacing them with empty arrays. I don’t recall ever learning about this, and they didn’t go into much detail about it, so I researched it a little further on my own. This podcast helped highlight the importance of refactoring and I’m sure I’ll continue to research more refactoring methods throughout my career.

https://fullstackradio.com/78

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