Category Archives: CS-343

All About The Principle of Least Knowledge

The Principle of Least knowledge also called the law of Demeter, as explained in Eric Feminella’s blog “Principle of Least Knowledge”, is a design principle that provides guidelines for designing a system with minimal dependencies.  It is summarized in short as “Only talk to your immediate friends.”

A client should have knowledge of an object’s member, and not have access to properties and methods of other objects via the members.

The example shown in the blog has three classes: ClassA, ClassB, and ClassC. ClassA has an instance member of type ClassB and ClassB has an instance member of type ClassC. This shows that all the classes are connected one by one, and this can be extended further ClassC if need be. Now believe it or not this example violates The Principle of Least Knowledge because it creates multiple dependencies, thus reducing the maintainability because if ClassA needs some work so would all the instances of ClassA. This creates like a domino effect and keeping up with the client could pose some trouble.

Now, like the blog explains, in software development there might be some trade-offs. If the program runs better optimally with the above method, then maintenance might need to be pushed aside for just that. But it’s an important goal for the software developer to minimize dependencies, and by following guidelines provided by The Principle of Least Knowledge this becomes much easier to accomplish.

The Principle of Least knowledge is very important when it comes to coding because when it comes to programming a client itself, it becomes very easy to callback other dependencies to make things easier. But this creates more classes that, in a before blog would be referred to as “master classes” and more redundant code is created, and other dependencies are brought into the mix.

In code it seems like it’s better off if some classes don’t know the inner working of their other class, I’ve seen many programs break entirely because of one class. These classes are dependent of other classes. When one class falls all the other classes fall with it. So, It’s important to implement these dependencies so that they can be changed easily. And it’s also remembered to implement in such a way that they don’t require these chains of dependencies involved. All in all, it’s best to create a program that easy to modify and refactor so that the code is easy to work with in future development.

Link to Blog:

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Week 11-Software Architecture patterns

The Blog I read this week focusses on the the different Types of software architecture that we had discussed in previous classes as well as the different situations that these different patterns are useful and for what type of situation they would be ideal for. One of the important ones discussed and the most interesting ones that applies to my everyday life is the client server pattern.

In this pattern a central server offers one or more services are offered to one or more clients, allowing for all of the work to be done at the central server while all of the users can use the Data independently. This is very relevant for the world at large as many of the sites that we use on a day to day basis use this type of pattern such as twitter, where the Application provided the under interface for the user and the servers to interact. this type of pattern is used for many different applications we use today such as facebook and many other types of social media, where the user takes the information from the server and the selections made on the users side will then be sent to the server and update the information on that side of it. it is interesting how our small interaction impacts the overall system as a whole and how the entire process occurs for something so simple as updating your twitter bio.

Another pattern discussed in the blog is the layers pattern, which we discussed in both classes related to Cohesion as well as design patterns. it is described as the most widely used and promotes low coupling and high cohesion, much of what we discussed before hand in class is gone over such is how it is utilized for the most part smaller projects with different teams working on different parts of the project in parallel with other departments in order to keep the system active for users as well as allowing for updates to be spit out more often without shutting down the rest of the system. this was an important aspect of release principles as allowing for these releases to happen frequently in order to push updates to users as often as possible while other developments were also in progressed proved beneficial to the user but strained the developers, with the different teams it allows for less stress on devs to release patches or updates in select parts of the projects.

O, Williams. “Fundamental Software Architectural Patterns.” Medium, Medium, 14 June 2022,

From the blog cs@worcester – Marels Blog by mbeqo and used with permission of the author. All other rights reserved by the author.

Restful APIs!

Here, here, and here

I found that REST APIs can be used in a variety of different ways! Some of them are things that I wouldn’t think about, while others are more in line with what I expect.

For example, there’s more obvious situations where you can use REST APIs in Twitter’s case that allows people to read certain data. This allows people to do more extensive research with Twitter and create other interesting data points that such as in-depth analysis.

Then, there are other cases that might not be as obvious. REST APIs can also be used in cases like Spotify. I wouldn’t have thought about it in such a way, but pulling information such as song artist and shuffle systems can be developed with REST APIs as well. On first thought, I was curious to see how Spotify would use REST APIs, but it does make a lot of sense when you think about it.

To break it down in it’s basic form, Spotify uses a variety of different endpoints to return all kinds of different information. Some are more obvious, like artist, alum, and tracks, but there are also endpoints for markets and even playlist!

Honestly, I think it’s really clever to set it up that way, and it makes it very easy for third party developers to work on these types of systems. Since many websites use REST as a foundation, if you’re familiar with how REST APIs are set up in one form or another, you can probably quickly learn it in other situations as well. It is certainly much easier to get a hang of than if every single API was different from one another, but I think that goes without saying.

