Author Archives: Ryan Klenk


This week I learned about anti-patterns by reading “Anti Patterns” by Ilyana Smith. Smith explains “An Antipattern is a description of a “negative solution” and a corresponding “positive solution.” In other words, an Antipattern describes a common way of solving a problem that actually causes more harm than good, alongside an example of a better way to solve that problem”. Smith then gets into the details about each pattern and the problems they cause.

Smith tells us that there are seven deadly sins of software projects that are the root causes of problems. These “sins” are haste, apathy, narrow-mindedness, sloth, avarice (overcomplicating things), ignorance, and pride. There are 18 anti-patterns Smith talks about. These anti-patterns are analysis paralysis, architecture by implication, the blob, copy-paste programming, death by planning, design by committee, functional decomposition, functional decomposition, golden hammer, intellectual violence, lava flow, and poltergeist, reinvent the wheel, spaghetti code, stovepipe enterprise, Swiss army knife, vendor lock-in, and singleton.

As you can see, there are a lot of anti-patterns. I will not be able to describe all of them so I suggest reading the article yourself, but I will go through a few of them. Analysis paralysis is when a software team gets caught up in the design and planning phase and fails to start any development.  The blob is building a class that does most of the work and there are a few secondary classes that contain mostly data. Copy-paste programming is a problem because if there is a problem in the code you copied it will be everywhere you paste it. These are just a few of the many anti-patterns.

After reading about the seven deadly sins of software projects and the anti-patterns associated with them and how important they are. I also learned there are a lot of things I should avoid when working on a project. Some of these anti-patterns could be easy to get caught up in like analysis paralysis. Being too caught up in trying to get the perfect design is something I could see myself doing so keeping these patterns in mind is something I should do. I think Smith did a great job explaining these patterns in a way that is easy to understand but still gets the point across. I would recommend this post to any software developer looking to improve their skills. Even if only one of these patterns is a new concept, I am sure it would be worth the read.


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

Learning About Frameworks

This week I read about frameworks by reading “What’s a framework? All about software frameworks” by Lucas Stahl and Sean Higgins. Sean and Lucas did a great explaining what a framework is by making it easy to understand and giving many examples.

A framework is like a template that can be used to build your code on top of. Frameworks are premade code that take care of some aspects of the program. They are also reusable functions that make programming easier. Most programming languages have at least one framework that use them. The content of a framework can be very different, and it depends on the needs of the programmer for which one they should use. Many frameworks are open source that are maintained by the community of programmers but there are some from large companies like Microsoft or Meta. Frameworks might sound like code libraries but there is a difference. A quote by David Fateh helps explain the difference. Fateh said, “A framework,” he says, “is like a construction blueprint: A template that defines a basic structure for your build. A code library is more like a carpenter’s tool belt: It has tools designed to perform specific tasks”.  Lucas and Sean go on to explain the benefits of using a framework. Some of the benefits are being able to focus on one area of development, easier testing, development speed, reliability, documentation, and better security. There are many benefits to using frameworks but there are a few challenges as well. These challenges are structural limitations because frame works can’t do everything, having to learn the framework and the language it is based on, as well as having to pick from the many frameworks that are available today.

I learned a lot from this article, and I think frameworks could be a useful tool to use when programming. The diverse selection available seems like they could help in many situations. Being able to use a framework to cover a part of a program like the backend for example so another part like the front end can be focused on sounds interesting. Being able to focus on your area of expertise is a major benefit of frameworks. Although there are some limitations of frameworks the benefits seem to outweigh the cons. After reading this article I am now curious about all these frameworks and how I could use them to better my development skills. In the future I suspect that frameworks will be a common use for me.

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

Getting a Grasp on GRASP

The topic I wanted to cover this week is GRASP. GRASP stands for General Responsibility Assignment Software Patterns. I read a blog post by Kamil Grzybek called “GRASP – General Responsibility Assignment Software Patterns Explained”. He does mention his post is inspired and based on Craig Larman’s book “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development”.

Grzybek explains GRASP is a lesser-known set of rules that can be used in object-oriented programming and there are 9 patterns to follow within GRASP. The nine patterns are the following.

1. Information Expert
2. Creator
3. Controller
4. Low Coupling
5. High Cohesion
6. Indirection
7. Polymorphism
8. Pure Fabrication
9. Protected Variations

