The Principle of Least knowledge also called the law of Demeter, as explained in Eric Feminella’s blog “Principle of Least Knowledge”, is a design principle that provides guidelines for designing a system with minimal dependencies.  It is summarized in short as “Only talk to your immediate friends.”

A client should have knowledge of an object’s member, and not have access to properties and methods of other objects via the members.

The example shown in the blog has three classes: ClassA, ClassB, and ClassC. ClassA has an instance member of type ClassB and ClassB has an instance member of type ClassC. This shows that all the classes are connected one by one, and this can be extended further ClassC if need be. Now believe it or not this example violates The Principle of Least Knowledge because it creates multiple dependencies, thus reducing the maintainability because if ClassA needs some work so would all the instances of ClassA. This creates like a domino effect and keeping up with the client could pose some trouble.

Now, like the blog explains, in software development there might be some trade-offs. If the program runs better optimally with the above method, then maintenance might need to be pushed aside for just that. But it’s an important goal for the software developer to minimize dependencies, and by following guidelines provided by The Principle of Least Knowledge this becomes much easier to accomplish.

The Principle of Least knowledge is very important when it comes to coding because when it comes to programming a client itself, it becomes very easy to callback other dependencies to make things easier. But this creates more classes that, in a before blog would be referred to as “master classes” and more redundant code is created, and other dependencies are brought into the mix.

In code it seems like it’s better off if some classes don’t know the inner working of their other class, I’ve seen many programs break entirely because of one class. These classes are dependent of other classes. When one class falls all the other classes fall with it. So, It’s important to implement these dependencies so that they can be changed easily. And it’s also remembered to implement in such a way that they don’t require these chains of dependencies involved. All in all, it’s best to create a program that easy to modify and refactor so that the code is easy to work with in future development.

Link to Blog: http://www.ericfeminella.com/blog/2008/02/02/principle-of-least-knowledge/

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Anti-patterns are on the opposite side of the design pattern and are undesirable according to the blog “Anti-Patterns in Software Development That You Should Avoid”. Another term to describe Anti-patterns are called Design Smells.

The blog goes over the concept of the Golden Hammer anti pattern which occurs when using a familiar solution to attack an unfamiliar problem. Sometime it might work out, but most of the time it’s an inefficient way to solve problems.

The Golden Hammer anti-pattern is a concept that can shared in every aspect of life. Like for example, as mentioned in the blog some people tend to have their solution ready before understanding the problem like a doctor prescribing while the patient is still telling about the symptoms.

In software development, each design pattern is basically suited for its targeted problem. But it’s really easy to use the same framework, the same programming language, and the same design pattern for almost every problem. Like similar to the doctors example, some doctors might prescribe Ibuprofen to help a certain health but it might not completely relieve or heal that issue completely.

And so the Golden hammer could lead to; Poorly performing code, Overly complicated code, Redundant code. To avoid this anti-pattern it is best to find all potential solutions for one problem and benchmark them. List down all PROS and CONS for each solution then choose the better one.

Another anti-pattern is the God Class which for the most part controls many other classes, takes many responsibilities as well as lots of dependencies. An application could be well designed at the beginning so that there aren’t God classes but eventually dominant, very well specified classes will turn into God classes at some point.

The big ball of mud is a very common anti-pattern that happens when the solutions/application lacks a perceivable, flexible, suitable architecture as defined in the blog. A ball of mud will have, haphazardly and sloppy structure without coding comments, contains many God classes with more than 6000 lines of code, static variables/functions everywhere, methods being overloaded several times, and code duplications.

This anti-pattern is dangerous because it could happen while writing the application. Once we can’t refactor the code anymore, then we have to rewrite the entire thing. There are many reason why this anti-pattern could be brought up. It could be due to the frequent changes and requirements that the application might need, the deadline is near and the project is rushed, new developer are being brought in, or being too narrow minded about the design architecture that was initially brought in.

There are many more anti-patterns when it comes to the software development process, these are just the most common ones to date.

Link to blog: https://medium.com/geekculture/anti-patterns-in-software-development-that-you-should-avoid-780841ce4f1d

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