Overall, I think that if I wanted to use REST APIs for my own project, I’d have some difficulties. There’s not a lot of things that I have that can use REST API, so I’ll have to think of a whole new project to make. For basic start, I’d probably make something with a lot of different data or categories, since I think REST APIs are best at that!

From the blog CS@Worcester – Bored Coding by iisbor and used with permission of the author. All other rights reserved by the author.

What are Anti-patterns?

Anti-patterns are on the opposite side of the design pattern and are undesirable according to the blog “Anti-Patterns in Software Development That You Should Avoid”. Another term to describe Anti-patterns are called Design Smells.

The blog goes over the concept of the Golden Hammer anti pattern which occurs when using a familiar solution to attack an unfamiliar problem. Sometime it might work out, but most of the time it’s an inefficient way to solve problems.

The Golden Hammer anti-pattern is a concept that can shared in every aspect of life. Like for example, as mentioned in the blog some people tend to have their solution ready before understanding the problem like a doctor prescribing while the patient is still telling about the symptoms.

In software development, each design pattern is basically suited for its targeted problem. But it’s really easy to use the same framework, the same programming language, and the same design pattern for almost every problem. Like similar to the doctors example, some doctors might prescribe Ibuprofen to help a certain health but it might not completely relieve or heal that issue completely.

And so the Golden hammer could lead to; Poorly performing code, Overly complicated code, Redundant code. To avoid this anti-pattern it is best to find all potential solutions for one problem and benchmark them. List down all PROS and CONS for each solution then choose the better one.

Another anti-pattern is the God Class which for the most part controls many other classes, takes many responsibilities as well as lots of dependencies. An application could be well designed at the beginning so that there aren’t God classes but eventually dominant, very well specified classes will turn into God classes at some point.

The big ball of mud is a very common anti-pattern that happens when the solutions/application lacks a perceivable, flexible, suitable architecture as defined in the blog. A ball of mud will have, haphazardly and sloppy structure without coding comments, contains many God classes with more than 6000 lines of code, static variables/functions everywhere, methods being overloaded several times, and code duplications.

This anti-pattern is dangerous because it could happen while writing the application. Once we can’t refactor the code anymore, then we have to rewrite the entire thing. There are many reason why this anti-pattern could be brought up. It could be due to the frequent changes and requirements that the application might need, the deadline is near and the project is rushed, new developer are being brought in, or being too narrow minded about the design architecture that was initially brought in.

There are many more anti-patterns when it comes to the software development process, these are just the most common ones to date.

Link to blog:

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.


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.

Week 10 – Rest API

For this week, I decided to look at’s article on REST APIs. We are currently learning how to use and work within REST API environments, so I assumed that this article would just be review, but I have learned some new topics. The article essentially describes what REST API’s are and how they work. Before delving into REST APIs however, the article explains what API’s are. Essentially, they are a middle man between the user and an application regarding information. The article uses a customer at an unknown restaurant for an analogy. The server is the API, and the customer is the user. The user requests a specific item from the menu, or the API’s documentation, and the server brings that request to the kitchen, or the application, and then returns with the user’s order. Rest API’s are specific to web servers only, and use a set of 5 different HTTP functions to perform their operations, GET, PUT, PATCH, DELETE and POST. All of these essentially create, read, delete and update information. These features allow the user to alter and gather information from a web server from a simple application and without having to go into the actual code to do this, after the REST API is set up. The information is then returned to the user in either a json or XML format.

I picked this article due to its simple yet effective explanation of what REST APIs are. As stated before, we are currently working with REST APIs in class, so a lot of this article was review, but this article expanded my way of thinking how REST APIs work. I have used freecodecamp’s articles in the past, and they provide free and simple explanations for complex software topics that are very beginner friendly. The article also included real code examples of how to use some of the requests, along with a different method of using the requests than from what we learned in class by using the fetch API.

This article will help with my work in REST APIs thanks to its clever ideas in how its explained. I have never thought of the restaurant analogy, and I am sure it will help with learning more about REST APIs, and when I am explaining to my friends or family what it is I am doing in school, I can lead them to this article to help their understanding.

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

Intentions and Goals Part 2: Defining Needs

