Author Archives:

Adapter Design Pattern


    This week On my Blog, I want to talk about a design pattern. The One I want to focus on is Adapter Design Pattern. Adapter design pattern Convert an interface of a class into another interface clients expect. The adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. The adapter design pattern is a structural design pattern that allows two unrelated/uncommon interfaces to work together. In other words, the adapter pattern makes two incompatible interfaces compatible without changing their existing code. Now Let’s take a look at an example that shows how the design works. From the blog, I used it provided a diagram that I think is helpful to understand the design pattern. In this diagram, Socket wrenches provide an example of the Adapter. A socket attaches to a ratchet, provided that the size of the drive is the same. Here a Ratchet is ½ in size and the socket is ¼ without using an adapter you cannot connect the ratchet and socket together. 

    Now let us take a look at the benefits and liabilities of using the adapter design pattern. The first benefit is that you can let any two unrelated classes run together. Second, Improved the reuse of classes, it Increased the transparency of classes and it has Good flexibility. Now for the Liabilities, the Adapter design pattern takes Too much use of adapters will make the system very messy and difficult to master as a whole. For example, if an interface A and B are implemented and interface B is adapted internally. If too many tasks are running in A system, it will be A disaster. So, if it’s not necessary, you can simply refactor the system without using an adapter. Also, in object-oriented programming especially in JAVA it inherits at most one class, it can only adapt to one adapter class at most, and the target class must be an abstract class.

    A real-life example that I found was about the card reader ACTS as an adapter between the memory card and the laptop. You insert the memory card into the card reader and insert the card reader into the portable computer. The memory card can be read from the portable computer.

    This source is helpful to understand the design pattern even more. I would suggest you take a look at the website because it goes into further detail about the Adapter design pattern, including various examples using diagrams and JAVA codes. 



From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Facade Design Pattern

This week on my CS Journey, I want to talk about the design patterns, Especially the Facade design pattern. In class, we also learned about other designs which are helpful. However, I wanted to focus on the Facade design pattern. To start of Facade is a structural design pattern that adds an interface to an existing system to hide its complexities. In other words, it provides a simple interface that can be used to manipulate more complex logic behind the scenes, that are hidden from the main user. According to the Gang of Four, the Facade pattern intends to “Provide a unified interface to a set of interfaces in a subsystem” From the blog I used it provided a diagram that I think is helpful to understand the design pattern. In the diagram, we can see that Facade is acting as an interface for the complex Subsystems that are hidden from the main clients. 

Now let’s take a look at a real-life example. A good example that I found was When a computer starts up, it involves the work of CPU, memory, hard drive, and other subsystems. To make it easy to use for users we can add a Facade that wraps the complexity of the task and provide one simple interface instead. This applies to the Facade design pattern because it hides the complexities of the system and provides an easy interface to the users. 


One of the liabilities is that a Facade might provide limited functionality in comparison to working with the subsystem directly. Does not prevent applications from using subsystems classes if they need to. Also, it can increase the number of wrapper classes. Another liability is that Facade can perform way too many tasks. One of the benefits is that it reduces compilation dependencies is vital in large software systems. Overall, The Facade design pattern is helpful when dealing with the complex system because It enables us to use the complex system much more easily.


There are a lot of examples, diagrams, and Java Codes, readings and a link to a GitHub resource that are provided in the blog I used. I would suggest you to take a look at the website because it goes into further detail about the facade design pattern, including various examples using diagrams and also this reference contains a lot of information that is broken down into easy steps which are user friendly.


Source :

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

S.O.L.I.D Principles

 This week on my CS Journey, I want to talk about the SOLID design principles. I am sure that you have heard the term many times, however, let us look at the principles in detail. The reason I picked this topic is as a Computer science major student we write many programs and having a strong principle will enable us to write effective object-oriented code. 

To start of SOLID is an acronym where each letter represents a software design principle. 

S – for Single Responsibility Principle

O – for Open/Closed Principle

L – for Liskov Substitution Principle

I – for Interface Segregation Principle

D – for Dependency Inversion Principle


Each principle overlaps here and there. The Single Responsibility Principle states that in a well-designed application, each class should have only one single responsibility. essentially meaning a class should only have one job. I think this is a very good concept to use because when you are working with complex programs and the class has more than one responsibility it will become a nightmare. The open-closed principle states that classes should be open for extension but closed for modification. For example, I learned that if you want to add a new feature to your program you should do it by extending it rather than modifying it which minimizes the risk of failures. Next, the Liskov Substitution Principle which explains that an object of a superclass can be replaced with objects of its subclasses without causing problems to the application. This means that a child class should never change the characteristics of its parent class.


The  Interface Segregation Principle is the fourth SOLID design principle that states no clients should not be forced to depend on methods they don’t use.  In other words, interfaces shouldn’t include too many functionalities since the interfaces are difficult to maintain and change over time, so it is best to avoid. Lastly, the Dependency Inversion Principle states that the High-level modules or classes should not depend on low-level modules/classes and both should depend upon abstractions because a change in one class can break another class which is very risky.