A bridge is a structural design pattern that lets you split a large class or a set of closely related classes into two separate hierarchical abstractions and implementation- which can be developed independently of each other. The blog from refactoring guru explains bridges a way of using more object composition rather than inheritance. Which means that we can extract one of the dimensions into a separate class hierarchy, so that the original classes will reference an object of the new hierarchy, instead of having all the behaviors with in one class.

Using this design principle, we can extract the code into its own class with two subclasses. And then we can have a reference field pointing to one of objects. That reference field will act as a bridge between one class to another and let’s say we needed to add another color for a shape, then we don’t have to go out of our way to create a PurpleCircle Class, we can just add the color, reference it with the shape and we’re done.

The blog has gone out of its way to explain real world applications for the Bridge pattern. One being used to help divide the monolithic code of an app that mages devices and their controls. The Device classes act as the implementation, whereas the Remotes act as the abstraction. The remote-control class declares a reference as explained in the description and that links it with a device object. All remotes work with the device via the general device interface.

Bridges are important because sometimes it can get hard to see what is contained with in a class especially if the class is gigantic. And making changes with one aspect of the class could require you to make changes in other aspects of the class. So, the bridge helps split the monolithic class into several class hierarchies. Which makes it different then most patterns like the Factory Design pattern or the Singleton pattern. The Bridge pattern would be mostly compared to the Strategy pattern where it plays a bigger role in how the code is being structured rather than adding some small commodities. It’s important to use the Bridge pattern to help extend the class in several orthogonal (independent) dimensions. It helps delegate the original class into related work to the objects belonging to those hierarchies instead of doing everything on its own.

The Bridge is very useful to help organizations within the code, I always tend to fill my classes with code with the use of implementations or inheritance so this would be a good way to get myself started on it.

Link to Blog: “https://refactoring.guru/design-patterns/bridge”

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

This week in CS-343 I’ve been getting familiar with REST APIs. This is not the only time I’ve had to use a REST API; I had to use them in my project last year for operating systems. REST APIS as explained in the stack overflow blog “Best Practices for REST API design” are one of the most common kinds of web services available today. It allows various clients including browser apps to communicate with a server via REST API. It’s important to design the REST API so that the client can properly and effectively communicate with the server.

First, what is a REST API? A REST API is an application programming interface that conforms to specified architectural constraints, like stateless communication and cacheable data. It is not a protocol or standard. REST APIs should accept JSON for request payload and response to JSON. JSON is the standard for transferring data. On another note, while transferring dates, I didn’t use JSON in my project, instead, I ended up using Curl. A curl is a command-line tool for transferring data, and it supports about 22 protocols, including HTTP.  It’s very good when testing REST services, but the blog and most sources I would say would recommend JSON for requests/responses. I was familiar with JSON files, it’s common, but now I understand why using JSON is the more optimal.

Endpoint paths are used to grab/modify whatever information you might want from the REST service. The most common ones are GET, POST, PUT, and DELETE. GET retrieves resources, POST submits new data to the server, PUT updates existing data, and DELETE removes date.  Creating routes are how we can use these endpoints. For example, let’s say that we have a route called article, POST /articles/ is for adding a new article, PUT /articles/:id is for updating the article with given id, DELETE /articles/:id is for deleting an existing article with given ID.

To avoid any confusion when an error occurs, we have HTTP response codes so that we can figure out the root of a problem, the common HTTP status codes include 400 Bad Request This means that client-side input fails validation. 401 Unauthorized – This means the user isn’t not authorized to access a resource. It usually returns when the user isn’t authenticated. 403 Forbidden – This means the user is authenticated, but it’s not allowed to access a resource.404 Not Found – This indicates that a resource is not found. 500 Internal server error – This is a generic server error. It probably shouldn’t be thrown explicitly. 502 Bad Gateway – This indicates an invalid response from an upstream server. 503 Service Unavailable – This indicates that something unexpected happened on server side (It can be anything like server overload, some parts of the system failed, etc.).

This doesn’t cover all the details of REST API but for the most part, this will get you a decent understanding of how it all works.

Link To “Best Practices for REST API design” : https://stackoverflow.blog/2020/03/02/best-practices-for-rest-api-design/

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

