Week 9 – GRASP

This week, I decided to look at an article based on the GRASP principles, and found this insightful article from Kamil Grzybek, an experienced designer in the .NET Framework. The GRASP concepts essentially explain how to assign certain responsibilities to different classes within a project. Each principle is derived from a problem, and the principle solves the problem. The first principle, Information Expert, decides which class will take the responsibility for a certain operation. In his example, his Customer class takes the responsibility of compiling an order since it has all the necessary information to do this. The next principle is Creator, which asks the question who creates an object? The answer according to the principle to assign a class to create this object, only if said class is closely related to the object. The next principle Controller decides who is the first object beyond the UI to control a systems operation and delegate information. The fourth and fifth principles are Low Coupling and High Cohesion, which solve the issue of keeping classes independent and to keep them focused on minimal tasks. The sixth principle is Indirection, which solves the issue of avoiding direct coupling between objects. The seventh principle is Polymorphism, which helps control flexibility within the code. The eighth principle, Pure Fabrication, solves the issues of what do to when there is an intermittent task that needs to be completed and avoiding more direct coupling between classes. The final principle, Protected Variants, is argued to be the most important principle. It helps to keep code available to change.

After reading this article, it seems to be a more expanded version of principles and concepts we have learned earlier in the class. Most of the principles within the GRASP lineup are connected to either another set of principles like SOLID, or directly correlate to a specific concept like loose coupling. The main reason I selected this article was the nice use of physical code examples to show off the principles. Throughout the whole article, Kamil used a Customer project that tracked orders. Each concept was show in a different section of the project, which makes it easier to visualize when thinking about how to apply it to code that I create. This article seems more to be for more experienced software designers, which I enjoyed. Learning new concepts with descriptions that are easy to understand can be helpful, but having a more challenging description given to me challenges me to understand the concepts deeper.

To use these principles in the future I must remember a two different ideas.
1.) All aspects of the code need to be individual and loosely related to avoid breaking the code when adding change
2.) It is easier to assign certain tasks to a separate class than to jam pack a single class with all of the functions


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.

Processing Architecture

When absorbing information, I find that it can often be overwhelming, sometimes leading to a point of disconnect. I see this occurring when you start asking questions like “Why am I learning this?” and “In what world would I ever need to use this?”. In the case of software architecture, I had a similar moment where I wondered how one would approach designing architecture.

 I found an article that suggest a solution to all my prior questions and in my previous blog post regarding the designing of software architecture, in which I questioned how one would create a design that suites a specific purpose. This article from 2006 suggest a general model for software architecture design that was derived from 5 other preexisting design approaches that were used within the industry. The article identifies that because software architecture design methods shares a basic problem that all these methods have much in common and can be derived, the basic problem being; “maintaining intellectual control over the design of software systems that: require involvement of and negotiation among multiple stakeholders; are often developed by large, distributed teams over extended periods of time; must address multiple possibly conflicting goals and concerns; and must be maintained for a long period of time.” Through this article I was introduced to 5 new design methods: Attribute-Driven Design, Siemens’ 4 views, RUP’s 4+1 views, Business architecture process and organization, and Architectural separation of concerns. This article also provide insight in the scale at which software architecture design is applicable. Whether large or small scale what remains is that there is a basic problem to be solved, and that it can be solved with an architecture design.

Below, I have included a link to the article where you can find the concluded derivations of the models. What stood out to me was the concept of workflow and backlogs. I was vaguely familiar with the idea of a back log from a previous CS course, Software Project Management. So, it is good to see that it can also be applied to architecture as well. On the idea of a workflow, I find that they offer notable insight into what is to be expected of someone in the industry.

It is important to follow through with a thought or question and to do that one must put in the work and find what you’re looking for yourself. When you don’t take action, you remain in that state of disconnect. This blog gives me an outlet to explore and I feel as though I am starting to reap the benefits of such a medium. It has allowed me to develop my own enthusiasm along with maintaining a vigilance for practicality.



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.

Week 8 – Law of Demeter

This article from InfoWars main goal is to explain the Law of Demeter, which is something that I have never heard about before this class. The basic premise of the Law Of Demeter is to ensure that classes and objects should never know the internal design and content of other classes. This promotes loose coupling and allowing code to be easily modified and changed in the future. First discussed in 1987 at Northeastern University, the law was developed to help software designers create code that can be understood and modified easily. This seems to be the main goal for most design laws. With more coupling, there is more confusion. The Law of Demeter will ensure that there is minimal complexity within code from restricting classes to have excess knowledge of the inner workings of other classes.

