C#

Transient fault handling in Sitecore Commerce

Posted on

Transient fault handling can be cumbersome and lead developers to write repetitive code. There could be many situations when you want your code to be retried in case of failures/exceptions etc. While working with a few external system integrations, we had to implement a retry mechanism for certain transactional requests. Payment integrations are one of the examples that I am using here. Polly is a library that allows developers to express resilience and transient fault handling policies such as Retry, Circuit Breaker, Timeout, Bulkhead Isolation, and Fallback in a fluent and thread-safe manner. Almost all the payment providers we integrated to Sitecore Commerce project e.g. Braintree/DiectBank/Openpay recommend to retry the transactional requests in case of timeouts or internet issues. For example when we request Braintree payment gateway to settle the payment if the request times out you have to retry the same request 3 times before you treat it as a failure. Since the retry could be handled […]

Software Design

Dependency Inversion Principle

Posted on

Start implementing DIP in your code, it will drive you through other SOLID principles as well. Take advantage of DIP to write loosely coupled software modules/classes. This makes a software modules mockable and testable . Dependency inversion principle has two parts. High level modules should not depend on low level modules directly, both should depend on abstractions. Abstractions should not depend on details, details should depend on abstractions. In order to understand this, let’s revise our example on Notifier we implemented while implementing Single Responsibility Principle with a bit of modification.

Here CampaignManager depends directly on EmailNotifier. This is poor design as both modules are tightly coupled, changing one would need changes in the other. If we need to send notifications through SMS rather email messages we will need to change almost everything. This is what DIP part 1 says, modules should not depend directly on other modules but they […]

Software Design

Interface Segregation Principle

Posted on

It’s useless to sell a frying pan to someone who doesn’t cook. Don’t give him a chance to say I don’t cook. In programming world we call it throwing NotImplemented Exception. An interface defines the contract of an object. Contract means, the functions an object has to perform. When a class implements an interface, it has to provide implementation of all the functions defined in interface. ISP states, Clients should not be forced to depend upon interfaces that they do not use. Always create smallest possible interfaces rather interfaces with huge number of methods (contracts). Classes that implement interfaces should not be forced to provide implementation of methods which are not useful for them. Problem arises when any client using such an interface would end up having functions it does not use. Let me code Let’s assume a scenario where we have to work with streams of data. For defining […]

Software Design

Liskov Substitution Principle

Posted on

OCP and LSP are very closely related. Implementing OCP would implicitly follow LSP in most of cases. LSP states, If S is a subtype of T, any object of T can be substituted with an object of S leaving our software in stable state. Most of developers might know substitution already but let me explain a bit before moving forward. Consider a method void Notify (Campaign campaign). While calling this method we pass it the object of campaign Notify (new Campaign()); . Suppose our Campaign class has a child class called SummerCampaign then according to LSP calling this method as Notify (new SummerCampaign()); should also work for our software. IS A relationship is a very common OOP concept. Every duck IS A bird, every Honda City IS A car, every square IS A rectangle and every SummerCampaign IS A Campaign etc. To represent these entities in object oriented way, we create […]

Software Design

Open Closed Principle

Posted on

Take advantage of OCP to write highly extendable and maintainable software. Introduce new changes with minimal impact on the existing system. OCP seems to increase complexity of code due to abstraction levels it introduces. Embrace it pragmatically, find good candidates for OCP while designing software. OCP states, our classes should be open for extension but closed for modification. Whenever we have to implement a change or add new functionality, instead of changing the existing class we should extend the functionality of existing class. Let’s try to understand with a scenario below. In our example for Single Responsibility Principle, we used a logger to log exception messages to a text file. In future we may have a requirement to log some error messages to database or application even log. How should we design our software to allow extension to logging functionality in future? Let me code: For OCP example I have […]

Software Design

Single Responsibility Principle

Posted on

Use SRP guidelines to write loosely coupled and highly cohesive software units which can be reused. This makes the software extendable and maintainable.  Classes and interfaces are basic units of a software. While writing a software we often overload a class with multiple responsibilities. As name suggests SRP states that a class should only perform one responsibility. Let me code Let’s take a look at the example below for more clarity on SRP.

At a glance you may like the code and decide to go along with this. Hold on, let me explain the problems in this code in the light of SRP. This class is performing 3 different responsibilities. Launch the campaign. Notify all the subscribers. If some exception occurs, log the exception with some message. This is the violation of SRP. In future if we have to change the way we log our exception messages e.g. we want to […]

Software Design

SOLID Programming Principles

Posted on

SOLID programming principles have caught too much attention recently. There are many articles on SOLID principles that explain them superbly. My focus here would be to start with a simple example and apply these principles to see how we can shape up our code to match the Characteristics of a Good Software. I would show how we can achieve these characteristics by following the SOLID principles. SOLID is an acronym for S – Single Responsibility Principle (SRP) O – Open/Closed Principle (OCP) L – Liskov Substitution Principle (LSP) I – Interface Segregation Principle (ISP) D – Dependency Inversion Principle (DIP) Single Responsibility Principle (SRP) Use SRP guidelines to write loosely coupled and highly cohesive software units which can be reused. This makes the software extendable and maintainable.  Classes and interfaces are basic units of a software. While writing a software we often overload a class with multiple responsibilities. As name suggests […]

Software Design

Writing a Good Software

Posted on

What is a good software? This question might seem trivial but software gurus have defined a set of characteristics and in order to be good a software must exhibit either all or a subset of these characteristics. From a developer’s point of view some of these characteristics are very important. Let me explain them briefly here Maintainability: Changes/modifications are inevitable during the life cycle of a software. A software is said to be maintainable if developers can incorporate the changes with minimum effort and minimum impact on the existing functionality. Scalability: A software is said to be scalable if it can entertain the increasing number of users over the time. Extendability: Adding new functions to the software should be easy. Reusability: Divide the code into reusable units. These units should be loosely coupled and highly cohesive. Testability: Test driven designs (TDD) makes sure we write testable code. Writing automated tests has […]