Anti-patterns are patterns in software development that are considered bad programming practices. The exact definition is “An Anti-pattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences.” More understandably put, an anti-pattern is a way of not solving a problem. Anti-Patterns are said to be the opposite of Design Patterns, for instance, with Design Patterns, users usually start with a well-defined problem and identify the best path to take to the solution, whereas with Anti-Patterns, they begin with a failed solution, which can be challenging and usually further complicate matters.
(http://antipatterns.com/EdJs_Paper/Antipatterns.html)

I found a video online that I found easy to follow along to by Andy Sterkowitz on 5 programming anti-patterns that was specifically geared towards beginners. The first anti-pattern he spoke about was ambiguous naming; ambiguous naming of variables, functions and classes. He explains that when you’re writing code, your variables should be well named, to make your ( or another’s) comprehension of your code easy. He suggests really thinking about what you’re planning on naming things within your code to simplify things. The second anti-pattern he spoke about was magic strings and numbers.
Example:

The third anti-pattern is called lava flow. He compared this anti-pattern to how lava flows continuously and hardens along the way, saying that as a programmer early on, you think you’re just creating all these small little apps you might need but you’re actually making parts of your application warped or hard to develop. He suggests to use Git to modify and make changes to your code instead of building a whole bunch of different sections. The fourth anti-pattern he talked about was cut and paste. What that means, he says, is when you see a code and there are ten or so different functions that all just say the same thing basically. He suggests to instead make one function that does everything or even one class. Doing this will save you time from having to go back through each and every function and modify one thing. The fifth anti-pattern he talked about is called the poltergeist pattern. Andy explained that this is basically just code that doesn’t serve a true purpose, like a class that just calls upon another class.

Through this video, I learned that the best way to write code is to not have a lot of code and to really make sure you have strict guidelines about when it is appropriate to make a new class, method or function. Andy gave a lot of useful and helpful tips on how to improve my coding skills and what common mistakes I should avoid doing in the future. He used easy to grasp and very relatable metaphors and comparisons to real life that made understanding his explanations of the patterns easy and interesting. While watching this video I had quite a few “wow, that’s really helpful.” moments and I realized there are a few things I should and will be changing from here on out to tidy up my code.

Video used for this entry:
https://www.youtube.com/watch?v=lQ_rGCL17EE

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

This week I will be touching base on a structural design pattern called the adapter pattern. This pattern has two different versions, the class adapter – which implements the adapter using inheritance and can only be used in C++, and the object adapter – which uses composition to reference an instance of the wrapped class within the adapter. For the purpose of this blog post, I will be speaking only of the object adapter pattern.

Structural design patters are supposed to simplify your design, the adapter pattern in particular makes doing so easy as pie. The adapter pattern reuses old interfaces and provides different interfaces to its subject in order to make things work after they’ve been designed, even if the previous interfaces were incompatible. So what can this pattern do? Let’s break it down a bit:

– Change the interface of an existing object.
– Provide a different interface to its subject.
– Make things work after they’ve been designed.
– Reuse old interfaces.

The adapter pattern addresses incompatible interfaces and lets classes work together that previously could not due to incompatibility by converting the interface of a class into another interface that the clients expect. This conversion process allows software to exchange and make use of information. When you are dealing with different interfaces with similar behaviors, it is best to use this design pattern to help develop a clearer, more easily understandable code. A brief list of some of the benefits of using adapter patterns are:

– It is a low-cost solution.
– It is easy to understand.
– Incompatible code can communicate with each other.
– It makes things work after they’re designed.
– Helps to reuse existing code.

Information gathered for this blog post:
https://stacktraceguru.com/adapter-design-pattern
https://www.geeksforgeeks.org/adapter-pattern/
https://www.java2novice.com/java-design-patterns/adapter-pattern/
https://sourcemaking.com/design_patterns/adapter

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.

Welcome back!

This week in Coding Kitchen, we explore one of the key principles of Extreme Programming, YAGNI (You Ain’t Gonna Need It). This principle states that some capability we think our software will need in the future should not be built now because “you aren’t gonna need it“, or as XP co-founder Ron Jeffries put it, “Always implement things when you actually need them, never when you just foresee that you need them.”

The YAGNI principle is to be used in conjunction with other practices, such as continuous integration, continuous refactoring and continuous automated unit testing. Without the additional use of any of these other practices, your code could go into Technical Debt, which means it could become disorganized and need to be reworked. Using the YAGNI principle saves you time by helping you to avoid writing code that you do not end up needing and by making your code better because you did not have to fill it with guesses that turned out to be wrong.

In an article posted by Martin Fowler, he uses an example about selling insurance for the shipping business. His example states that an insurance company’s software system is broken into two components, pricing and sales and that the dependencies cannot usefully build sales software until the relevant pricing software is completed. His example also states that while the company works on updating the pricing component to add support for risks from storms, they consider working on a feature they will not need for another six months for piracy pricing. By adding on this additional feature now, Fowler declares that doing so would incur three classes of presumptive features, and four kinds of costs that occur by neglecting YAGNI for them.

1) Wrong feature — Cost of building, cost of carry + cost of delay
2) Right feature, built wrong — Cost of repair, cost of carry + cost of delay
3) Right feature, built right — Cost of carry + cost of delay

I chose this article because this particular example given by Fowler highlights the benefits of using YAGNI and why neglecting to do so would inherently cause many issues and become costly. As a future software engineer, I would prefer having to write less code that is easier to understand rather than have lines of useless, possibly obsolete code. I found Fowlers explanation of YAGNI and his further explanation of the many ways applying this principle could cause problems in comparison to the very few ways it could be of benefit easy to understand and useful. Having knowledge of this principle as a programmer will make writing and editing code in my future professional endeavors much more time and cost effective.

Inspiration and information gathered for this blog post :

https://dzone.com/articles/martin-fowlerbliki-yagni-youre-not-gonna-need-it

https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it

http://c2.com/xp/YouArentGonnaNeedIt.html

From the blog cs@worcester – Coding_Kitchen by jsimolaris and used with permission of the author. All other rights reserved by the author.