So what even is an anti-pattern? Well, anti-patterns are solutions to ineffective problems that eventually cause more problems than they solve them. They are often used because they seem to work very well but the long-term consequences are not usually thought of. Anti-patterns are just like a regular pattern but instead of a solution, they give a superficial solution but really isn’t one at all. Programming anti-patterns are known for common mistakes, they can lead to problems like maintainability. The spaghetti code is a good example of anti-pattern, it’s a code with no structure. There are random files scattered into random directories, the whole thing is difficult to follow and is tangled together. This usually happens when someone isn’t carefully thinking out their program and how smoothly it should be running before actually coding. It makes it basically impossible to add any new functionality, no matter how many changes you try to make and try to understand those changes you will still end up with countless issues with your code. Another example of anti-patterns is the boat anchor. The boat anchor happens when someone leaves a piece of code in the codebase because they believe that they will need it later but doing this actually can keep your project from moving forward, can cause your coding time to slow down, and mess up your codebase.

Avoid anti-patterns with better system management. You can avoid anti-patterns in your code by being more consistent with your system. By reviewing your code, looking through and making sure you have no typos and grammatical errors. These code reviews help improve the quality of your code and make it easier to find better solutions for any common problems your’re having. Always have someone else take a look at your code in case you did miss something that you didn’t see it’s always helpful to have a set of fresh eyes look at your code so it can help you tighten up your code. The process of engaging in code refactoring can also help make adjustments that will strengthen your code’s structure and framework without impacting the user experience. Refactoring is very helpful in simplifying your code construction.  It will make it easier for someone to take a look at your code and understand how you put the code together and be able to add any new functionality to the code as well. Making the code a visual can help give you as well as others a better understanding of the information presented to them. It can help you show the workflows, and analyze and brainstorm for any new improvements.

https://www.lucidchart.com/blog/what-are-software-anti-patterns

https://www.baeldung.com/cs/anti-patterns

From the blog CS@Worcester – Kaylene Noel's Blog by Kaylene Noel and used with permission of the author. All other rights reserved by the author.

In the intricate world of software development, as developers strive to create elegant and efficient solutions, they encounter not only best practices but also pitfalls to avoid. These pitfalls, often referred to as anti-patterns, are common design and coding practices that may initially seem like solutions but ultimately lead to more problems than they solve. Understanding and recognizing these anti-patterns is a crucial part of becoming a seasoned software developer.

At its core, an anti-pattern is a recurring design or coding practice that appears to be helpful but is counterproductive in the long run. It’s like a mirage in the desert – promising relief but ultimately leaving you more parched. Anti-patterns often arise from misapplications of well-intentioned ideas or a lack of experience in software development.

One common anti-pattern is known as “Spaghetti Code,” where the codebase becomes entangled and challenging to maintain. While quick fixes and shortcuts may seem like a solution, they often lead to a tangled mess that hampers productivity.

Another notorious anti-pattern is “Cargo Cult Programming,” where developers mimic code without understanding its purpose. This blind imitation can lead to code that lacks context and may introduce errors.

By studying anti-patterns, developers can proactively identify and avoid these pitfalls. It’s akin to recognizing warning signs on the road and taking detours to smoother coding practices. In the ever-evolving landscape of software development, understanding what not to do is as important as knowing what to do. Recognizing anti-patterns empowers developers to make informed decisions and craft robust and maintainable software solutions.

References:

• Anti-patterns
• Design Patterns and Anti-patterns
• Common Anti-Patterns in Software Development

From the blog CS-343 – Hieu Tran Blog by Trung Hiếu and used with permission of the author. All other rights reserved by the author.

REST stands for Representational State Transfer. This means that when a client requests a resource using a REST API, the server transfers back the current state of the resource in a standardized representation.

From the blog CS@Worcester – Andres Ovalles by ergonutt and used with permission of the author. All other rights reserved by the author.