Grzybek goes through each pattern, explaining them, and gives some code from Larman’s book to help give the reader a better understanding of the uses of the principles.  The information expert is to assign the responsibility to the class that has the information needed to fulfill it. The creator pattern decides which class should create an object. A class needs to have at least one of the following responsibilities to be a creator, contain or compositely aggregates of the object, records the object, closely uses the object, or initializes data for the object. The controller pattern is to assign the responsibility of controlling a system operation to an object that represents the overall system or use case scenario. Low coupling is a pattern where responsibilities are assigned with the idea of reducing the impact of change by lowering coupling. The high cohesion pattern is used to keep objects focused and easy to use and understand by making sure all responsibilities of an element are related. Indirection is used to avoid coupling by making an intermediate object between two components. Polymorphism is how alternative types of classes are handled by using polymorphi operations. Pure fabrication is making a new class when it is hard to figure out where responsibility should be placed. The last pattern-protected variations is to create stable interfaces around points of variation or instability.

I chose this topic because I thought learning more patterns that could improve my code would be beneficial to me. SOLID and GRASP are the first two sets of rules I have learned about but there are plenty more that Grzybek mentions at the end of his post so perhaps one day I will learn about those too.  I did find GRASP to be a bit more confusing than SOLID to understand but I am glad I had a chance to read about it. The main conclusion I took away from this post is the management of responsibilities in software is crucial to creating a high-quality architecture and code that can easily be changed. Grzybek ends his post with the words “the only thing that is certain is change. So be prepared”, which really emphasizes his point that software must be flexible. I will have to keep this in mind when developing code in the future.


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

Getting Solid with SOLID

This week I read a blog post titled “SOLID Principles every Developer Should Know” by Chidume Nnamdi. Chidume taught me the important things I should know about SOLID and gave good examples to help make it more clear. SOLID stands for Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle.

The Single Responsibility Principle is a class should only have one job. This is because if a change is made it can affect more than just the one class that was meant to be altered. The Open-Closed Principle is software entities such as classes, modules, and functions should be open for extension, not modification. This makes sense especially with dealing with larger programs. If something new has to be added to a function it makes more sense to extend it than to edit the function. In larger programs, the function might need to be edited a lot which could fill it with if statements which can get messy. The Liskov Substitution Principle is that a sub-class must be substitutable for its super-class. This basically means if a subclass is called instead of a parent class the code still should still work properly. The Interface Segregation Principle is “Make fine-grained interfaces that are client specific”. This is done so that clients are not being given interfaces that contain parts they do not use. Finally, there is the Dependency Inversion Principle. This principle is that dependency should be on abstraction, not concretions. This basically means abstractions should not depend on details and that details should depend upon abstractions.

I selected this blog because it seemed like it was easy enough to understand and had code examples to demonstrate the principles in action. There was a lot of information to gather from this one blog post but it was well worth the read. Chidume does a good job explaining each principle and the pieces of code uses throughout the post helped clarify any confusion. I think following these principles will be a big help in the future when coding, especially larger programs that could easily become messy if I did not follow the SOLID rules. I think it will take some time and practice to be able to implement these rules in all my programs but it will be worth doing in the long run. I think that focusing on one rule at a time will be the easiest way to master these principles since it looks like it can be a lot at once if all of them are needed in a single program. 


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

Object-Oriented Programming

Object Oriented Programming is a topic that I wanted to brush up on because it has been a long time since I have programmed with it or learned about it.

 I read a blog by Omar Elgar called “The Story of Object-Oriented Programming” which was a great help with relearning the terms and use of object-oriented programming. Omar goes over the major aspects of object-oriented programming which are objects, abstraction, encapsulation, inheritance, and polymorphism. Omar explains objects in programming are meant to represent real-world objects like a car, phone, etc. When Omar gets to abstraction, he sums it up by saying it is focusing on common properties and behaviors of objects and getting rid of what is not important. For encapsulation, Omar explains it is breaking down a program into small mini-programs in the form of classes as well as hiding content that is not necessary to expose. Inheritance is when we take the common properties we created in an abstract class and apply them to the class that is more specific. The last topic Omar covered was polymorphism which is when an object takes the shape of many different forms. Omar even gives some code at the end of his post to show the readers a real example of object-oriented programming being used which is a nice touch and helps to see.

I chose this blog post to read because I wanted to get a clearer understanding of object-oriented programming and how it worked. I have coded using object-oriented programming in the past, but I do not think I had completely understood it and how useful it can be until now. Omar did a great job going over all the important pieces of object-oriented programming and explained them in an easy to understand way.  After reading his blog I feel like I got exactly what I was looking for out of his work. I will be able to apply what I learned from Omar’s blog to my programming and be able to effectively explain object-oriented programming to someone else if I needed to. I have a feeling that having a strong understanding of how object-oriented programming works is going to be important to have not only for my university classes but my future career as a software developer. I would highly recommend this blog post to someone who needs a straightforward and easy to understand overview of object-oriented programming.


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

First Post

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