Category: Best Practices

Code Smells : Change Preventers

If you ever have been in a situation when you need to make change in one place, but had to make changes in many places too, then Change Preventers is a code smell you should be vary off. Change Preventers is result of poor structuring of code and can be broadly categorized into 3. Divergent … Continue reading Code Smells : Change Preventers

Code Smells : Object Oriented Abusers

While a well implemented Objected Oriented code is a hallmark of a good program, a poor implementation of the same could  lead to utter chaos as the project progresses. Object Oriented Abusers are a particular genre of Code Smells which refers to incorrect or incomplete implementation of Object Oriented Concepts. Switch Statements Switch Statements are … Continue reading Code Smells : Object Oriented Abusers

Code Smells : Bloaters (Primitive Obsession, Long Parameter List, Data Clumps)

Primitive Obsession If there is a code smell I often misses, then it has to be Primitive Obsession. Quite honestly, I have been guilty of falling for Primitive Obsession more than once. This particular type of Code Smell refers to the tendency of Developers to use primitive types instead of small objects for stimulating certain … Continue reading Code Smells : Bloaters (Primitive Obsession, Long Parameter List, Data Clumps)

Code Smells : Bloaters (Long Methods, Long Class)

Code Bloats or Code Bloaters are probably the most common signs of code smells you can see in any branch of code. In fact, eradicating bloaters act as the first step towards refactoring your code. Bloaters are nothing but classes or methods that have grown excessively over a long time marking it difficult to work … Continue reading Code Smells : Bloaters (Long Methods, Long Class)

Fail Fast Principle

There are 3 keys ways a developer usually approaches error handling in code. Ignore Fail Safe Fail Fast We have, at different point of writing code, used all three approaches. There are times when have good reasons to ignore a particular exception scenario, while at other times, we are opt for Fail Safe approach. Fail … Continue reading Fail Fast Principle

Design Patterns : Template Method

The purpose of a Template Method Pattern is to define the skelton of an algorithm, while deferring the exact steps to sub classes. There is plenty of literature on the internet detailing the pattern, so we will skip it and head right to the code. As always, lets begin by defining the contract interface, in … Continue reading Design Patterns : Template Method

Design Patterns : Chain of Responsibility

The intend of Chain of Responibility Pattern is to avoid coupling the sender of a request to its reciever by giving more than one object change to handle the request. Let's try to mimic the execution of classical Waterfall Model with CoR. Let's begin by declaring the contract interface. And our sub classes. The final … Continue reading Design Patterns : Chain of Responsibility

Design Patterns : Fascade Pattern

Fascade, name being an analogy to an architectural fascade, intends set the tone for the entire functionality by providing a simplified yet effective interface wrapping away the complex, pooly designed collection of APIs. Wrong Code Consider following set of Classes.   The Client Code could be As you can see, the Client class is invoking … Continue reading Design Patterns : Fascade Pattern