Overall, the blog I read talked about each principle in detail using various examples such as UML diagrams, Java programs, and other diagrams that helped me to understand each concept. I learned a lot from the blog, and I think that these concepts are all key to writing a good solid code. In the future, I will be using the principles to write effective object-oriented code. 



Here is the blog I Used:

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

NicholasDudo Computer Science Blog


    My name is Nicholas Dudo, I am currently enrolled at Worcester state as a senior in the Computer science program. I am currently on track to graduate in the spring of 2021 with a concentration of big data analytics. In my free time, I enjoy wrenching on cars and my own truck which is my non-computer related hobby. As well I like to participate in as many things possible when it comes to sports. For example playing pick up games in soccer, basketball, and even football on occasions. Other than that you can catch me with my friends giving out a helping hand on whatever is needed. I am a fast learner and very hands-on. When it comes to my computer-related hobbies I like to mess around with creating programs or tweaking them in any way possible. As well I love to learn new techniques even when it involves cloud computing or even searching a database for specific material. I am very aware that computer science is not something for the people fain at heart. It takes practice and an extreme amount of devotion to succeed in. with that being said I really do enjoy learning the tools of the trade and figuring out what needs to happen to succeed in the course. At one point in my life, I want to look back and share the story of where I have come from and say that it is possible if you put your mind to it. I am excited to see where this carrier takes me!

From the blog Nicholas Dudo by and used with permission of the author. All other rights reserved by the author.

CS 343 First Post

Welcome to Haoru’s Blog

Hello Everyone! This is my first post for 343.

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

CS 343 First Post

 Hello Everyone! This is my first post for 343. I’m excited and looking forward to this semester. Lets stay Focused!

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

At the end of last week, we finally conclude our third sprint in our development process of the LibreFoodPantry, aiming at a deloyable environments so that they all are isolated in their own space. This is also our last sprint so we tried our best to wrap it up as much as possible, so that the team after us can easily pick up from where we left off. We were able to work together more this time, comparing to us having to separately work on our own stuff in the previous sprint. We finally got a working, operational and deployable user interface as well as a fully implemented, buildable and deployable backend system with REST API and mySQL database. We were also able to adapt with the online communication and worked more effectively with each other.

List of what we accomplished during the last sprint:

       – Successfully integrate Docker into frontend UI and the REST API, allows them to communicate with the existing mySQL container with configurable parameter in config.json file (REST API DockerApproveGuestWebUI Docker)

           Having an operational admin page user interface or ApproveGuestWebUI, although without actually data fed from backend systems, but mocked with data points (ApproveGuestWebUI Epic)

         – Having a mocked or stubbed backend for the frontend to test connections establishing mechanics (Registration Stub)

It seems that we did not do a lot for this sprint, but it was actually much more challenging for us because of more advanced technologies that we have to research on and a lot of new barriers that we have, such as us having more things to do for our career and other classes, voice and video communications became harder as the internet becomes unstable, for me at least, etc. Despite all of that, I think we did a very good job wrapping up all the work we have done from the sprint and even make it deployable, so the next group can just skip the hard part of Docker and focus more on the part of developing operational products for the food pantry. We think that is much more important than to waste time on getting them to be able to run on an actual server, so I heavily prioritized to get it done, both on Docker Desktop and Docker Toolbox. I would say that out of all the sprints, this one is pretty boring since I personally had to read a lot comparing to the two last one that all I do is setting up systems, coding, and a whole lot of checking on people if they can run the same system and if they need some help.

For future improvement, if we have a chance to work more on the project, I think it is better to centralize our work source into either backend or frontend, then move on to another. I believe it is better that way so all the team member can know what other members are doing and learn both the backend and frontend stuff. Another improvement that our team can use is more official communication and well documenting our steps of implementing. It is the same problem that persists from the last run, but we did make sure to have more transparency in what we do this sprint, which I think is a major effort from us.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Learn How You Fail

