This week I encountered a blog regarding Anti-Patterns. As we have learned, design patterns are reusable solutions to common problems and provide a way for us developers to solve problems in a proven way, rather than trying to reinvent the wheel every time a problem was to arise. On the other hand, Anti-patterns are unhelpful or ineffective approaches to problem solving that can negatively impact the efficiency and effectiveness of our work. 

Some common examples of anti-patterns include:

1. The Golden Hammer, which is when a specific tool or approach is overused or applied to every problem. I can personally say that I’ve fallen into this trap as I would always use the same programming language or framework to write code and would come to a standstill not knowing what to do next. Little did I know there were more suitable options that could’ve made my job easier and the end product more efficient.
2. The God Class antipattern, occurs when a single class in a software system becomes excessively large and complex, with too many responsibilities. I believe all developers including myself, at one point or another, created a class with too many responsibilities and would wonder why we have issues in our code. This would even violate the Single Responsibility Principle as each class should only have one key responsibility. 
3. The Big Ball of Mud antipattern, is when a solution lacks a clear and flexible architecture. As a program developer, I’ve encountered the big ball of mud antipattern and it can be a major source of frustration and inefficiency. Working with a system that has become a “big ball of mud” can be extremely difficult, as it can be nearly impossible to understand how the different parts of the system fit together and what each component is responsible for. This can make it difficult to make changes to our code, as it is unclear how those changes will impact other parts of our code.
4. The Copy and Paste Programming antipattern, is where code is copied and pasted from other sources without proper understanding or modification. I believe every programmer at one point found code that they believed they could reuse from another program and placed it into their new program. The program may work, but it causes many bugs and becomes difficult to later make changes. 

Overall, as important as design patterns are to follow, sometimes we will fall into the trap of an antipattern. In my own experience, I have fallen into the trap of using anti-patterns in my code. Now knowing how to avoid these patterns going forward, I’ll be able to recognize and avoid antipatterns and leverage design patterns that can help to create more effective and efficient code. By doing so, anyone can better achieve their coding goals and improve the quality of their work. 

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

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

This weeks blog of choice was from a source called altexsoft. Since the last couple of weeks in class and for homework we have been talking about REST API. I decided to pick a blog in that area so that I would help me refresh memory for some of the homework and also help me study for our third exam that why I picked this blog post called “REST API: key concepts, best practices and benefits” this blog post touches a lot on the things we learned in class which was a nice refresher but one of the things I like the most about it was the graphics that came with it. I am a very visual learner so seeing some diagrams really help put everything together. They had one of the diagrams about layered architecture, and how clients interact with the API layer reaching the server via a proxy. This help me view the order and understand it fully. One of the most interesting things I did find about this blog post was then they talked about different features that made a REST stand out. And how there were different Main API types like REST, RPC, SOAP GRAPHQL. Since in class we only most of the time dealt with REST. It was like to get a different perspective and different once and how they can be used differently how REST is good for mostly web, RPC for complex microservices systems, SOAP for financial services and last GraphQL is good for mobile applications. Seeing what all the different things they are used for, really helped paint a picture of the different systems and quality they have. During the read in this post what was coming to mind was all the different ways to implement the REST API. What I hope to take away from this blog post and what I have learned in class is different was to use it to create different applications. One of the ones I would really like to dig deeper into would be GraphQL because of the high performance mobile apps. REST was good and all to get information and request but it can have a chance of slowing down the request processing so that’s when GraphQL came in. GraphQL starts defining a schema that describes how a data is structured on the server which makes a single query and gets a precise response. Since mobile devices aren’t the most reliable when it comes to network multiple request have a high chance of failure so that’s why GraphQL is more efficient.

https://www.altexsoft.com/blog/rest-api-design/

From the blog CS@Worcester – CS- Raquel Penha by raqpenha and used with permission of the author. All other rights reserved by the author.

SOLID is a popular set of design principles that are often used in object-oriented software development. The acronym stands for five key design principles which are: single responsibility principle, open-closed principle, Liskov substitution principle, interface segregation principle, and dependency inversion principle. Together these principles are intended to reduce dependencies along with making designs easier to understand, maintain, extend, and avoid issues to build an adaptive, effective, and agile software. 

The single responsibility principle is a basic principle that many of us developers are already using daily in our own coding. The idea behind this principle is that every class, module, or function in the program should only have one responsibility or purpose in the program. A commonly used definition to describe this principle is that “every class should have only one reason to change.” Implementing this principle is sure to make your code easier to test, maintain, implement, and can help avoid unanticipated side effects of future changes. 

