Continuing on our discussion on Code Smells and Refactoring techniques, we will discuss Dispensable in this post. Dispensables are avoidable components whose absence would make the code much more cleaner, readable and efficient. Comments A joke is not a good one if needed to be explained. A similar philosophy holds for code as well. If … Continue reading Code Smells : Dispensable
Category: Best Practices
Design Pattern : Memento Pattern
Memento Design Pattern allows to capture internal state of an object in an external object and restore it to the desired checkpoint when required, all the while being in compliance with encapsulation. The Memento Design Pattern comprises of 3 actor classes. Originator : The class which needs to have the ability to store its internal … Continue reading Design Pattern : Memento Pattern
Stairway Pattern
How do you feel when you invite your friend for a private family function and he brings along a dozen strangers (his friends) ? Entourage Anti-Pattern This is similar to the scenario when you want to add a library as reference and in turn ends up referring a different set of libraries which you … Continue reading Stairway Pattern
Looking back at DRY
Continuing with our series to bring together the common design patterns and principles, we will, in this particular post, look into arguably the most famous design principle known to programmers - DRY. Don't Repeat Yourselves - or DRY, is possibly the easiest to practice, at the same time, one that could go wrong in the … Continue reading Looking back at DRY
Design Patterns : Bridge Pattern
The essence of Bridge Pattern lies in the fact that it not just decouples the abstraction from implementation, but in doing so, allows both to evolve independently. Let's consider the examples of smartphones. The underlying OS (for sake of example, let's assume its Android) improving every year. The Android has seen atleast 7 versions in … Continue reading Design Patterns : Bridge Pattern
Design Patterns : Prototype Pattern
Falling under Creational Patterns, Prototype Pattern aims in creating a clone of your object and is used in scenarios when creating a object is considered costly (may be the creation involves a long Database or Web Service Operation). The formal definition of the pattern is as follows. Specify the kind of objects to create … Continue reading Design Patterns : Prototype Pattern
Design Patterns : Decorator Pattern
While Inheritance/Sub Classing seems to be most natural way of extending functionality, it might not be always the best option. Especially when you want to avoid subclassing as it might result in too many classes. Consider the following scenario. Your nearest Dominos has many varieties of Pizzas. On top of it, you could decorate each … Continue reading Design Patterns : Decorator Pattern
Why avoid Conversion Operators
No doubt that the Conversation Operators makes developers life easier by bring in a kind of substitutability, but it comes with a price. If not properly designed/used, it could result in subtle errors that can be easily ignored. Consider the following code. We have a class called Car, which exposes a single property - MakerName. We … Continue reading Why avoid Conversion Operators
Design Patterns : State Pattern
State Pattern is share a lot of similarities with Strategy Pattern, but has its own fundamental differences as well. The State pattern allows to change the behavior of a method, depending on the state of an object, in other words it encapsulates the behavior dependent on the state (the What). This is different from the … Continue reading Design Patterns : State Pattern
Design Patterns : Null Object Pattern
Null Pattern is probably one of the most underestimated and often most ignored among the design Patterns., though it turns out to be one of the easiest to implement. The intend of the pattern is to ensure we won't end up with NullReference Exceptions, while avoiding the long list of repeated preconditions that checks of … Continue reading Design Patterns : Null Object Pattern
ByteLanguage.Net 