Category Archives: Week 6

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.

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.

Jog at the Back of the Pack

The pattern “Be the Worst” is one that most people have heard many times and its a great life lesson that can be applied to many other situations. The idea is to surround yourself with people that are better than you and learn from them and grow. Basically don’t be afraid to not be at the same level as your peers and try to surpass them with every experience. This can also be a way to help others that are struggling or want to be better at something that you excel at. This pattern is definitely one that i could see myself using in my professional career and also in my education because the quickest way to learn something is to be surrounded by people that understand the concepts and to observe them and ask questions. Everyone has weak points and things that they wish they could be better at so finding people that excel at what you struggle with can only help you to learn and grow.
The one thing that I feel this pattern failed to make an extremely important part is that you should strive to go on and become the best at what you learn. I might just be a competitive person and this may not apply to all people, but I personally would want to become the best at whatever I do. This pattern also fails to really talk about doing the reverse which would be helping others in the same way that you want help. This pattern changed my perception about the profession of software development because I didn’t really think about how people from all over the place could be assembled to help one another understand things and it makes me think of a coalition/brotherhood rather than work or a job. The pattern talks about how it is a little selfish to join a team knowing that you are the weakest link and that you might hold them back a little, but sometimes you need to be selfish and think about yourself and what you need to grow and become better. Being selfish at times is needed to advance yourself and your career, so I’ll probably do this pattern unashamed and ready to become the best in every group.

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

Independent Study: The Plateau, the Snag, and the Obstacle

Researching more on audio feature extraction last week gave me a lot to think about. As it settled in, I came up with great ideas for hypothesis to test and specific applications for them. The kind of ideas that lead to turning off your cell phone, skipping lunch and dinner, and get things working.

Unfortunately, as mentioned last week, I do not have the time learn audio processing algorithms to the extent that I can implement them, so I will have to make a choice on a library that will help. A further complication was getting code to run in Android. Libraries exist to run Python code in Android, but the Python libraries I’ve found for audio analysis are lacking in features and I would need to use a combination.

The most comprehensive library I’ve found is Essentia. Of course, it’s so comprehensive I won’t be able to use the code for a professional app without a commercial license. Luckily there is a noncommercial license available that will allow me to get results for the project and determine if there are commercial applications.

Essentia is a C++ library. So the good news is I get to use JNI and the Android NDK (Native Development Kit) to run C++ code. Getting C++ code to run from an Android Activity is straightforward enough, but I do worry about potential complications in running Essentia. There are a number of dependencies that I fear might cause trouble with a feature I might want in the future. These are kept to a minimum with a special flag during compilation for Android. But alas, my paranoia strikes.

Because Essentia is open source, I am at least able to see implementations of the audio processing algorithms, and the code is well-documented with references to studies. Signal processing is a degree, not just a semester-long project. I certainly appreciate that fact more over the past couple of weeks. But this will be a great overview and using the code will still require understanding of the underlying processes.

Progress was made on converting files from audio to basic byte data. When I was considering Python libraries, I was under the assumption I could use WAV files and easily get byte data (for example, with librosa). Android’s MediaRecorder doesn’t support saving WAV files, so other formats must be used.

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.