The main reason I selected this article for this weeks blog post was because it again showed some visual examples of code being used in the Law of Demeter, instead of just plain text. As I stated in another blog post, I enjoy seeing pieces of code that show the principle being used, and showing its violations. This article was also another free resource for many beginner coders to utilize to enhance and optimize their code. This is a concept I did not know about before taking this class. Reading the article, I connected the main points of the Law of Demeter to concepts we have learned in class, such as loose coupling. I’ve never realized that those small concepts we learned in class had much bigger implications in the world of software design, such as having a whole law dedicated to it.

In the future, knowing the Law of Demeter exists will help me make sure my code utilizes loose coupling, so that my code can be easily understood and ready by my co-workers on the project. Having code that is easy to read and understand is important when working in a team environment, as you can write something that you personally understand easily, but if a co-workers takes over your work, they are left in the dark as to what they are reading. This also promotes communication in the work environment, such as having standards for writing code so that everyone is on the same page when it comes to creating code, and allows for a more fluid and effective work environment.

Link: https://www.infoworld.com/article/3136224/demystifying-the-law-of-demeter-principle.html#:~:text=The%20Law%20of%20Demeter%20principle%20states%20that%20a%20module%20should,of%20other%20objects%20or%20components.

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.

Software Solutions

As software designers and developers, we can often run into errors and issues during our development process. Design patterns however, provide a general reusable solution for the common problems that occur in software design. These patterns are known to typically show relationships between classes or objects. The overall idea is to speed up the development process by providing well tested, proven development/design paradigms. We can even use patterns in our own designs as it will only make our design more flexible, more resilient to change, and even easier to maintain. There are multiple different types of patterns that are extremely well known to designers and developers across the globe. These patterns are categorized into three different types, Creational, Structural, and Behavioral.

The Creational design patterns are all about object creation or class instantiation. The benefit of creational design patterns is that they enable a design to become more flexible and applying a creational pattern removes hard coded behavior or can move it into a higher level interface. Class creation uses inheritance in the instantiation process and defers creation to subclasses. Object creation uses delegation in the instantiation process and defers some of the creation to other objects. Some of the most common creational design patterns include the Factory Method, Abstract Factory, Builder, Prototype, and Singleton. Structural design patterns are a little different from the creational patterns, but they allow us to create large, flexible, and efficient structures. This pattern eases the design process by identifying a simple way to realize relationships. Some common types of Structural patterns may include, Adapter, Bridge, Composite, Flyweight, Proxy, and many more. More than often this design pattern will result in some form of abstraction and inheritance between two objects. Lastly, Behavioral design patterns is a pattern that strictly defines communication between objects, as well as classes. This pattern is solely for the purpose of increasing the flexibility of communication. There are many behavioral design patterns but some may include, Command, Iterator, Meditator, Memento, Observer, Strategy, and many more.

Design patterns are extremely useful and important to learn about as they can help accelerate the development process and help save time without needing to reinvent a new pattern every time a problem arises. They can especially be useful when you’re at the beginning of your journey as design patterns are a good starting point. Even if you won’t use them right away in your first projects, getting to know them will help you understand the existing solutions you’re using. The simplest and most complex solutions are all made up of different patterns.


From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

REST API Design!

This week in CS-343 I’ve been getting familiar with REST APIs. This is not the only time I’ve had to use a REST API; I had to use them in my project last year for operating systems. REST APIS as explained in the stack overflow blog “Best Practices for REST API design” are one of the most common kinds of web services available today. It allows various clients including browser apps to communicate with a server via REST API. It’s important to design the REST API so that the client can properly and effectively communicate with the server.

First, what is a REST API? A REST API is an application programming interface that conforms to specified architectural constraints, like stateless communication and cacheable data. It is not a protocol or standard. REST APIs should accept JSON for request payload and response to JSON. JSON is the standard for transferring data. On another note, while transferring dates, I didn’t use JSON in my project, instead, I ended up using Curl. A curl is a command-line tool for transferring data, and it supports about 22 protocols, including HTTP.  It’s very good when testing REST services, but the blog and most sources I would say would recommend JSON for requests/responses. I was familiar with JSON files, it’s common, but now I understand why using JSON is the more optimal.

Endpoint paths are used to grab/modify whatever information you might want from the REST service. The most common ones are GET, POST, PUT, and DELETE. GET retrieves resources, POST submits new data to the server, PUT updates existing data, and DELETE removes date.  Creating routes are how we can use these endpoints. For example, let’s say that we have a route called article, POST /articles/ is for adding a new article, PUT /articles/:id is for updating the article with given id, DELETE /articles/:id is for deleting an existing article with given ID.

