Category Archives: CS-343

Facade Design Pattern

This week we practice docker a lot bout docker Activity, but we havent learn all about patterns so I choose to write one more Main Design Pattern call Facade Design Pattern. in my homework 3 I picked Decorated design pattern but I have’t learn more about Facade Design Design Pattern. This is really help full in programing becuse it have high level interface that make subsystem easier to use.

Facade design pattern provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.Facade pattern is one of structural design pattern among other Gang of Four design pattern. The facade pattern is appropriate when we have a complex system that we want to expose to clients in a simplified way. Its purpose is to hide internal complexity behind a single interface that appears simple from the outside. Facade also decouples the code that uses the system from the details of the subsystems, making it easier to modify the system later.

To understand the facade, let’s take a very simple example of a desktop computer machine. When we have to start a computer, all we have to do is press the start button. We really do not care what all things go inside the computer hardware and software. It is an example of Facade pattern.

In Java programming, we must have connected to a database to fetch some data. We simply call the method dataSource.getConnection() to get the connection but internally a lot of things happen such as loading the driver, creating connection or fetching connection from pool, update stats and then return the connection reference to caller method. It is another example of Facade pattern in the programming world. Similarly, we can find a lot of more examples which hide lots of internal complexities and provide simple to use interface to the programmer to work with the system. All such are facade examples.

Remember facade does not reduce the complexity. It only hides it from external systems and clients. So the primary beneficiary of facade patterns are client applications and other systems only. It provides a simple interface to clients i.e. instead of presenting complex subsystems, we present one simplified interface to clients. It can also help us to reduce the number of objects that a client needs to deal with.

When you call a shop to place a phone order, an operator is your facade to all services and departments of the shop. The operator provides you with a simple voice interface to the ordering system, payment gateways, and various delivery services.

Source:

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

https://www.tutorialspoint.com/design_pattern/facade_pattern.htm

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

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. 

 

Source: https://sourcemaking.com/design_patterns/adapter#:~:text=Intent,class%20with%20a%20new%20interface

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

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.

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.