Your Web News in One Place

Help Webnuz

Referal links:

Sign up for GreenGeeks web hosting
December 20, 2021 04:59 pm GMT

Design Principles

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

There's essentially no agreement on how to do software design or even what a good piece of software looks like.

What are Software Design Principles?

Design principles are core abstract principles that we are supposed to follow while designing software. They can be applied in any language, on any platform regardless of the state as long as we are within the permissible conditions.

Design principles provide high-level guidelines to design better software applications.

Design principles arefundamental pieces of advice for you to make easy-to-use, pleasurable designs. You apply them when you select, create and organize elements and features in your work. Design principles represent the accumulated wisdom of researchers and practitioners in design and related fields.

These are the key software design principles but most important isSOLID(top 5) which use in all software designing.

  1. Single Responsibility Principle:One class should do one thing and do it well.
  2. Open Close Design Principle:Open for extension, close for modification.
  3. Liskov Substitution Principle:Subtype must be a substitute for supertype.
  4. Interface Segregation Principle:avoid monolithic interface, reduce pain on client-side.
  5. Dependency Inversion Principle:Dont ask lets the framework give it to you.
  6. DRY(Dont Repeat Yourself):avoid duplication in code.
  7. KISS (Keep it Simple, Stupid):Keep your code simple, small and understandable.
  8. Encapsulate what changes:hides implementation detail helps in maintenance.
  9. Favor Composition over inheritance:Code reuse without the cost of inflexibility.
  10. Programming for an interface:Helps in maintenance, improves flexibility.
  11. Delegation Principle:Dont do all things by yourself. Let's Delegate it.
  12. YAGNI ( You Aint Gonna Need It):If its not in the concept, its not in the code

All these software design principles are mainly based on four factors:

  1. Problem Partitioning:Divide the problem into manageable pieces.
  2. Modularity:Divide software into well-defined separate modules.
  3. Abstraction:Provide components as interface and hide the internal implementation.
  4. Strategy Of Design:Top-Down/Bottom-Up Approach

This further section will discuss these principles in detail.

Few words about Abstraction

Abstraction is the Key to Simple Code

The right abstractions can make code more readable, adaptable, and maintainable by hiding details that are unimportant for the current context, and reducing the amount of code required to do the same work often by orders of magnitude.

Simplicity is about subtracting the obvious and adding the meaningful.
John Maeda:The Laws of Simplicity

Abstraction is not a 1-way street. Its really formed by two complementary concepts:

  • Generalization Removing the repeated parts(the obvious)and hiding them behind an abstraction.
  • Specialization Applying the abstraction for a particular use-case, adding just what needs to be different(the meaningful).

Junior developersthink they have to write a lot of code to produce a lot of value.

Senior developersunderstand the value of the code that nobody needed to write.

The right abstractions are powerful levers that can impact productivity dramatically. Abstraction is not a dirty word. Modules, functions, variables, classes all of these are forms of abstraction and the entire reason any of them exist is to make abstraction and composition of abstractionseasier.

You cant build complex software without abstractions. Even assembly language uses abstractions names for instructions, variables for memory addresses, code points to jump to for subroutines (like function calls), etc. Modern software is a layer cake of useful abstractions, and those layers give you leverage.

SOLID - Most Common Design Principle

SOLID is combination of five basic designing principles.

Single Responsibility Principle (SRP)

A class should have only one reason to change. If there is any other reason create another class.

This principle is completely based onCouplingandCohesion. This principle states that In your software design classes should be in such a way that each class should have a single purpose/responsibility/functionality.

While designing software if you put more than one functionality in a single class then increasecouplingbetween functionalities. If change is required in one functionality there are chances to break other functionality and required more testing to avoid such surprises in a production environment.

Benefits:

  • This principle makes your software easier to implement and prevents unexpected side-effects of future changes.
  • Your class will change only if anything will change in respected responsibility.
  • Need to update dependencies and compile when some respected dependencies change.
  • Reduce coupling between software and components.

The Single Responsibility Principle (SRP) also provides other benefits with classes, components, and microservices with single responsibility make your code easier to explain, understand, implement. It also improves development speed and easier to track bugs.

Open/Closed Principle (OCP)

Software entities like classes, modules, and functions should be open for extension (new functionality) and closed for modification.

This principle is based on inheritanceorcompositiondesign patterns like Strategy Design patterns. As per this principle:

  • Openmeans, Your code should be able to extend existing code in order to introduce new functionality.
  • Closemeans, Once your module has been developed and tested, the code will change only when correct bugs.

