Hello everyone and welcome to week 11 of the coding journey blog. In this week’s post I will be talking about the design pattern acronym GRASP. This acronym is short for general responsibility assignment software patterns. Design patterns are essential for software developers, and we will dive more deep into the benefits of using GRASP.

Originally, the GRASP design patterns were introduced after gang of four book, which has details on commonly used software design patterns. The GRASP design pattern is answering what each certain role each aspect plays in the software. There is the controller whose essential role is to take responsibility to encapsulate a system operation, which is something the user is trying to process such as purchasing an item. The system operation is achieved by calling one or more method calls between the software objects. Also the controller is responsible for providing a layer between the UI and the domain model. Then there is the creator which is responsible to help decide which class going to be responsible for creating a new instance of a class. There is a pattern known as high cohesion which is essentially responsible to keep objects understandable and more manageable. An example of this is breaking classes down and different subclasses for different roles making it easier in the bigger picture. Then there is the indirection principle which is responsible for low coupling and gives interaction responsibility to an intermediate object. Another part of GRASP is the information expert which gives guidelines about giving responsibilities to classes and one example would be methods.

Also in the GRASP design pattern there is the pattern of low coupling which decides how to assign responsibilities to lower dependency of classes and the change in classes impacting on another as well as the higher reuse potential. Polymorphism is a concept most of us know about because it is one of the principles of objected oriented programming. In brief to recap the concept, polymorphism provides guidelines on how to use the object oriented feature in your design. Then there is protected variation which protects elements from the variation on other elements by wrapping it with an interface and using polymorphism for many other implementations. The last part of the GRASP principles is pure fabrication which is made up to achieve low coupling and high cohesion with a class that does not represent a concept in the problem domain.

I personally think that the design concepts of GRASP have many essential components of programming and creating real world software. Many of these components are used in our everyday world and features we see without even recognizing. As I learn more in my coding journey and take in more concepts, I will most certainly take into account GRASP principles in my future projects to make it easier.

For more resources on this topic check out these links:

https://dzone.com/articles/solid-grasp-and-other-basic-principles-of-object-o https://medium.com/@ReganKoopmans/understanding-the-grasp-design-patterns-2cab23c7226e

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

Just because they’re not on your road doesn’t mean they’ve gotten lost.

-H. Jackson Brown Jr., Life’s Little Instruction Book

“A different Road” pattern shows us exactly how to follow our map and recall what we know. For some time, we might have walked through a road, and then realized that this route is not an acceptable option for us because of our drawn map. It has happened that we have found a way that is more in line with our current values. Based on this pattern, if we permanently leave the road, we will still have values and principles established along the way. This pattern shows different examples of people who decided to move on into something else and come back to bring new ideas to a company. It is okay to set people free if they have different ideas and let them come back along with the new interactions they have discovered. Unfortunately, traditional software companies are not so welcome. Such detours are also seen as questionable shortcomings in your profession you must explain later in the future. You would hope that your reason for why you left and why you came back will become important within your belief system. However, this shouldn’t be an issue for someone who wants to pursue their dream in a way or another.

What got my attention in this pattern is that we shouldn’t be afraid to do something else with our life, no matter the risks. The skills we have gotten during our journey will not leave, and at one point they will be useful wherever we go. As a software developer, with the experience, we will enrich everything we want for our future. Leaving behind the software development journey to become a professor or an instructor could be an option in our lives. We may like it or not, in the end, it’s all about trying to find where we and our knowledge best fit. I have always thought that leaving a company and coming back after a while wouldn’t be so good but based on this pattern it wouldn’t be so bad. However, there are several reasons why we would and wouldn’t want to go back to our previous employer. But let’s be positive and do what we feel it’s right. If what you were doing didn’t feel right in your career, you have the chance to return to a higher level and be where you always wanted to be in your previous company or move on to another one.

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

The next Apprenticeship pattern I would like to discuss is titled “Nurture Your Passion.” This pattern is targeted at software developers whose work environments drain them of their passion for creating software. It emphasizes that a passion for software craftsmanship is crucial for improving our skills, and that we should take steps to protect our passion if we find ourselves in such an environment. The pattern suggests several techniques we can use to strengthen our passion for software development. These include investing time into enjoyable projects, joining groups that focus on our interests, and changing our work environments.

As I mentioned in my post on “Breakable Toys,” I have struggled to stay passionate about programming since I started college. When software development became the focus of my education, I stopped working on personal projects because they took time away from more important (yet far less enjoyable) class assignments. This really damaged my ability to enjoy programming, and I think that following this pattern’s tips could help me regain some of my passion. I already expressed my desire to start working on personal projects on my own time again in my “Breakable Toys” post. While this pattern recommends this once again, it also provides several new suggestions that I think could be just as useful.