To avoid any confusion when an error occurs, we have HTTP response codes so that we can figure out the root of a problem, the common HTTP status codes include 400 Bad Request This means that client-side input fails validation. 401 Unauthorized – This means the user isn’t not authorized to access a resource. It usually returns when the user isn’t authenticated. 403 Forbidden – This means the user is authenticated, but it’s not allowed to access a resource.404 Not Found – This indicates that a resource is not found. 500 Internal server error – This is a generic server error. It probably shouldn’t be thrown explicitly. 502 Bad Gateway – This indicates an invalid response from an upstream server. 503 Service Unavailable – This indicates that something unexpected happened on server side (It can be anything like server overload, some parts of the system failed, etc.).

This doesn’t cover all the details of REST API but for the most part, this will get you a decent understanding of how it all works.

Link To “Best Practices for REST API design” : https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

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

Week 8-What is an API

For this week I wanted to dive a little deeper on the APIs that we has begin to work with in the previous lab, it interested me how these systems work and wanted to see how different examples out in the world worked and how it related to how we interact with the systems themselves.

In the blog the author goes deep into how the API System are very apparent throughout the world and how they work, the best example I saw was a calendar system on google. The user would send a request to googles remote server and then the server would respond with the site to allow the user too book on the calendar, one the user set the date the request would be sent back to the server and a response would be sent back to the user. As someone who uses other systems like booksy to book haircuts with my barber its interesting how the API allows me to book it on my end while it does all of the work for me interacting with the server and changing my barbers calendar to integrate my appointment.

In the case of the work we did in the lab it is interesting to see how the API used for the pantry relates to some of the APIs discussed in the blog, when we worked we saw the all of the different actions in that API which led to either the collection as a whole or individual students when we looked to post new details or retrieve details. It is interesting to see how similarly the example we worked on works with the blogs APIs, where ours is more adding students taking food or putting food in the pantry, while also logging what is taken or what is put in, there examples is access to a Weather API to check weather in certain areas or the facebook API to give the user their profiles information.

One part that the Blog focuses on heavily is Object Oriented design, where there is a large list of objects and each object has an API which allows the objects to interact with one another, much of what is said leads back to our earlier lab seasons focusing on the different design models and which ones work better, the API aspect of it is now made relevant on how these objects interact with each-other on the users side.

Gazarov, Petr. “What Is an API? in English, Please.” Medium, We’ve Moved to FreeCodeCamp.org/News, 10 Oct. 2016, https://medium.com/free-code-camp/what-is-an-api-in-english-please-b880a3214a82.

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

Gluing functions together in F#

Often when writing a function, we want it to be generic enough that it can operate in different ways for different inputs. Different languages will provide different ways to do this. Object-oriented solutions might include interfaces and polymorphism. Procedural languages might suggest template specialization or function pointers.

I’m going to talk about how functional programming languages use first-class functions to solve this problem in a satisfying way without any pointer syntax. Here’s some F#:

let rec filter fn lst =
    match lst with
        | [] -> []
        | head::tail -> 
            if fn head then [head] @ filter fn tail
            else filter fn tail

We’re defining a function named filter here which takes a boolean function and a list. The filter function will pass each element of the list to the function and eventually return a list of the elements for which the boolean function returns true. Let’s look at the result of passing some simple arguments.

let numbers = [0; 1; 2; 3; 4; 5; 6; 7; 8; 9]

let isEven i = 
    i % 2 = 0

filter isEven numbers
[0; 2; 4; 6; 8]

Usually when we see functions in the argument lists of other functions, we expect them to be glorified values. But in this case, isEven is not returning some value that gets glued to a parameter of filter. When a language has first-class functions, it’s perfectly fine to have functions themselves be the inputs or outputs of other functions. Here, isEven is itself an argument, and it operates on the head of each sub-list as we recursively cut our list down to one with zero elements.

In functional programming languages, it’s harder to write programs that aren’t reusable. If we want our filter to cut out any numbers that aren’t part of the Fibonacci sequence, we just write another boolean function and pass it instead.

let rec isFibHelper n x y = 
    if n = x then true 
    else if (y < 0) || (x > n) then false
    else isFibHelper n y (x+y)

let isFib n =
    if n < 0 then false
    else isFibHelper n 0 1

filter isFib numbers
[0; 1; 2; 3; 5; 8]