The Observer Pattern is a design pattern that allows objects to react to changes in another object’s data while maintaining loose coupling. Loose coupling, for a reminder, is a system in which components are weakly associated with each other.  The pattern as described in Ilyana’s blog “The Observer Pattern” is a pattern that can decide at runtime whether to receive data from the subject-object.

                The blog goes on to say that it is not uncommon for object-oriented programming to run into a situation where you have an object in your code that collects/outputs data and other objects that care about that data. Some objects might care about certain data that the programmer might throw at them, such as measurements or certain temperatures. These objects are the observers. The observers do not care what class gives them the data, only that they receive the data as it changes. Signs that your code might need to be refactored to utilize the Observer Pattern include an object that is dependent on another object or a change to one object that requires a change to many others.

                The Observer Pattern defines a one-to-many relationship between a set of objects. The Observer Pattern defined one subject’s relationship with its many observers. The Observer Pattern will separate the subject from its observers while still allowing the observer to react to changes in the subject’s data. The observers provide a method that allows the subject to inform them of the updates. This pattern allows for loose coupling once again between subjects and observers. As explained in the blog they can interact but don’t know that each other exists, they basically know nothing about each other.

                The pattern is usually implemented using an abstract subject class and an abstract observer class, which a concrete subject and some concrete observers inherit. This pattern would be very useful if I ever needed the objects to receive an update when one object changes. It’s very intriguing to hear the terminology they use within the blog. The subject acts as a publisher which sends out the information and the observer, which acts like a subscriber, basically takes in the information it wants to receive. Obviously with I can see the subject sending information that the observer might not want to receive or have on them. Non the less it’s a very interesting pattern that shows the process of what a loose coupling might look like in a coding environment.

Link to Blog “The Observer Pattern” by Ilyana: https://ilyana.dev/blog/2020-08-07-observer-pattern/

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Learning new design patterns can be interesting because, for the most part, it explores a new way of coding that I thought I would never have to use. This week I’ve been refactoring design patterns in my code, such as the Singleton pattern. The Singleton pattern is a design pattern that is supposed to restrict the instantiation of a class to one object. Basically, it’s used so that when that object is created then we don’t have to recreate that object. Recreating that object would wipe clear the information that you want that object to hold. That is where the Singleton Pattern shows up! But for now, I want to go over the Abstract Factory Design Pattern. The Abstract Factory Pattern is almost like the Factory Pattern but according to the blog “Abstract Factory Design Pattern in Java” published by Pankaj, the Abstract Factory Design is like a factory of factories.

If familiar with the factory design pattern, it uses a single Factory class, this factory class returns different subclasses based on the inputs provided and the factory classes use if-else or switch statements to find out the class it’s supposed to bring up. In the Abstract factory pattern, the if-else statement or switch statements are thrown out the window and instead, we have a factory class for each sub-class. And then we have an Abstract Factory class that will return the sub-class based on the input factory class. So the Abstract Factory uses multiple sub-classes of the factory class which is then implemented into a superclass which would be the abstract class.

The Abstract Factory will use a more interface and extension approach rather than implementation. In contrast to the factory method, all the subclasses are basically put into one class which would be the factory class, and that one factory class was the class to call if a subclass needed to be reached. Now we have all these classes that represent these subclasses that can be changed or coded to our liking. So it’s a lot more robust because we don’t have to be hammered down by conditional statements, but since we don’t really have that simplicity anymore, things do tend to be a lot more complicated. It’s a lot more complicated because of the many classes that can be involved in making a factory and plus the many specifics and ideas that have to go into those sub-factory classes I guess you could call it.

It would be really interesting to implement this in one of my projects. Right now I’m making modifications to a game called Minecraft, you might have heard of it, it’s a pretty popular game. It would be interesting to create an Abstract factory design for the many tools or blocks that I’ll be adding to the game. It might seem complicated but it could help me better organize the mod a lot better.

Link to Blog “Abstract Factory Design Pattern in Java” by Pankaj:

https://www.digitalocean.com/community/tutorials/abstract-factory-design-pattern-in-java

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