The pattern first recommends focusing on enjoyable topics while working as a way to make work less draining. This suggestion changes my perspective on how I should go about my work, as I have generally not prioritized my own interests during assignments. For example, I have recently been working on testing for my group’s project in CS-448, which has been exhausting for me since I dislike writing tests. I might try to contribute to more interesting aspects for the remainder of the project so that I can be more invested in it. The pattern also recommends joining groups and reading books that focus on topics of interest. Groups haven’t really worked for me in the past, and I’ve never been a fan of reading, but knowing that these options could help nurture my passion might make them worth trying. Finally, the pattern recommends having a list of positive ideas to talk about whenever work conversations become exhausting. Although I’m not great at conversation, I think this might be an action worth taking. Even if I never have a work environment that completely engages me, talking about my interests with others might be enough to keep my passions alive.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

For my final blog post on apprenticeship patterns, I wanted to discuss my favorite pattern. Software is so pervasive now that anyone can make a working product with little more than superficial knowledge of a language and a framework. This is great motivation to continue, but it may lead one to erroneously believe they are an expert. Finishing a product, even a successful one, doesn’t make you an expert programmer.

Digging deeper is going below surface knowledge of a technology and learning the nitty-gritty bit-y details. The caveat is to not become too specialized. The book warns to keep your perspective of the project as a whole, and only the learn as much detail necessary to help with a given task or problem.

I was originally taught to treat new classes as a black box, and I only found it frustrating once I graduated to more complicated tools. To truly understand how something is meant to work, you have to look inside. Another example: I’ve taken a few introductory classes that used metaphors to explain concepts and/or taught from the top down, adding detail over time. Biology class was boring and difficult because I had to memorize that a blue circle will separate the green, spiked lines so that two red hexagons can copy each of them. It wasn’t until high school, which provided an understanding of underlying chemical reactions, that biology became interesting and easy to remember.

So it is with software. I’ve been exceedingly frustrated with new tools when I tried to play without understanding. Sometimes, it works. Others, when things begin to get confusing, diving in becomes a necessity. Another caveat: you don’t know what you don’t know, and if you assume you’re doing it right, you may be wrong. Even if it works.

This is another pattern that requires balance. Learning details provides diminishing returns over time, but you should mostly understand why you need to do something a certain way, and how it is working. If you can explain this in simple words, you’re probably on the right track. This applies not only to software tools, but work processes as well.

You may not always agree with how a technology was designed. No one will tell you that the modern Internet is a perfect design, because it has been manipulated into working in a world it wasn’t designed for. Created in a world of text, it now works in a world of streaming video across billions of devices. This would never have been achieved without engineers and developers who understood the basic building blocks of the technology. Be like them.

From the blog CS@Worcester – Inquiries and Queries by James Young and used with permission of the author. All other rights reserved by the author.

With CS 343’s final project beginning, I have looked into some ways of displaying data. For this week, I will focus on Angular’s CDK. In Netanel Basal’s article “Creating Powerful Components with Angular CDK,” Basal describes the process of making an overlay in angular. He starts with creating a Popover service, Popover being a component from the CDK. This component is used for creating popup overlays, such as info that pops up while the mouse is hovering over something. Basal then creates the PopoverRef and its Injector. The PopoverRef is then injected into a ComponentPortal which is then attached the origin page. Portals dynamically render UI to the page. For the portal, the author creates a custom component to receive the contents to be displayed and how to render them. The article then covers three types of content the PopoverComponent can receive: text, template, and component. With that, the article’s example is completed. Now let us get a little more in-depth.

Let’s start with the Popover service. This service creates an
open() method that creates the overlay, its contents, and its injector. This
service is injected into the Popover component, where the open() method is
utilized in a show() method in the app component that is called on when a
button is clicked in the root component HTML. From what I understand, this
service handles the creation of all the parts needed to make the popover with an
open() method.

Next up is the PopoverRef, a class that receives a
overlayRef, content, and data, and creates a close() method to dispose of the
overlay. It seems that this class is used for the storage of the parent
overlay, the content, and the data, and the close() method that removes the popover.

Since Basal wanted to use a custom component, he needed to
create an Injector for it. The injector is created in the Popover service in a
createInjector() method, which converts the custom injector to a PortalInjector.

The author then attaches the soon-to-be-created Popover
component to the overlayRef in the popover service. This is done by overlayRef’s
attach() method, where a new ComponentPortal containing the PopoverComponent is
attached to the overlayRef.

The Popover component’s job is simple, just to inject the
popoverRef and render its contents. This article’s example provides multiple
rendering methods depending on content type. The three content types being template,
component, and text.

For all three types, a show() method is added to app
component that injects PopoverComponent and creates a Popover from popover service.
The only difference between the content type’s show() is what the content in
Popover is set to. This method is called on in the app component’s HTML where
it is attached to a button.

Reading through this article and examining its code has helped me towards learning how to create popup overlays. I feel I have a more solid grasp of how angular components interact with each other. I will undoubtedly use knowledge I gained from the article, “Creating Powerful Components with Angular CDK” by Netanel Basal, in my final project.