filter isFib (filter isEven numbers)
[0; 2; 8]

Because filter operates on a list, to filter a list of some other type we can just steal some documentation code for another boolean function.

let strings = ["abc"; "DEF"; "gHi"; "jkl"]

open System

let allLower s =
    s |> String.forall Char.IsLower

filter allLower strings
["abc"; "jkl"]

Functional programming is all about composition and modularity. You start with tiny Lego pieces and need to attach them until you have a gigantic ninja castle. In its most dogmatic form, that means sacrificing creature comforts like loops and mutable data that we use to quickly slap together solutions that can never be reused.

If you learned to write procedures or call constructors, I recommend giving one of these languages a try. It even makes recursion fun, so what’s not to like?

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

The Great Observer Pattern

The Observer Pattern is a design pattern that allows objects to react to changes in another object’s data while maintaining loose coupling. Loose coupling, for a reminder, is a system in which components are weakly associated with each other.  The pattern as described in Ilyana’s blog “The Observer Pattern” is a pattern that can decide at runtime whether to receive data from the subject-object.

                The blog goes on to say that it is not uncommon for object-oriented programming to run into a situation where you have an object in your code that collects/outputs data and other objects that care about that data. Some objects might care about certain data that the programmer might throw at them, such as measurements or certain temperatures. These objects are the observers. The observers do not care what class gives them the data, only that they receive the data as it changes. Signs that your code might need to be refactored to utilize the Observer Pattern include an object that is dependent on another object or a change to one object that requires a change to many others.

                The Observer Pattern defines a one-to-many relationship between a set of objects. The Observer Pattern defined one subject’s relationship with its many observers. The Observer Pattern will separate the subject from its observers while still allowing the observer to react to changes in the subject’s data. The observers provide a method that allows the subject to inform them of the updates. This pattern allows for loose coupling once again between subjects and observers. As explained in the blog they can interact but don’t know that each other exists, they basically know nothing about each other.

                The pattern is usually implemented using an abstract subject class and an abstract observer class, which a concrete subject and some concrete observers inherit. This pattern would be very useful if I ever needed the objects to receive an update when one object changes. It’s very intriguing to hear the terminology they use within the blog. The subject acts as a publisher which sends out the information and the observer, which acts like a subscriber, basically takes in the information it wants to receive. Obviously with I can see the subject sending information that the observer might not want to receive or have on them. Non the less it’s a very interesting pattern that shows the process of what a loose coupling might look like in a coding environment.

Link to Blog “The Observer Pattern” by Ilyana: https://ilyana.dev/blog/2020-08-07-observer-pattern/

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

Refactoring code!

Before our more recent classes where we learned about the Singleton and Simple Factory pattern, I knew about the concepts of refactoring, but in a different light. Rather than using these patterns and methods to make my code more efficient through a pattern of sorts, I consider refactoring as something more akin to making my code more readable and more efficient by breaking down useless portions of code. This isn’t exactly wrong, but it’s not completely right either!

Mainly, because though these approaches were important, they could be done even better! I main thing that I was missing in my own refactoring was obviously the design smells that we have recently went over now. Intuitively, I understood a few of the smells already, but now that I have a better grasp of many of them, it is clear that my older refactoring efforts were missing plenty of things!

For example, I used to clean up code and make it easier to understand by breaking them into chunks, which is good, but at the same time, I would also condense other areas since they seemed to ‘fit.’ It is clear now that I should NOT do that, but you live and you learn!

I think that the biggest resource that I found so far, is this website! Though it is basic and even a bit barebones, it gives a pretty good introduction to refactoring. It makes sure to consider things such as cleaning up dirty code from inexperience, a refactoring process, the design/code smells, and techniques to refactor as well as show off a few different design patterns!

One thing that might be helpful is that the website contains many different images to help break concepts down and even code examples! I know for me, it helps tremendously when I can look at some code and see exactly what is happening! Though I do understand the concepts a lot of the time, I find that I learn things a lot more quickly if I can look at the source and break things down myself! The website even has plenty of different coding languages too, so if say, Java isn’t your best, you can look at the different patterns in C#, Python, etc!

Overall though, I think that learning about a more refined structure to refactor code and implement these various design patterns will help me tremendously! I know that there have been times where I have gone to look at my old code and I’m sitting there lost, confused, and asking “Who did that!” Hopefully, with this in mind, I’ll have a better understanding of how to proceed with my older code past and future!

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

Link: http://www.kamilgrzybek.com/design/grasp-explained/

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