Benefits:

The main benefit of Open/Close Design principle is that already developed and tested code will not be modified and dont break.

Liskov Substitution Principle (LSP)

Driven type must be completely substitute of their base type.

Liscov Substitution Principleis closely related to theSingle Responsibility PrincipleandInterface Segregation Principle.

This principle states that Subclasses or derived classes should be completely substituted of superclass. The Subclass should enhance the functionality but not reduce it.

In other words, functions that use pointers and reference of base classes must be able to use objects derived classes without knowing it.

Benefits:

  • If this principle violates then so much extra conditional code of type checking and duplicate code need to write throughout the application that can cause bugs when the application grows.
  • In methods or functions which use the superclass type must work with the object of subclass without any issue.

Interface Segregation Principle (ISP)

Clients should not be forced to depend on methods in interfaces that they dont use.

This principle states that a client should not implement an interface if it doesnt use that. An interface should belong to clients , not to library or hierarchy and keep only those methods as required for client.

Benefits:

  • If you violate this principle and add some more methods in interface that are not used with client then if you change any thing in interface definitely some functionality of client will break.

Dependency Inversion Principle (DIP)

High level module should not depend on low level module , both should depend on abstractions. Abstraction should not depend on detail. detail should depend on abstraction.

This principle provideloose couplingbetween the dependencies of modules and classes.

The Dependency Inversion Principle states that:

  1. High level modules should not depend on low level modules directly, both should depend on abstractions.
  2. This abstraction should not depend on details, details should depend on abstractions.

Benefits:

  • If you violate this principle your code will be tightly coupled because every high level module is directly referencing to lower level modules.
  • Makes testing easy by injecting the mock objects with out modification on existing functionality.

DRY (Dont Repeat Yourself)

Avoid duplication of code.

This principle states that dont write duplicate code. If you have same code on multiple places then consider making a separate method. or If you are using any hard code value more than one time make this value aspublic static finalconstant.

This principle states that each small pieces of knowledge (code) may only occur exactly once in the entire system. This helps us to write scalable, maintainable and reusable code.

Benefits:

  1. The main benefit of DRY principle is maintenance of system.
  2. This helps to design a system scalable, maintainable and reusable.
  3. Common functionality or utility methods will on one place.

KISS (Keep it simple, Stupid!)

Keep it short, simple and Understandable.

This principle states that always try to keep your code in small pieces, simple and avoid unnecessary complexity.

Benefits:

  • KISS principle helps to write easily maintainable code.

DRYandKISSprinciples are almost similar because they focus on a small piece of code but the difference is KISS principle more focused on simplicity and avoiding complexity.

YAGNI (You ain't gonna need it)

If its not in the concept, Not in the code.

This principle states that always implement things when you actually need them never implement things before you need them.

Benefits:

  • If we violate this principle and write unnecessary code with perception like may required in future then unnecessarily have to take care while maintenance or some change happen.

Encapsulate what changes

Hidden implementation detail helps in maintenance.

This principle states that encapsulate the code you expect or suspect to be changed in future. By default make your variables and methods private and increase access step by step like from private to protected not directly public.

Benefits:

  • Its easy to test and maintain proper encapsulated code.

Favor Composition Over Inheritance

Code reuse without the cost of inflexibility.

In OOPS there are two ways to reuse the code, Inheritance and composition, both the ways have own advantage and disadvantage.

This principle states that, If possible always prefer composition over inheritance because composition are lot more flexible than inheritance.

Benefits:

  • Composition allows changing the behavior of a class at runtime by setting properties during runtime and by using interfaces to compose a class by runtime polymorphism provides flexibility to use better implementation any time.

Programming for Interface

This principle states that we should always program for an interface, not for implementation. It makes code flexible with any implementation of the interface.

In other words, We should always use interface type in variable, methods arguments, and return type of methods like Superclass type to object instead of the subclass.

Benefits:

  • It provides flexibility to maintenance code and changes implementation.

Delegation Principle

Dont do all things by yourself, Lets delegate it

This principle states that dont all things in yourself, we should write logic to delegate it to respective class.

Benefits:

  • No duplication of code.
  • Pretty easy to modify behavior.

Sources:


Original Link: https://dev.to/antsitvlad/design-principles-38dg

Share this article:    Share on Facebook
View Full Article

Dev To

An online community for sharing and discovering great ideas, having debates, and making friends

More About this Source Visit Dev To