Article Referenced:
https://netbasal.com/creating-powerful-components-with-angular-cdk-2cef53d81cea

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

Once again, Martin Fowler has some comments on this week’s topic, but this post will mainly reference Dan Terhorst-North’s post, which better describes the reason and motivation for creating Behavior-Driven Development. BDD arose from TDD and it is better to think of it as an extension of TDD.

BDD tests follow the pattern “Given-When-Then” (notice the similarity to Arrange-Act-Assert). Mockito can define this pattern, but the BDDMockito aims to follow the same human-readable principles. The idea is simple: given a precondition, if some other condition occurs, then something else should have happened. Fowler’s example includes checking the state of an object, so clearly BDD is not simply testing the behavior of an object. However, it is a very important part.

Terhorst-North mentions that BDD picks up where TDD left off. I have seen some evidence that BDD has influenced TDD, such as describing tests as a sentence like “testFailsForDuplicateCustomers()”, which can be seen in many TDD test examples. Imitation is the highest form of flattery, so clearly this is a good approach. Or maybe, BDD is just more consistent in this naming because they put it in the specification.

Regardless, BDD developed out of Agile processes. It aimed to make writing tests part of the entire process and help future developers work well together in doing so. This is where many of Terhorst-North’s ideas stemmed from, and his main point, and the motivation behind the name BDD, is that “‘Behaviour’ is a more useful word than ‘Test’”. If you describe each test as a behavior, you know how to define the test, and you know when the specification has changed enough to warrant deletion of a test.

“What to call your test is easy – it’s a sentence describing the next behaviour in which you are interested. How much to test becomes moot – you can only describe so much behaviour in a single sentence. When a test fails. . . either you introduced a bug, the behaviour moved, or the test is no longer relevant.”

Daniel Terhorst-North, “Introducing BDD”

Real mastery of a subject is when it becomes simple. BDD is the next step to understanding testing on an intuitive, subconscious level. It wasn’t immediately obvious that tests don’t need to be difficult to write, but Terhorst-North managed to figure out a way to make it so. It is another part of the iterative process that is technology. Next time I encounter a difficult concept, I think asking three questions, in order, might help: Am I misunderstanding the concept? Do I just need more practice? Or is this method flawed?

Someone saw a flaw in TDD and developed BDD to improve it. This came only through thorough understanding, practicing, and identifying problems. This is applicable to any career, to provide real value.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.

I must say, this project has gotten much more complicated than I was expecting, even last week. Not difficult necessarily, but requiring much more knowledge of the framework that I expected. But after a steep hill over the course of the week, the good news is the features of Angular are much more powerful and exciting than I had thought. While the project specification requires communication with a REST API, which will be used for the database, I also require remote file storage. Since I will be using Google Firebase for both of these services, and file storage has a much simpler API which I’d prefer to use with mobile, I opted to not use the REST API for file storage.

Understanding the Firebase Storage API was the first step, but after reading through much of Google’s documentation for the web API, I still had difficulty translating everything to Angular and TypeScript. But luckily, Google is kind of a big deal these days, so David East from Angular posted a short tutorial that helped me bridge the gap.

The most mindblowing portion of completing this task was the concept of an async pipe, which I will explain shortly. You can’t get through a CS degree without learning and performing asynchronous tasks, but this syntax was completely alien to me. Take this HTML from David East’s post:

<label for="file">File:</label>
<input type="file" (change)="upload($event)" accept=".png,.jpg" />

This demonstrates Angular’s ability of event binding. The (change) syntax is binding a change in input to the upload() method in the Component, while also passing the event DOM, from which you can get the File using TypeScript. My needs were a bit different, but this same syntax can be used to simply store the file when the input is changed. Then, a separate upload button’s (click) event can trigger an upload within in the Component:

<button class="btn" (click)="submit()">Upload</button>

From there, my Component uses Typescript to communicate with the AngularFireStorage service, and even update a progress bar. This is where the async pipe comes in:

<progress max="100" [value]="(uploadProgress | async)"></progress>

More binding! This time, we’re using square brackets to bind the value property of the HTML progress tag to an Observable<number> object, which we can get within the Component from the AngularFireStorage service. This Observable will update the progress bar as the file uploads if we pipe it through an async task, as shown above. This subscribes to the Observable (or Promise) and automatically unsubscribes when the Component is destroyed.

I highly recommend reading over Angular’s template syntax documentation to get better acquainted with these concepts.

After completing this portion of the project, I’ve determined I’ve been thinking too much in terms of JavaScript, because I’ve found some of TypeScript’s rules to be a hindrance. Some of the examples noted above have shown me that if I get back to an object-oriented, strongly-typed mindset, I will be able to work quicker on future tasks. Essentially, this is just a matter of getting practice with a new language and framework.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.