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.

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.

As software designers and developers, we can often run into errors and issues during our development process. Design patterns however, provide a general reusable solution for the common problems that occur in software design. These patterns are known to typically show relationships between classes or objects. The overall idea is to speed up the development process by providing well tested, proven development/design paradigms. We can even use patterns in our own designs as it will only make our design more flexible, more resilient to change, and even easier to maintain. There are multiple different types of patterns that are extremely well known to designers and developers across the globe. These patterns are categorized into three different types, Creational, Structural, and Behavioral.

The Creational design patterns are all about object creation or class instantiation. The benefit of creational design patterns is that they enable a design to become more flexible and applying a creational pattern removes hard coded behavior or can move it into a higher level interface. Class creation uses inheritance in the instantiation process and defers creation to subclasses. Object creation uses delegation in the instantiation process and defers some of the creation to other objects. Some of the most common creational design patterns include the Factory Method, Abstract Factory, Builder, Prototype, and Singleton. Structural design patterns are a little different from the creational patterns, but they allow us to create large, flexible, and efficient structures. This pattern eases the design process by identifying a simple way to realize relationships. Some common types of Structural patterns may include, Adapter, Bridge, Composite, Flyweight, Proxy, and many more. More than often this design pattern will result in some form of abstraction and inheritance between two objects. Lastly, Behavioral design patterns is a pattern that strictly defines communication between objects, as well as classes. This pattern is solely for the purpose of increasing the flexibility of communication. There are many behavioral design patterns but some may include, Command, Iterator, Meditator, Memento, Observer, Strategy, and many more.

Design patterns are extremely useful and important to learn about as they can help accelerate the development process and help save time without needing to reinvent a new pattern every time a problem arises. They can especially be useful when you’re at the beginning of your journey as design patterns are a good starting point. Even if you won’t use them right away in your first projects, getting to know them will help you understand the existing solutions you’re using. The simplest and most complex solutions are all made up of different patterns.

https://jtearl188.medium.com/the-3-types-of-design-patterns-6138e353715b

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 week I stumbled upon an article regarding different software architectural diagrams. An architectural diagram is a visual representation that maps out the physical implementation for components of a software system. Other than the typical UML diagram, a different way to effectively communicate how you are planning to build a software system or how an existing software system works is with the C4 model. The C4 model, which stands for context, containers, components, and code, is a set of hierarchical diagrams that you can use to describe your software architecture at different zoom levels. Each case can be useful for different types of audiences. As developers, we can envision this model as a Google Map for our code. In order to create a map of our code, we would first need a common set of abstractions to describe the static structure of a software system. With the C4 model, we can consider the static structure of a software system into just terms of containers, components, and code, along with taking into consideration the people who use the software system.

We can break the C4 model into four different levels or steps, in which each level is adding something new to the diagram. Level one, is a simple system context diagram that shows the software system that you are building and how that would fit into the world in terms of the people who use it and the other software systems it interacts with. Level two consists of a container diagram. This zooms more into the software system and shows the containers that would make up that specific system. Containers could include applications, data stores, micro-services, and more. Level three, which is a component diagram, really dives into an individual container to show what the components are inside of it. These components provide us with a map to the real abstractions and groupings of code in our codebase. Lastly, Level four is based solely on coding. Here we can jump into an individual component to show how that specific component is implemented. It can really help show that the components can be made up of a number of classes with the implementation details directly reflecting the code.

The C4 model can be a simple, yet effective way to communicate software architecture at multiple different levels of abstraction. It can also be used as a way to introduce a different modeling technique to software development teams.

https://www.infoq.com/articles/C4-architecture-model/

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

Hello, I’m Conner and this is my first post.

CS@Worcester CS-343

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