Setting goals allows me to take things one at a time and move over those self-imposed barriers effortlessly, but it is the learning and the love of the process that don’t even allow me to put those barriers there in the first place.
Now on to one of the actual goals, I have been wanting to use what I am learning as a computer science major to implement into my current workplace. I think that it has been a great opportunity to work there and they have provided a good environment for self-development similar to that of being in school. As a token of appreciation, it would mean a lot to me to be able to leave something useful behind. That something useful would be in the form of Software. In the past year or so I have had a level of engagement in my courses that I haven’t had in a while and that is most likely due to recognizing the practical application of what I’m being taught. This has led me to be vigilant at my workplace and observe problems that can be solved with software. After figuring out what the problems are and defining those issues
For a while, I have been stuck on what to do now after defining the problems from the software development class, and based on the topic of my last two blog posts it is clear to me that figuring out suitable architecture is important to a well-developed software system. To do this, I need to understand the important requirements of the users involved. Currently, I am under the impression that microservices architecture would be most suitable as many of its defining characteristics would fulfill the requirements of the business. Within this process of developing software, I am learning that there is a lot of picking and choosing systems that are specific to the needs of the business. Although it can still be overwhelming, I am relieved that there are already many preexisting systems and that picking and choosing make it a little easier instead of having to completely create something from scratch. On the aspect of picking already developed systems, the topic of API comes into mind I found this useful article outlining different APIs and their use cases and how some are still in use today and fit specific needs. The article points to the idea that even though some APIs might seemingly be outdated that they still have a use case that only requires such an API and nothing more.

I understand that I still have a lot to look out and plenty to learn but recognizing that there is a direct application to what I am learning provides some great motivation and hope that will allow me to continue to get over whatever barriers may be in the way whether self-imposed or not.

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

Bridge Structural Design Pattern

A bridge is a structural design pattern that lets you split a large class or a set of closely related classes into two separate hierarchical abstractions and implementation- which can be developed independently of each other. The blog from refactoring guru explains bridges a way of using more object composition rather than inheritance. Which means that we can extract one of the dimensions into a separate class hierarchy, so that the original classes will reference an object of the new hierarchy, instead of having all the behaviors with in one class.

Using this design principle, we can extract the code into its own class with two subclasses. And then we can have a reference field pointing to one of objects. That reference field will act as a bridge between one class to another and let’s say we needed to add another color for a shape, then we don’t have to go out of our way to create a PurpleCircle Class, we can just add the color, reference it with the shape and we’re done.

The blog has gone out of its way to explain real world applications for the Bridge pattern. One being used to help divide the monolithic code of an app that mages devices and their controls. The Device classes act as the implementation, whereas the Remotes act as the abstraction. The remote-control class declares a reference as explained in the description and that links it with a device object. All remotes work with the device via the general device interface.

Bridges are important because sometimes it can get hard to see what is contained with in a class especially if the class is gigantic. And making changes with one aspect of the class could require you to make changes in other aspects of the class. So, the bridge helps split the monolithic class into several class hierarchies. Which makes it different then most patterns like the Factory Design pattern or the Singleton pattern. The Bridge pattern would be mostly compared to the Strategy pattern where it plays a bigger role in how the code is being structured rather than adding some small commodities. It’s important to use the Bridge pattern to help extend the class in several orthogonal (independent) dimensions. It helps delegate the original class into related work to the objects belonging to those hierarchies instead of doing everything on its own.

The Bridge is very useful to help organizations within the code, I always tend to fill my classes with code with the use of implementations or inheritance so this would be a good way to get myself started on it.

Link to Blog: “”

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Get a (rewriting) hat!

One thing that stuck out to me is the concept of a refactoring hat! It is the idea that if you’re refactoring your code and you feel tempted to change the meaning of the code, don’t! So get that hat and remember to keep things intact when you start cleaning up!

For me, this was something that felt very important, since I often have a distinct issue where as I’m going back on old code, I realize that I could do something an entirely different way because of a new perspective. This often makes the code a bit better, but at the same time, I often change the functionality of it, so not only do I have to edit that one portion, but all the portions of my code! It isn’t that my code is too coupled together or that it’s rigid, but because my intent changed and this is hopefully where my refactoring hat comes in!

As noted in the website, a good way to recognize if you’re changing the intent of the code is to make sure that you are not rewriting Unit Test. If you’re refactoring and your Unit Test seems to still work without any changes, then that means you’re on the right track! But if you refactor and find that there are things you need to change in your Unit Test, you better put your hat on more securely because you’re past the point of refactoring!

This is essentially the concept of Rewriting vs Refactoring! To paraphrase MarnixKlooster, refactoring is cleaning things up, so you have more wiggle room when designing your code. In essence, making more design space! While Rewriting is creating code that meets new specifications and implements algorithms and data structures that are more efficient than the previous ones.

Though both of these seem similar, they are very different! From my understanding, Refactoring is like cleaning up your room, you know, sweeping it, mopping it, etc! But Rewriting is rearranging your room entirely! Move your bed, your table, add a new desk, all the little bits and bobs! Though they do seem similar, they are very different!

From the blog CS@Worcester – Bored Coding by iisbor 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.