Another little snippet on code standards to help make code better!
Coding or Extensibility of one of the goals of the SOLID development pillars:
Single Responsibility Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Injection Principle
These principles are designed to lead to code that is easily extendable, easily tested and localises changes to one place in the code-base.
What is code extensibility?
Simply, the ability to take an existing piece of logic and use it to solve a problem without copy-pasting (and creating duplicate code, with its associated maintenance overhead) and without breaking things the code already does.
Consider a function that adds up two numbers. We may want to extend it so it can cope with adding negative numbers also, but we don't want to break it so it no longer adds positive numbers and we don't want to write another 'Add' function.
Single Responsibility Principle
To keep code extensible, testable and readable (lean) we should consider the Single Responsibility Principle. A piece of code should do one thing and do that one thing well.
A function that adds up should do adding, it shouldn't also do multiplication.
A class that reads customers from a database shouldn't also write out HTTP cookies.
A namespace for Validation shouldn't also handle CRM/Sitecore integration.
SRP keeps code lean, focused and more easily understandable.
Code should be open for extension and closed for modification. This is a principle focused on adding new features without breaking what's there.
If a new use-case appears that involves changes to code, eg maybe business customers get a different discount process than home customers, then we should leave the existing logic alone.
This will prevent our breaking things for existing customers and processes.
We can then extend the existing logic using normal Object-Oriented inheritance, functional-style Composition or amendments to our IoC container to build this new logic.
For example, if we have a PurchaseDiscount class we might inherit from it to create BusinessPurchaseDiscount and HomePurchaseDiscount. That way, anywhere in the code still using PurchaseDiscount will be unaffected and the system will not break. It keeps regression errors to a minimum.
We can then, at our leisure, update the code to use the new extended code to implement the new behaviour.
Liskov Substitution Principle
This rule states that wherever a parent class is used, an inheriting class should be able to be substituted without breaking the system.
Supposing I have a class that calculates BasketTotal. It takes an array of items and calculates their prices. Suppose then that we inherit from it to create BusinessBasketTotal that calculates prices and applies a business discount.
Anywhere I use BasketTotal, I should in theory be able to substitute BusinessBasketTotal. However, if BasketTotal has a property float total and BusinessBasketTotal implements its own BusinessTotal and overrides the total property from its parent and always returns -1 instead of the total, then this would break the Liskov Substitution principle.
public class BasketTotal
{
 public float Total { get; private set; }
 public virtual void Sum(BasketItem[] items)
 {
  Total = 0f;
  foreach(var item in items)
  {
   Total += item.Price;
  }
 }
}
public class BusinessBasketTotal : BasketTotal
{
 // Don't need this because it's a business basket?
 public override float Total => -1f;
 // Return a business basket total instead
 public float BusinessTotal {get; private set; }
 public virtual void Sum(BasketItem[] items)
 {
  BusinessTotal = 0f;
  foreach(var item in items)
  {
   BusinessTotal += item.BusinessPrice;
  }
 }
}
It would not be possible to use BusinessBasketTotal in place of BasketTotal because the former breaks the design of the latter by returning a -1 for price.
This is a bad idea because it's likely to lead to weird behaviour in the system: .Net will happily allow BusinessBasketTotal in place of BasketTotal, but that will break our logic. What should be done instead is to have BusinessBasketTotal respect the interface set out in BasketTotal and set the Total property correctly.
Interface Segregation Principle
An important part of being able to compose objects together to solve bigger problems is being able to refer to them by interface. Interfaces offer advantages to the traditional inheritance model of OO software, behaving more like interchangeable Lego bricks.
If you want a class to do something different in place of another, write a new class that implements the same interface and use it instead.
This leaves an important design consideration when planning interfaces: keep them focused and not too big. It closely relates to the Single Responsibility Principle.
Let's say I have a ICustomerSaver, an interface that has the sole purpose of persisting a customer object to storage somewhere. If I write a class to implement that interface, I'd expect to write methods like Save.
Supposing I implement that interface in my class, and I am asked to write methods for Serialize, GetFromDB or CheckOrders. What has happened is that this interface does not follow the good design principle of Interface Segregation.
I implemented the ICustomerSaver interface because I wanted a class that could save Customer objects in a new way- I should not be implementing serialisation, database access or order management methods. They should be separate interfaces (eg ISerializable, IDbAccess and IOrderManager) that I choose to implement if I need them.
Dependency Injection Principle
The final step for extensible, readable and testable code is the Dependency Injection Principle. This means that if I have one class that depends on another for its logic, then that dependency should be passed in (ie injected).
public class CustomerManager
{
 public void Save(Customer customer)
 {
  var database = new CustomerDatabase();
  database.Persist(customer);
 }
}
Consider the class above if we make changes to the CustomerDatabase object. Perhaps we add some constructor parameters, or want to replace it with a different class. We've now made a lot of work for ourselves if we want to make such changes because we'll need to change every place we use CustomerDatabase.
Suppose, instead, we injected it as a dependency:
public class CustomerManager
{
 public void Save(Customer customer, CustomerDatabase database)
 {
  database.Persist(customer);
 }
}
That's better: now it is the responsibility of whatever uses CustomerManager to supply the CustomerDatabase object as an argument. Presumably that will be down much farther up the stack, so there will be fewer places to change it if CustomerDatabase changes.
However, we can do better. CustomerManager is likely to have several methods, for example Save and Load. We could then pass CustomerDatabase as a constructor argument rather than as a method argument:
public class CustomerManager
{
 private CustomerDatabase database;
 public CustomerManager(CustomerDatabase database)
 {
  this.database = database;
 }
 public void Save(Customer customer)
 {
  database.Persist(customer);
 }
 public Customer Load(Guid customerId)
 {
  return database.Find(customerId);
 }
}
So we have now reduced duplication and followed better Single Responsibility: the constructor gathers dependencies and then individual methods use them to solve specific problems.
However, we still have the issue of changes to CustomerDatabase: supposing we follow the Open for Extension Principle and create a new database layer that we now want to use here? We must manually find and replace all CustomerDatabase instances with our new PersonDatabase object.
We can solve this by using Interfaces for our dependency injection. Consider:
public interface ICustomerPersistence
{
 Customer Find(Guid customerId);
 void Save(Customer customer);
}
public class CustomerManager
{
 private ICustomerPersistence database;
 public CustomerManager(ICustomerPersistence database)
 {
  this.database = database;
 }
 public void Save(Customer customer)
 {
  database.Persist(customer);
 }
 public Customer Load(Guid customerId)
 {
  return database.Find(customerId);
 }
}
Now CustomerManager will accept, without any changes whatsoever, any ICustomerPersistence implementer we choose to pass to it.
Using an IoC container (such as Unity, StructureMap, Ninject, AutoFaq or many others) we can even automate this in code, eg:
container.Register<ICustomerPersistence, PersonDatabase>();
container.Register<CustomerManager, CustomerManager>();
// ...
var customerManager = container.Get<CustomerManager>();
// This will now work with everything done for us:
customerManager.Load(customerId);
The IoC container will create a CustomerManager and, as long as it knows what to use for a ICustomerPersistence it will handle running the constructor for us. Swapping out to a different database is now a simple matter of writing a new class that implements ICustomerPersistence and changing that one line in the container registry!
annaxmalina
stormborns
turnnoffyourmind
pixelskylines
discoholicmusic
areudirty
dailybridgerton
blakekathryn