#software design principles

[facingissuesonit]

12 Software Design Key Principles

12 Software Design Key Principles

If you are in software development and working as senior programmer or application architect then you should keep these software deigning principle in your mind while working on software or application development.

Why Software Design Principles?

Software Design principles are set of guidelines to handle complexity and reduce effort needed to develop a good system design. Design principles ease…

View On WordPress

[sekanet]

Dependency Inversion Control

Dependency Inversion Principle (DIP) is one of the five software design principles. What programming languages you know, you should know these five principles written below :

Open Close Principle(OCP)

Dependency Inversion Principle (DIP)

Interface Segregation Principle (ISP)

Single Responsibility Principle (SRP)

Liskov’s Substitution Principle (LSP)

In this article, i will explain Dependency Inversion Principle.

Purpose / Reason This principle’s purpose is not to provide strong correlation between high level classes and low level classes. The reason of using DIP is that changing in low level class shouldn’t affect high level class. When you need some change in low level classes, you shouldn’t need to change code in high level classes. For clarifying , let’s see a bad example and good example respectively, thus, you can understand better.

Key Principles High level classes should not depend on low level classes. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.

Implementation For this case, you build log manager 6 months ago to track user’s action. For this aim, you decided to insert log into database. But right now, your manager wanted that log must be inserted into file.

Bad Example : Here is the code that you wrote 6 months ago to track user actions.

