Monthly Archives: October 2020

Rest API Design

https://www.mulesoft.com/resources/api/what-is-rest-api-design

https://restfulapi.net/

The topic I’ll be writing about this week is Rest API design which is one of the topics listed to be covered in the class syllabus, though we haven’t covered it yet if at all. It’s also worth noting that the following information is taken from the websites linked above. Rest API design or simply Rest stands for REpresentational State Transfer and is an architectural style for distributed hypermedia systems. The purpose of Rest is to create web services that have reliability, fast performance, and the ability to grow by reusing components that are managed and updated without affecting the larger system. There are six guiding restraints that an API must follow to implement Rest. The first is “client-server” which states that the client and server should be completely separate in order to improve scalability and portability. The second is “stateless” which means that each call should contain all the data needed to complete itself. The third is “cacheable” which means that the storage of cacheable data should be encouraged. The fourth is “uniform interface” which means the interface should follow four constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state. The fifth is “layered system” which means ordering components in a layered system. The sixth and optional constraint is “code on demand” which means REST allows code or applets to be transmitted via API for use within the application.

            Rest API design is generally used to increase performance and make web services that implement is easier to use. For example, the first constraint “client-server” as I already mentioned earlier increases scalability and portability. The second constraint “stateless” reduces the amount of work a server or a client needs to do depending on which is calling. The same applies to the other constraints; they all improve on a web service in some way or another. Of the sources I’ve looked at, I could only find one major drawback which is that you can lose the ability to maintain state in REST, such as in between session. But even then, it’s not that big of a drawback since one of the constraints of REST is refraining to use states so it’s an intentional design choice. So overall, Rest API design is an architectural style that sets out to accomplish a specific goal and does it well with minimal drawbacks. And from what I’ve read, there is really no reason to not use it if states aren’t required and the goal of the designer is to save resources.

From the blog CS@Worcester – Rainiery's Blog by rainiery 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 : https://www.baeldung.com/java-facade-pattern

















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

Adapter Design Pattern

I’ve always found Derek Banas’ channel really useful. In late middle school, I started watching his tutorials for how to code. So it’s really interesting to go back and watch his videos, to say the least.

I feel like the adapter design pattern is something that shouldn’t really need to be used. Don’t get me wrong, it’s very useful. Like real adapters, however, the problem itself shouldn’t really exist. That’s especially true with code; it seems as though adapters become required when interfaces aren’t abstracted well enough. In his video, for example, he has an EnemyAttacker interface that represents some kind of enemy. However, the methods are very specific and presume certain characteristics about the attacker. We then need to use an adapter to get around that specificity. It seems to me that writing the interface more generally to begin with would be more ideal. But given that it’s a bad idea to modify old working code, an adapter is a great solution.

In principle, an adapter does exactly what you expect it to: it adapts code. It takes one “interface” and connects it to another “interface”. That’s the colloquial interface as opposed to a coding specific interface. We use adapters every day. The best example is a phone charger. It converts (or adapts) 120V AC power to a low DC voltage. It also adapts the physical plug into USB type-c. All of the functionality is hidden inside of the charger and from the perspective of a user, it’s literally plug and play.

An adapter in code acts the same. I honestly like the example he gave so if you want to see an example of actual code, check out his video. Conceptually, one description of an adapter is the following: We have two interfaces A and B that have many differences, but are conceptually similar. We can create an adapter so we can use any A as a B, or vice versa. It’s okay because of their similarity (or perhaps they need not even be similar!). Really, it’s an incredibly basic pattern so the specifics aren’t that important.

Fundamentally, an adapter is just code that allows other code to operate together. Again, I think the best way to conceptualize it is through the imagery of any real life adapters. However, it should ideally not be necessary in scenarios such as the one from the video. Abstraction, within reason of course, should be prioritized ahead of time.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Design Patterns: Useful Tools for Structure & Organization

When I was first learning about programming and writing code, I never stopped to consider issues like effective layout, efficiency, or structure in my programs. At these early stages, it was enough for me that the code worked and ran without crashing. Now, as I have been studying design patterns in one of my University classes, I have seen the value that design patterns, and taking consideration to layout and structure can bring to a program.

I think that following a structure or a framework of some kind can definitely bring some much-needed order to what would previously have been organized solely by necessity and convenience. Without a design pattern, my code would often be organized based purely on instinct and whatever seemed easiest in relation to the particular functionality I was currently in the process of implementing, without taking into account the effects this would have on the rest of the project.