During the course of this course (Software Construction, Design, and Architecture), there have been design concepts that are very easy to grasp at first glance, and those that take much more time to digest. I was surprised to see that the Law of Demeter, or Principle of Least Knowledge, is a fairly intuitive rule, but feels almost too restrictive in nature.

Essentially, the Law of Demeter is the concept that methods in an object should not communicate with any element that isn’t ‘adjacent’ to it. According to a blog post by JavaDevGuy (and thinking of a Java application to the rule), the elements that are allowed by the law are the object itself (this), objects in the argument of the method, instance variables of the object, objects created by the method, global variables, and methods that the method calls.

This is most easily explained by a negative example. For example, if a class Car has a method with a Dashboard object as an argument, it can technically call something like dashboard.getVersion(). But if a class Garage method has a Car argument, the method should not call something like car.getDashboard().getVersion(). Maybe this is a silly example, but this applies to more practical code as well.

JavaDevGuy goes further to say that most Getter methods violate this law. This interpretation seems restrictive, as it makes it much more difficult to just get work done (of course, I’m not the most experienced in the design aspect of software engineering so I could be wrong). It seems more practical to use the law to get rid of chaining in your code, as it causes needless complexity. Chaining methods together, regardless of how necessary it is, always ends up looking kind of ugly. I do feel like it is a necessary evil sometimes though.

As it stands, I can understand that this sort of practice can minimize that amount of complexity and reduce code repetition, but it does feel like sometimes you sort of need to put things together in this way to get the desired output. The aforementioned blog post seems to explain when code is violating the law, but unless my eyes and brain are too tired to read properly, the author doesn’t really give any good replacement options for the code. The few alternatives given don’t seem very desirable. This is typically the problem with negative rules, it imposes a restriction without a solution, and so you have to scramble to figure out how to work it.

Perhaps I’ll understand better when we cover this material in class.

From the blog CS@Worcester – V's CompSCi Blog by V and used with permission of the author. All other rights reserved by the author.

SOLID is an acronym that stands for the 5 different principles that help write high-quality, maintainable, and scalable code. These include Single Responsibility Principle (SRP), Open-Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP) and Dependency Inversion Principle (DIP). Each provide their own benefits and work in tandem together when designing a program.

SRP states that a class should only have one responsibility, meaning only one reason to change. This helps prevent a class from having too many responsibilities that can affect each other when one is changed. Following SRP ensures that the code will be easier to comprehend and prone to fewer errors. However, it is harder than it sounds to fulfill this principle. The quickest solution to adding a new method or functionality would be to add it to existing code, but this could lead to trouble down the road when trying to maintain the code.

OCP states that software classes, modules, functions, etc. should be open for extension but closed for modification. This is essential because it allows entities to be extended without modification so that developers can add new functionality without risking the chance of breaking the code. Adding an additional level of abstraction with the use of interfaces help design the program to provide loose coupling.

LSP states that any instance of a derived class should be substitutable for an instance of its base class without affecting the program in a harmful way. The importance of this principle revolves around the ability to ensure the behavior of the program remains consistent and predictable. Unfortunately, there is no easy way to enforce this principle, so the user must add their own test cases for the objects of each subclass to ensure that the code does not significantly change the functionality.

ISP focuses on designing interfaces that are specific to a user’s needs. Instead of creating a large interface that covers all methods, it is more beneficial to split up the methods across smaller, more focused interfaces that are less coupled. For example, having too many methods in an interface can sometimes cause issues in the code, so separating the methods into individual interfaces that can be implemented by a certain class.

DIP states that high-level modules should not depend on lower-level modules but should depend on abstractions. This approach aims to reduce coupling between modules, increase modularity, and make the code easier to maintain, test, and extend. An important thing to note is that both high-level and low-level modules depend on abstractions. Dependency Inversion utilizes the SOLID principles which in turn leads to a more refined and maintainable code.

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.