Throughout the semester, we have been learning a lot about good coding practice, which includes the implementation of various software design patterns. While we can try our best to fit our code into these design patterns, oftentimes this is not the case, at least for me. So, here is a list of several software design “anti-patterns,” or bad-practice patterns. My good pal James Blash (found at www.jwblash.com) gave me the idea to look more at these anti-patterns. The link that he recommended is https://sourcemaking.com/antipatterns/software-development-antipatterns.
This list has several great examples of different ways that code falls into more of bad practice. Here is a brief overview of some of the interesting design pattern problems that I found from this list.
- Cut-And-Paste Programming – This anti-pattern involves the reuse of existing source code, rather than programming new code from scratch. This can result in multiple errors of similar nature, as errors from the existing code can affect the rest of the program when pasted elsewhere. A fix to this problem utilizes more of a black-box reuse development process, such that the issue of reusing buggy code is more likely to be bypassed.
- Input Kludge – This anti-pattern occurs when behavioral testing fails because software accepting free text input uses “ad hoc” algorithms, which does not account for illegal statements or combinations of characters (e.g. strings when the input only accepts numbers, etc.). Solutions include the use of free parsing software or simply examining and possibly revising the algorithms to account for and properly handle “input kludge” being entered into the system.
- Golden Hammer – This anti-pattern occurs when developers use sort of a “one-size-fits-all” approach to coding; in other words, they take advantage of one or a couple of solutions to attempt to solve all other issues in their programs. A solution to this problem involves further education or training for team members to learn more about other ways to solve problems that arise, rather than just sticking to one familiar concept.
- Poltergeist – This anti-pattern uses poltergeists, or classes with very limited use throughout the program, but can potentially break the whole system when it isn’t there. Often, poltergeist classes start other processes taking place in the program. The solution reorganizes the class structure such that longer-lived objects in the program take on the responsibilities that the poltergeist(s) handled, thus removing the need for the poltergeist classes altogether.
Hopefully with this new information in mind, I hope to try to avoid some of these issues later in my classes, as well as my career!