The Open-Closed Principle in summary, is that you should be able to extend a class’s behavior without modifying it. By following this principle can make our code writing easier to maintain and also revise in the future. Our classes would compile with this principle if it is open for extension and closed for modification. Open for extension means that the class’s behavior can be extended. While on the other hand, closed for modification means that the code is set and cannot be changed. This implies that such entities, like classes, functions, objects and so on, should be created in a way that their core functionalities can be extended to other entities without altering the initial entity’s source code.

The Liskov Substitution Principle is one of the most difficult to understand out of the five SOLID principles. This principle simply requires that every derived class should be substitutable for its parent class. The Liskov substitution principle implies that when an instance of a class is passed/extended to another class, the inheriting class should have a use case for all the properties and behavior of the inherited class. So, if we were to extend a class, if some of the properties of the initial class are not useful for the new class, then the principle will be violated. We can easily fix this though by creating an interface that matches the needs of the inheriting class. Following this principle helps to avoid unexpected consequences of changes and avoids having to open a closed class in order to make changes. It leads to easy extensions of software, and, while it might slow down the development process, following this principle during development can avoid lots of issues during updates and extensions.

The Interface Segregation Principle states that it’s better to have a lot of smaller interfaces than a few bigger ones. This means that you don’t want to just start with an existing interface and add new methods. Instead, start by building a new interface and then let your class implement multiple interfaces as needed. This principle makes us understand that it is unnecessary and unreasonable to create an interface with a lot of methods as some of these methods may be irrelevant to the needs of a particular user when extended. 

The Dependency Inversion Principle, simply put, is that developers should depend more on abstractions, not on concretions. For example we should make our classes rely on properties in our interfaces instead of relying on each other. The implications of violating this principle would result in a rigid system where testing blocks of code independently would be very difficult, reusability of code would be near impossible, and the addition or removal of code would lead to further complexity of the system and introduce bugs. High level modules should not depend upon low level modules. Both should depend on abstractions. Furthermore, abstractions should not depend on details. Details should depend upon abstractions. 

Overall, the goal of the SOLID principles is to reduce dependencies so that we can change one software without impacting others. With the  SOLID principles we can  make our code more maintainable, extensible, and flexible. These principles provide a set of guidelines for object-oriented programming and design, with the aim of making code easier to understand, debug, and modify. By following the SOLID principles, developers can write code that is more cohesive and less prone to errors, and that can be easily adapted to changing requirements or new features. Ultimately, the goal of the SOLID principles is to help developers create software that is of high quality, and that is easy to maintain and evolve over time. 

https://www.bmc.com/blogs/solid-design-principles/

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.

The Principle of Least Knowledge can go by many different names but the most common name today is the Law of Demeter. The Law of Demeter for Functions/Methods (LoD-F) is a design principle which is used for designing a system with minimal dependencies. It is typically summarized as “Only talk to your immediate friends.” This principle/law is more of a guideline than anything else. Some of its guidelines may include, each unit only having a limited knowledge about other units or objects and they should only be units or objects that are closely related to the current unit, each unit should communicate with its friends while not “talking to strangers”, and should only communicate with immediate friends.  

The main idea behind this principle is that inside of our applications, the code that we write should only express knowledge of its surroundings. The guidelines of LoD promote a notion of Loose Coupling in our codebase, which can lead to cleaner code with more maintainability. 

If we had a class that would implement a method, then the method should only be able to call a few objects. These include:

1. The object that owns the method.
2. Objects passed as arguments to the method.
3. Objects that are dependencies of the owner instance, which are held in instance variables.
4. Any object which is created locally in the method.
5. Global objects that can be accessed by the owner instance within the method. 

On the other hand, if an object was to know too much about another, then this could be considered a bad design as the object would then have to traverse from top to bottom of the chain to get actual dependencies it needs to work with. 

Overall, The Law of Demeter gives us a guideline on how to achieve loose coupling in our code and helps to properly encapsulate the knowledge of some complicated operations or logic into the places where they should be. By keeping this law in mind when producing our own codes and programs, it is sure to help us have cleaner code with increased maintainability and can help benefit the code we are producing when running it.

Principle of Least Knowledge

From the blog CS@Worcester – Conner Moniz Blog by connermoniz1 and used with permission of the author. All other rights reserved by the author.