While looking through my blogs, I came across a familiar acronym that I used all the time when it comes to developing software and system. The acronym is called “YAGNI”, which stands for “You Ain’t Gonna Need It” according to the blog “Automation Principles – YAGNI/Premature Optimization, It’s the principle of extreme programming that states a programmer should not add functionality until deemed necessary. The blog takes about how many engineers will spend multiple hours trying to build the “right system” the first time. In some cases, trying to build a flawless system in the first go can be rather difficult to achieve. The problem is that programmers spend too much time worrying about efficiency in the wrong places and having that premature optimization can cause more harm than good. The blog goes over Big- O notation which explains that it does not care about constants but the long-term growth rate of functions. This is a good rule to consider because having to introduce something before a fraction of the code is even written can make a program a lot more difficult to support as explained, it would increase design considerations, the likelihood of race condition, and the ability to troubleshoot. Optimizing certain processes might not lead to any time savings or real optimization. In fact, it could do the exact opposite, a good example that the blog states are when using Python, constructing lambdas and list comprehensions over simple for loops. The blogger has mentioned that in his personal experience he would add non-functional requirements, such as authentication and logging, too early, adding features before needed. With that being said, I remember spending so much time on adding the ability to connect my bank to my finance application, that I didn’t have the time to code the application itself. The blogger talks about network automation which explains more about how networking is all about speed and not creating YAGNI isn’t really in the cards. They would go into detail about real-world examples when it comes to the network automation process, explaining issues about multithreading, in which he explains that overloading the TACACS server with too many requests at once is very problematic, or scaling wide too fast can cause processes to slow down and too much resource utilization, overall, it’s very inefficient. Configuration Generation takes too long and is very inefficient, and with all these in mind, the blogger isn’t trying to not consider tomorrow’s problems but is more in line with building things up as they go.

“Automation Principles – YAGNI / Premature Optimizations” :

https://blog.networktocode.com/post/Principle-YAGNI/

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

These past few weeks, I’ve been getting myself refamiliarized with UML Diagrams. These diagrams have made a frequent appearance in my CS career. From my complete understanding, they are a great way of analyzing one’s code from the top down. At first, I thought it was just another hassle. Some of these UML Diagrams can get rather difficult to understand, and with all terminology and ways to draw out these charts, it can get pretty hectic to understand how the code works. I learned to take in the information given one at a time. In the blog “Types of UML Diagrams” by Lucid Content Team, it explains that when it comes to any formal code training, UML diagrams are essential but take some time to build and become really out of date fairly quickly, in an Agile environment. But they are very useful for quick visual documentation so that employees can give stockholders a quick overview of the system so developers don’t waste time in meetings.

UML stands for Unified Modeling Language, which is a way to visually represent the architecture, design, and implementation of complex software systems. It is supposed to keep track of the relationships and hierarchies within a software system. It’s hard enough to keep track of thousands of lines of code and so the UML diagram is supposed to keep track of all these components of the software. UML diagrams can be used with basically any programming language and so all software developers should be able to understand it. UML diagrams keep things productive and focused, and they are very helpful to engineering teams. This can include bringing in new team members or developers up to speed, source code navigation, and planning out new features before programming them, and it helps communications between a non-technical audience more easily- which means that most people will be able to understand the process regardless of programming experience.

There are many types of UML diagrams. The first is structural UML diagrams, which show how the system is structured, with classes, objects, packages, and the relationships between them. The component diagram is a more specialized version of the class diagram, which breaks a complex system down into smaller components and will visualized the relationship between the components. Deployment diagrams show how software is deployed on hardware components in a system. Composite structure diagrams are essentially blueprints for the internal structure of a classifier. Object diagrams show examples of data structures at a specific time. And package diagrams are used to show dependencies between different packages. Obviously, this doesn’t even cover half of the UML diagram spectrums since we didn’t even Behavioral UML diagrams which are used to visualize how the system behaves and interacts with itself and other systems.

I’ve come to realize that UML diagrams can be very useful, it’s important to read code from the source but that can be rather time-consuming sometimes. UML diagram is a lot easier to take in and can explain how the software works in just minutes. In my future projects, I want to be able to utilize UML diagrams so that I can better explain my own work to others. I feel it would have been very easy to explain my past projects to people if I was able to have one. The blog was quite interesting because it explained the many types of UML diagrams that exist and their practical uses.

Link to “Types Of UML Diagrams” by Lucid Content Team: https://www.lucidchart.com/blog/types-of-UML-diagrams

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.