This brings me to an article I found relevant to the topic, a post from the personal blog of a software developer (https://madhuraoakblog.wordpress.com/2017/03/01/design-patterns-revisiting-gang-of-four/) which talks about each of the different Gang of Four design patterns, (of which I was surprised to learn there are a total of 23). This post goes into sufficient detail for each of the different design patterns, without inundating the reader with excessive information. The author provides a simple explanation of each of the design patterns originally presented in the book Design Patterns: Elements of Reusable Object Oriented Software. Many of these patterns were unfamiliar to me with the exception of the creational patterns and maybe half of the structural patterns, which I had worked with for class assignments prior.

Of these 23 design patterns, I want to highlight one specifically which stood out to me in terms of versatility and overall usefulness.

Bridge pattern

Photo by Pixabay on Pexels.com

The bridge pattern is used to separate an abstract class or method from the class implementing it, by using inheritance/hierarchies. The example given by the author is of an abstract feedback class, with two sub-classes: questionnaire and comment, with each utilizing the same variable reviewable which was previously defined by the parent class, thereby acting as a bridge to separate the sub-classes from each other (both can be changed without it having any effect on the other as a result of the separation). I think this concept is useful because it keeps sub-classes notably separate from each other, while allowing them to each retain important aspects from the parent abstract class, so you can have each subclass be completely different besides the bridge aspects of the program which link them together.

I can see this being especially useful in programs where there are large amounts of specific functionalities added on to more centralized base abstract classes which define boilerplate functions and basic attributes.

Overall, I think that the Bridge pattern will likely be useful to me in the future, and combined with another pattern like decorator could be used to build a program with highly specific sub-classes which elaborate on functionalities defined in a central base abstract class. I believe this combination would be helpful in building GUI style projects, word processing applications, or anything where high flexibility and customizability is warranted.

Post Referenced:

https://madhuraoakblog.wordpress.com/2017/03/01/design-patterns-revisiting-gang-of-four/

From the blog CS@Worcester – CodeRoad by toomeymatt1515 and used with permission of the author. All other rights reserved by the author.

DOCKER

We have been working on Docker doing some activities in class for some time now so I decided to look for more resources on that talks more about Docker. I finally settled on this blog that gives tutorials on Docker. I chose this blog because it talks about some topics and defines some terms relevant to know when working with Docker. Links to some concepts and to some Docker commands are provided to explore the concept further.

In this blog, Docker has been defined with some examples, and reason for its popularity. It also talks about the difference between virtualization and containerization. Advantages and disadvantages of each of these concepts have been provided. A youtube tutorial is also provided to explain the concept further. It also talks about the benefits of using Docker and explains some other concepts such as Dockerfile, Image, Container, DockerHub, Architecture and Docker Compose. Some diagrams have been provided to help visualize some of the concepts being talk about. As I was reading through, I came across a link to a page that talks about Docker and Containers, explaining with examples and I found that very helpful.

I learned in this blog that Docker is a containerization platform that packages application and all of its dependencies together in the form of a docker container to ensure that application works well in all environment. A docker container is a standardized unit that can be created on the fly to deploy a particular application or environment. Docker have functionalities that are useful to both developers and system administrators.

Virtual machines and docker container are similar in the sense that they both allow running of multiple operating system inside a host machine.  However, Docker unlike Virtual Machine, allocates exactly the amount of memory required by a container which helps to create additional containers from any leftovers of allocated memory which by so doing, increase productivity. Docker saves a lot of time to start since the container runs on host operating system unlike Virtual Machine which runs on guest operating system, so it takes a lot of time to boot up.  Docker containers are also lightweight and faster because containers created are run from the host operating system.

In addition, I learned that multiple containers in docker can be run as a single server by using Docker compose. Also, Docker engine is an application installed in the host system that uses a server, a command line interface and a REST API. Images are built and containers are run by passing commands from the command line interface and the server. Docker images are also the building blocks of a Docker container and these images are stored in Docker Registry.

https://www.edureka.co/blog/docker-tutorial

From the blog CS@Worcester – GreenApple by afua3254 and used with permission of the author. All other rights reserved by the author.

State Design Pattern

            In keeping with my recent learning about Java Design Patterns, as outlined by the Gang of Four, I have recently been doing research on the State Design Pattern. I came across an extremely useful article which details the Design Pattern logic, implementation, upsides and downsides, as well as giving an overall evaluation. The article is titled “State Design Pattern in Java,” by Denis Szczukocki, and starts by explaining that the main usage for the State pattern is “to allow the object for changing its behavior without changing its class.” It is also cleaner than a project cluttered with if/else statements for controlling object behavior. The basis is that an object who’s behavior is dependent on a specific state can easily change states and therefore change behaviors without the creation of a new object and the classes responsible for this behavior will be “tightly coupled.” Within the pattern, there will be 2 essential classes and a number of extra classes dependent on the number of states required. The first is the context class. The context class delegates object behavior to the other class, the state class, but the context class is the one used by the client. The state class is usually an interface, with the concrete state classes implementing this interface and dictating behavior. The article gives the example of a package with 3 states: ordered, delivered, and received. There is a package class, which is the context class, and contains methods to move to the next/previous states and print the status as well. When an instance of the package class is created, really what happens is that an instance of the first state (ordered is created). When ready, the package object can move to the delivered state, and then the received state, all of which have different behaviors. The three behaviors in the PackageState interface common to all concrete states are next, previous, and printStatus, each which has a different behavior depending on the concrete class of the package. The article then notes that a possible downside to the State design pattern is that, “the state becomes hardcoded, which is a bad practice in general.” This taught me how to use the State Design Pattern and why it is good practice. I plan to use this in future projects when I can in order to practice, as well as to implement good project design practice. It is understandable and not terribly difficult to implement, so I know this can help me in my future work. 

Source: https://www.baeldung.com/java-state-design-pattern

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

Software Frameworks

https://techterms.com/definition/framework

            The link above leads to a website article that explains what a software framework is while giving some examples. The two main reasons I chose to write about this topic is because of one, it’s listed as one of the topics to be covered in class and two, I’m not too familiar with the definition of a software framework. According to the article, a software framework is essentially a set of tools that act as a foundation for software developers. These may include preset classes, APIs, compilers, code libraries, and predefined functions among other things. Examples of software frameworks include Microsoft’s .NET framework, Android Application Framework for Android, Cocoa Touch for iOS, and Cocoa for Mac OS X.

            From the definition given, the practicality of a software framework seems pretty apparent to me. Rather than creating classes and functions from scratch that will most likely see reuse, set them together in a ready to use package in order to save time and effort. It’s similar to how someone would buy ingredients at the supermarket rather than making each one from scratch. I’d imagine that software frameworks also have the added benefit of increasing portability for software that uses a specific framework. Take for example my computer which has .NET framework on it. If I were to create a piece of software using .NET, then another machine which has a similar version of same framework would be able to run my software with no additional setup needed. To be fair this is only speculation on my part; I haven’t checked whether or not this is true yet. But then again, I remember having to install a newer version of .NET framework in order for my computer to run software correctly so I might be on the right line of thinking.

In the case of porting software to machines with different operating systems, I’m not sure what role frameworks would take. I am pretty confident that software frameworks aren’t limited by operating systems. One example being Java Collections Framework or JCF for short which, as far as I know, isn’t limited to an operating system like .NET is. When a difference of frameworks is a factor, I assume that a software developer would have to make up for a lack of a framework’s components in a machine in some way. And that’s on top of the usual changes needed for porting software between operating systems.

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

Decorator Design Pattern

In this class we have learned Few design pattern and when you look at history of pattern there are several design pattern out there that I haven’t learned. Well today I am going to tack about Decorator design pattern where I am going to show you how I used it to make my code look professional. With Example. Let’s start with what is Decorator Design pattern and how can we implement it in code.

Decorator is a structural design pattern that lets you attach new behaviors to objects by placing these objects inside special wrapper objects that contain the behaviors. The intent is to attach a responsibility to an object at runtime. Sometimes we want to add a responsibility to an object A, not its whole class. … This can be done by wrapping A in another object that adds the responsibility. In other world clint has freedom to create object and then extend it by adding a varity of future to it. just like weapping a gift, putting it in a box and weapping the box.

What are success and failure of using this pattern? So let’s start with successes when you use this pattern in code extend an object’s behavior without making a new subclass., You can add or remove responsibilities from an object at runtime.,  also You can combine several behaviors by wrapping an object into multiple decorators. Now the failures so  It’s hard to remove a specific wrapper from the wrappers stack., The initial configuration code of layers might look pretty ugly.

now let me give you example of how I used it in code.this is just Class diagram. With Step by step about how to implement it.

Step 1: Create an interface FlyBehavior.java witch is blue print to the class which we will Decorate.

Step 2: Create concrete classes implementing the same interface. like FlyWithWings.java and FlyNoWay.java witch will create dynamically.

Step 3: Create abstract decorator class implementing the Shape interface like Duck.java witch contain refrence to interface.

step 4: Create concrete decorator class extending the Duck.java class. RedHeadDuck.java

Step 5: Use the RedHeadDuck to decorate DuckSimulator objects. witch will verigy the outPut.

Now how this pattern have connection with other pattern. Adapter changes the interface of an existing object, while Decorator enhances an object without changing its interface. Decorator lets you change the skin of an object, while Strategy lets you change the guts. Composite and Decorator have similar structure diagrams since both rely on recursive composition to organize an open-ended number of objects.

Reference:https://www.geeksforgeeks.org/the-decorator-pattern-set-2-introduction-and-design/

https://refactoring.guru/design-patterns/decorator

From the blog CS@Worcester – </electrons> by 3electrones and used with permission of the author. All other rights reserved by the author.

REFACTORING

As I was reading some articles, websites for my previous assignments, I came across the term refactoring a lot. However, that was not the only time seeing that as it is part of the course syllabus. I decided to learn more about refactoring and write something on it for my weekly blog post. After going through some resources, articles I finally settled on this blog post that talks about refactoring. The structure of this blog is made simple, easy to learn and understand especially for beginners and those new to the term. It also provides links to some terms, books and some other IDEs mentioned.

This blog defines refactoring as the process that involves editing and cleaning up previously written software codes without changing the function of the code at all. Blog talks about the importance of refactoring, reasons for refactoring and how to perform refactoring. It also provides some techniques on how to perform refactoring. Each technique is well explained and broken down into subtopics and/or steps with some diagrams provided. Also, blog talks about when refactoring is not needed, best practices for refactoring and general summary refactoring.

In this blog I learned that the basic purpose of refactoring is to make codes efficient and maintainable, reduce technical cost, improves readability, and help prevent future bugs. A term that I found interesting as I was reading about the importance of code refactoring is code rot. Further research from Wikipedia explained it as a software decay that is a slow deterioration of software quality over time leading to software becoming unusable or in need of upgrade. Refactoring is important as it help to avoid this code rot.

I also learn that the best time to refactor is before any update or additions to an existing code. This is so as it improves the quality of code and should be done in small steps as possible. Other practices include planning refactoring project and timeline carefully, testing frequently and involving Quality Assurance teams and striving to focus on progress.

I thought that refactoring is always needed especially dealing with very high coded software programs and systems, but I learned from this blog that refactoring is not needed when an application needs to be completely improved.

Some techniques of refactoring I learned are Red-Green Refactor, Refactoring by Abstraction, Composing and Simplifying methods. Before applying the Red-Green Refactor technique, there should first be consideration of what needs to be developed. These developments need to pass basic testing before improvements can be implemented. Refactoring by abstraction is used when there is a large amount of refactoring to be done. I learned that extraction, one of the processes in Composing method, involves breaking down of codes into smaller pieces to find and extract fragmentation. This code is then removed to a separate method and replaced by a call to a new method. This process also involves classes, interface and local variables.

I hope others find this blog useful as well.

https://www.altexsoft.com/blog/engineering/code-refactoring-best-practices-when-and-when-not-to-do-it/

From the blog CS@Worcester – GreenApple by afua3254 and used with permission of the author. All other rights reserved by the author.

More on Code Smells and Refactoring

Similar to how code and design smells were covered in class. I was interested in digging more into code smells and seeing how they influence development of code and how they can be rectified. I found that this would be a useful topic to further delve into because being able to pick up smells from your code will help prevent further mess in the future. To supplement my learning in this topic I got around to watching a seminar or conference video on code smells in java, which was hosted by Stanly Lau, a software development coach/mentor and also someone having experience of looking at companies code and giving advice on code smells and refactoring. In his seminar he basically went over code smells and refactoring techniques used to remove to code smells; in the seminar this is done by an example he goes over with the participants.

Besides going over code smells, what I really like from this seminar, was how he explains the significance of catching code smells in our code; he explains this via system diagrams to show that code smells are in a reinforcing loop relationship with bad code, and bad code is in a balancing loop with developer motivation; because of this we need to reduce bad code via refactoring. Refactoring is important because it instigates flexibility and helps to remove bad code or code smells. And flexibility is important in order to deal with change and he states “[i]f you cannot deal with change or how to improve with change easily, then you are probably in the wrong business”. The was a powerful I really appreciated, that change is inevitable in programming and in order to deal with change we must make our code more flexible, and that is where finding code smells and refactoring comes in.

I also enjoyed watching Stanly going over his example code of detecting and refactoring the code smells. His methodology appeared that he would look at the code and try to understand what is going on with the code (reading before coding) and then would see if he can detect any code smells such as comments, duplicated code, feature envy, long methods, primitive obsession, or magic number. Afterwards he would choose a means to refactor that code smell; the aspect of refactoring that he describes as ‘making small steps without breaking the code for too long’ is what I found helpful and will incorporate next time I am reviewing my code. Rather than just choosing a technique such as extraction method, I should be compartmentalizing steps to fix a problem and then work on improving on that refactoring. Overall it was a supplement for my learning in code smells as I was able to see a demonstration and also learn some more techniques use ide’s as well.

I attached the links to video as well as the diagram that explains effects of code smells in a developers environment below.

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.