public class LogDB { public void AddLog() { // Add log into database } } public class LogManager { LogDB log = new LogDB(); public LogManager(LogDB log) { this.log = log; } public void Log() { this.log.AddLog(); } }

Here is the new low level class you write to insert log into file. It needs to be implemented current structure.

public class LogFile { public void AddLog() { // add log into file } }

When you try to implement LogFile into current class structure. You will have to change LogManager classes. Using this bad solution, you have these problems written below :

The code statement where you used to invoke LogManager.Log() method.

You have to redone your unit testing.

It’s obvious, you are able to implementing new requirements into your current code. However, it won’t be a good solution. Because, you will need to modify all related classes to Log Business Logic.

Let’s see how you can build better using Dependency Inversion Principle

Good Example : According to this principle, the way of building class structure is to start from high level classes to  low level classes. And put abstract class or interface between high level classes and low level classes.

High Level Classes ==> Abstraction ==> Low Level Classes

//ILog is a abstraction. public interface ILog { void AddLog(); } // LogManager is a high level class public class LogManager { ILog log; public LogManager(ILog log) { this.log = log; } public void Insert() { this.log.AddLog(); } } // LogDB is a low level class public class LogDB : ILog { public void AddLog() { // insert log into database } } // LogFile is a low level class public class LogFile : ILog { public void AddLog() { //insert log into file } }

Summary

If you build your class structure in respect of DIP, you can implement new low level class such as LogFile without changing any code in your high level class ( LogManager ). Also you minimize the risk to affect old functionality. Beside that, you don’t need to rewrite your unit testing for LogManager class.

For this good example, as you see, LogManager (High Level Class) doesn’t know anything about low level classes. It knows only interface of log classes (ILog).

When you use DIP, you have more flexible. But this principle can not be applied for every class. If you have a class functionalities these are more likely to remain same, unchanged in the future, you don’t have to apply this principle.

[sekanet]

Open Closed Principle

Open Closed Principle (DIP) is one of the five software design principles. What programming languages you know, you should know these five principles written below :

Open Close Principle (OCP)

Dependency Inversion Principle (DIP)

Interface Segregation Principle (ISP)

Single Responsibility Principle (SRP)

Liskov’s Substitution Principle (LSP)

In this column i will explain Open Closed Principle.

Purpose/Reason The reason to use open closed principle is to add new features without changing existing software entities. Especially in enterprise application, due to marketing conditions, softwares need to be changed. In order to reduce time, cost and risk for implementation new features, you should consider how to expand software easily. Open closed principle is one of the five answers written above.

Key Principle Open Close Principle states software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

Implementation Suppose that, you have two different database products which are MySQL and Oracle. In order to connect right database, you built a DatabaseManager to decide that which database product is used to connect. Here is the solution which is not recommended.

Bad Example :

public class DatabaseManager { public void Connect(Database d) { if (d.DBType == 1) ConnectMySQL((MySQLDB)d); else if (d.DBType == 2) ConnectOracle((OracleDB)d); } public void ConnectMySQL(MySQLDB db) { // connect } public void ConnectOracle(OracleDB db) { // connect } } public class Database { public int DBType; } public class MySQLDB : Database { public MySQLDB() { base.DBType = 1; } } public class OracleDB : Database { public OracleDB() { base.DBType = 2; } }

For instance, one day ago, your manager said that we need to support Microsoft SQL database. You need to modify almost all classes. But if you cared open closed principle before, you wouldn’t need to change all classes. Let’s see good example about how it should have built.

Good Example :

public abstract class Database { public abstract void Connect(); } public class DatabaseManager { private Database db; public DatabaseManager(Database db) { this.db = db; } public void Connect() { this.db.Connect(); } } public class MySQLDatabase : Database { public void Connect() { //connect MySQL } } public class OracleDatabase : Database { public void Connect() { //connect Oracle } }

If you had built your database manager like above, you wouldn’t have needed to modify all classes. The only thing you should do is add new MicrosoftSQL class into current situation.

public class MicrosoftSQL : Database { public void Connect() { // connect Microsoft SQL } }

Summary : As you see, this principle should be applied software application which is most likely to be modified or added new features into current situation. Otherwise, your software application has more abstractions between classes and this occurs more complication in your code.

[sekanet]

Single Responsibility Principle

Single Responsibility Principle (SRP) is one of the five software design principles. What programming languages you know, you should know these five principles written below:

Open Close Principle (OCP)

Dependency Inversion Principle (DIP)

Interface Segregation Principle (ISP)

Single Responsibility Principle (SRP)

Liskov’s Substitution Principle (LSP)

In this article, i will explain Single Responsibility Principle.

Purpose / Reason Each class or module should be responsible only one task. For instance, if you have one Employee class to update Employee information, calculate salary and tax. You have more than one reason to modify Employee class. I mean, when you need to change algorithm of calculating salary or tax, you have to change same class. In our purpose, you have only one reason to change class or module.

Key Principle There should  never be more than one reason for a class to change.

Implementation For instance, you have one Employee class which is responsible for calculation salary and tax, modify Employee information and sending hours reports to managers.

Bad Example :

public interface IEmployeeManager { void SendHourReports(); Money CalculateSalary(); double CalculateTax(); void UpdateEmployee(Employee employee); void CreateEmployee(Employee employee); }

As you see Employee class has more than one task to perform. Instead of designing Employee class like that, it’s better to separate similar functionalities into three classes. Look at good example.

Good Example :

public interface ISalary { Money CalculateSalary(); double CalculateTax(); } public interface IReport { void SendHourReports(); } public interface IEmployeeDatabase { void UpdateEmployee(Employee employee); void CreateEmployee(Employee employee); }

I divide Employee class into three different classes which are ISalary, IReport, IEmployeeDatabase . Because, Employee class actually has three main functionalities :

Salary functionalities

Employee reports

Database behaviors

Summary If a class has more than one responsibility, then there will be more than one reason to modify class or module. Preventing this, you need to be able to separate classes or modules into more than one classes or module. Otherwise responsibilities become coupled and change is a manifest through a change in a responsibility among the classes or modules.

[sekanet]

Liskov’s Substitution Principle

Liskov’s Substitution Principle (LSP) is one of the five software design principles. What programming languages you know, you should know these five principles written below :

Open Close Principle (OCP)

Dependency Inversion Principle (DIP)

Interface Segregation Principle (ISP)

Single Responsibility Principle (SRP)

Liskov’s Substitution Principle (LSP)

In this article, i will explain Liskov’s Substitution Principle.

LSP is first mentioned by Barbara Liskov in 1987 conference keynote. This principle is about relation between subclasses and base classes. We can say strong behavioral subtyping. When you read the principle, you will find something similar with Open Close Principle.

If function in base class is modified because of that new derivative of the base class is created. You shouldn’t need to change function which is placed in base class.

Key Principle Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

Violation of Liskov’s Substitution Principle I will write a best known example; Rectangle and Square. You can think of that Square is a kind of  special rectangle. Then the square can be inherited from Rectangle class.

public class Rectangle { protected int _Width; protected int _Height; public void SetWidth(int width) { _Width = width; } public void SetHeight(int height) { _Height = height; } public int CalculateArea() { return _Height * _Width; } } public class Square : Rectangle { public void SetWidth(int width) { _Width = width; _Height = width; } public void SetHeight(int height) { _Height = height; _Width = height; } } public class Program { public static void Main() { Rectangle r = GetNewRectangle(); r.SetHeight(5); r.SetWidth(10); Console.WriteLine(r.CalculateArea()); // Output : 50 instead of 25 } private static Rectangle GetNewRectangle() { return new Square(); } }

The square class which is derived from Rectangle class assumes that width is equal with the height. When Square is used in context where Rectangle class is expected, unexpected behavior may occur, because the dimensions of the square can not be set independently.

For further information you can download pdf file written by Robert C.Martin.