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

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

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.

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.

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.

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.

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 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.

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's Blog by Ryan Klenk and used with permission of the author. All other rights reserved by the author.