The pattern that from Apprenticeship Pattern that I read for this week is “Learn How You Fail”. The chapter mainly talks about how to identify our own problem during the development process and seek to fix it in order to get better.
I really like what the author said within the context. Failure is inevitable and people who has never failed would either stay in their comfort zone and avoid going over the boundaries, or they have overlooked and ignore their mistake all along. This holds true to me since I have done multiple personal projects that requires me to constantly make mistake and discover what is needed to be done for even a single line of code to work. It is pretty obvious that errors will push ourselves to find out what works and what does not, give us a space to fully explore the capacity of the technology so that we will not make a same mistake later on. Moving on to the problem, he states that the learning skills may bring us success, but there are weakness and failures still remains. I agree with this and I think he did it brief but covered all the aspect of this chapter. The author then gives us the solution, which is as simple as to always seek the errors or failures and resolve what is worth fixing, and more importantly, we have to accept that there will be a lot of things that we are not good at. The solution itself is pretty much self-explanatory and I agree that there’s no better way to improve it without starting to identify the problems and spend time and effort to fix it.
Another way to solve this problem is to is to always arm ourselves with knowledge to make better decisions when carrying out working and identify our own boundaries and limitation to push it when we need to. These changes and improvement can also enable us to have a realistic limitation on our goal. That limitation is what we need to be mindful about as we cannot know everything, and that limitation will greatly help us in filtering out which one is distraction, which on we should spend more resources on to excel at what we are trying to accomplish. I like the example that he put out, which is making time for PhD courses, or simply give up what we know as it requires maintenance to be fortified and maybe to make room for what we need at the moment. I both experience a similar form of these two examples since I had to dedicated time and resources to be able to just learn a new language or a piece of technology.
Personally, I like the chapter because of its simplicity and how it encourages people to not afraid to push their boundaries, while at the same time, accept that we can never know everything, and we have to prioritize one over the other. Like I mentioned, I had experience what this pattern is saying in the past, and I believe that this can be extremely useful for a lot of people, especially the one who has quite some decent knowledge about an area to encourage them to learn something not quite similar to what they have been using.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Study the Classics

The second pattern for this week Apprenticeship Pattern is “Study the Classics”. I think this one is pretty straight forward, as it states on point that reading and learning what is in the past is as essential as doing so with documents and books in the current generation, as it would allow ourselves to expose to problems that we might rarely see at the moment.
The patterns start out with an extremely interesting problem that a lot of more experienced people in the field would likely to reference a concept from books and area that we might have now idea it exists, but they expect us to know it already, like any other self-respecting software developers. I have not experienced anything thing like this while working as an intern, but I can imagine that it does happens a lot to new developers in the field. The author explains the solution in a very simple way, which is to admit your ignorance, and ask about the concept, how it works, where do they reference it from and add it to our own reading list. For people like me who has not experienced a situation like that to get a title to read, when picking out books to read, the author recommended us to look at how out of dated it is comparing to the continuously evolving technologies that we have right now to make sure that we are reading the one needed for our on need in the current state of technology development. I think that does not really mean that we can ignore all of the books that are written decades ago as it might contains a lot of information that can even serve until today, still however, they should not be on our top priority list. It is best to have a mix between classics and modern to have a feel of what is the differences, what is improved, what is still remains, and that is the best way to avoid making the same mistakes and have a better referencing stand point when putting out our opinion to the team.
In my opinion, this pattern does not necessary to contain the most useful information to choose the best book out there to read. I think if the author put out some of the examples to make comparison, like a book about Python 2 and another one about Python 3, it should make a clear distinction in the reader’s mind that this pattern is important to keep in mind. With that being said, I think the patter itself is not too informative as much as the other one, but it does have some value to tell the readers that books will always have their value, whether it is old or new, but to prioritize reading the right one, would make one more successful than others

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Concrete Skills

The first pattern in the Apprenticeship Pattern that I read for this week is Concrete Skills. The pattern pretty much talks about skills that are required to be focus on when an apprentice software developer like us start our career. It also lays out a concept, which is to have knowledge about it, does not mean that we can successfully apply it to create a piece of software, and I think that this is crucial to remember.
The pattern starts off by posing a really interesting problem that I think a lot of people, even veteran, are facing I would say, which is having a team, or a company that is not willing to hire someone that will, for sure, not able to not make any contribution to the project, whether it is direct or indirect, and this I think would take away the potential for an individual to learn and maybe even progress himself/herself in the field if it happens to them constantly. As the author starts to explain the solution, which is to acquire and maintain concrete skills, which is really generalized, but when he starts to explain further, it makes a lot of sense to me. He explains that we just simply can bring the ability to learn quickly, or the ability to bring a specific tool or technology that allows the team to work better, and our credibility will be increase among the team, so it is best to be prepared a lot of necessary skills and tools before applying for a position in a team. I like the point where he points out that some hiring manager will have to trust us with what we have and bringing a creation of our own might ensure them that we will fit the job that benefit them. I found it also true that these concrete skills are only noticeable when our resumé is new and lack of experiences. It is certainly be easier as we proceed from job to job, as they are more likely to look at our personal experiences, reputation, and most importantly, our portfolio.
Personally, I think this pattern is really brief about the subject matter, it does not necessary be the most informative patterns, but it certainly motivates me and I am sure a lot other developers out there to learn and do more in their own time in order to make their resumé looks better, as well as gaining more experiences in using tools and languages at the same time. It also made me realize that the demand of tools and technologies are always going to change, so it is quite essential to always learn new things on the go, although our pool of knowledge is filled with a lot of stuff that can easily be used in a team at some point. I feel like this pattern is different as it is more about preparing for getting a job in the field, but it is quite important not to be passed by by new developers.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.