
## Table of Contents

1. [Introduction](#introduction)
2. [DRY Design Principle](#dry-design-principle)
3. [SoC Design Principle](#soc-design-principle)
4. [DIE Design Principle](#die-design-principle)
5. [KISS Design Principle](#kiss-design-principle)
6. [YAGNI Design Principle](#yagni-design-principle)
7. [TDA Design Principle](#tda-design-principle)
8. [Conclusion](#conclusion)

## Introduction

This blog covers some of the most widely used design principles in software development. These principles help developers write code that is maintainable, testable, and scalable. Whether you are an experienced developer or just starting out, understanding these principles will improve the quality of your code.

The following design principles are covered in this post:

- **DRY** — Don't Repeat Yourself
- **SoC** — Separation of Concern
- **DIE** — Duplicate Is Evil
- **KISS** — Keep It Simple, Stupid
- **YAGNI** — You Ain't Gonna Need It
- **TDA** — Tell Don't Ask

## DRY Design Principle

**DRY** stands for **Don't Repeat Yourself**. This principle states that you should avoid repeating the same code in multiple places. If you find functions or code being used in multiple locations, it is better to move them to a common place. Otherwise, you will have to maintain the same code in two different spots.

This principle applies to any area of software development — whether you are structuring front-end SCSS files, creating JavaScript functions, or developing back-end SQL queries. Below is an example using Node.js with TypeScript.

### Example: Extracting Shared Constants

Imagine you are developing Page A and create a class that needs a readonly string for a blog detail URL, so you define it in Page A. Later, you notice that Page B also needs the same URL. Based on the DRY principle, you should move it to a common location that both classes can access — perhaps a constants file.

```typescript
// page A
private readonly BLOG_DETAIL: string = "/blog/post/";

// page B
private readonly BLOG_DETAIL: string = "/blog/post/";
```

### Example: SCSS Variables

The DRY principle also applies when creating SCSS files. If you declare a variable for your primary color in one SCSS file and that variable is needed in other SCSS files, it is better to declare it in a global variables file that all SCSS files can import.

### Example: Avoiding Duplicate Functions

I have seen cases where a developer creates one file for `localStorage` operations in JavaScript and another nearly identical file for `sessionStorage` operations. The only difference is `localStorage` versus `sessionStorage`, but the code ends up duplicated. This is a missed opportunity to apply the DRY principle.

The DRY principle may seem simple, but consistently keeping it in mind can lead to significant improvements. For instance, how do you share the same UI component across two different systems — one for a public-facing UI and another for an internal UI? Approaches like Micro Front-End architecture can help solve this type of problem while staying true to the DRY principle.

## SoC Design Principle

**SoC** stands for **Separation of Concern**. This principle is about dividing a software program into distinct sections or units, where each section has its own purpose. Following this principle leads to better maintainability, easier code refactoring, and improved testability.

Imagine if one class had to handle everything — it would be very difficult to understand, maintain, and debug.

### Example: Express.js Route

Let's look at the following code. This Express.js route takes a query string key, uses that value to query MongoDB for localization data, and then binds the data to a view called `local-view`. The code is not too long, follows the DRY principle, and appears to work. So what's wrong?

```javascript
const mongoose = require('mongoose');
const Schema = mongoose.Schema;

let local = new Schema({
        key: {
            type: String
        },
        value: {
            type: String
        },
        culture: {
            type: String
        }
});

async getLocalText(key) {
        if (!key) {
            return '';
        }

        try {
            return await localModel.findOne({key: key});

        } catch (error) {
            console.error(error);
            return '';
        }
    }

exports.all = async function(req, res) {

    const model = await getLocalText(req.params.key);

    res.render('local-view', model);

}
```

This code can be broken down into the following sections, each with its own responsibility:

- **Database Model** — Defines the MongoDB schema
- **Database Repository** — Repository function to access the MongoDB database
- **View Model** — Model to bind to the view
- **Controller** — Checks the request query, gets the model, and binds it to the view

### Why Separation Matters

What happens if you don't separate concerns? Your code becomes a "God class" — a class that does everything. God classes are hard to maintain, hard to add features to, hard to debug, and hard to test.

By creating a separate file for the database model, you can add validation and define the schema in one place that can be shared with other repositories. By creating a separate database repository file, that file only needs to handle database access and connections. The same goes for the view model and controller — each has its own focused purpose.

## DIE Design Principle

**DIE** stands for **Duplicate Is Evil**. This principle is similar to DRY but emphasizes that duplication is inherently harmful to code quality. When writing new code, you should actively work to eliminate duplicates.

However, there may be cases where you choose not to refactor duplicates, especially when other factors take priority.

### When to Refactor Duplicates

If you join a team and notice many duplicate constants or functions, should you change them? The answer depends on several factors:

- **Your error rate** — How likely are you to introduce bugs during refactoring?
- **QA automation** — Do you have a trusted automated test suite to catch regressions?
- **Team trust** — Does your team trust you to make refactoring changes safely?

If you are new to a company and immediately send a PR to refactor everything, it may go well if nothing breaks. But if you accidentally break something, it could take time to rebuild trust. Timing and context matter when applying this principle.

## KISS Design Principle

**KISS** stands for **Keep It Simple, Stupid**. This principle means keeping your software design as simple as possible and avoiding unnecessary complexity. While this sounds straightforward, writing simple code often takes more effort than writing complex code. You need to review your code repeatedly to find simpler approaches, reduce unnecessary logic, and test again.

### Example: Two Approaches to Bug Fixing

Consider a scenario where you need to fix a bug that seems complex. Developer A goes in and fixes the issue but creates several new functions in the process. Developer B fixes the same issue with just one line of code. Which approach is better?

Developer B likely spent more time understanding the root cause of the issue before writing any code. This brings us to a few practices that help maintain simplicity:

### Tips for Keeping It Simple

1. **Find the real problem first** — Invest time in understanding the issue before writing code. The reason Developer B needed only one line might be that they spent more time understanding the problem.

2. **Keep files small** — If a file is growing large, it likely contains mixed responsibilities. Breaking it into smaller, focused pieces helps maintain simplicity.

3. **Do code reviews** — Collaborate with your coworkers to review and simplify code. Pair programming and code reviews are great ways to write simpler, cleaner code.

## YAGNI Design Principle

**YAGNI** stands for **You Ain't Gonna Need It**. This principle is related to KISS and advises against adding functionality until it is actually needed. When designing software, keep it simple and avoid implementing features based on speculation about future requirements. If you don't need it now, don't build it now.

Adding unnecessary features increases complexity, creates more code to maintain, and can lead to bugs in features that may never be used. Focus on the current requirements and add new functionality only when there is a clear need for it.

## TDA Design Principle

**TDA** stands for **Tell, Don't Ask**. This principle suggests that an object should be responsible for its own data and behavior, rather than requiring the caller to query the object's state and perform calculations externally.

### Example: Before Applying TDA

In the following example, the caller creates a `LineItem` object and manually calculates the total:

```typescript
class LineItem {
  ItemPrice: number;
  Quantity: number;
  Total: number;
}

const myItem = new LineItem();
myItem.ItemPrice = 30;
myItem.Quantity = 2;
myItem.Total = 2 * 30;
```

### Example: After Applying TDA

Now, we refactor the code so the `LineItem` class calculates the total internally. The caller simply tells the object the price and quantity, and the object provides the total:

```typescript
class LineItem {
  constructor(itemPrice: number, quantity: number) {}
  get Total(): number {
    return this.itemPrice * this.quantity;
  }
}

const myItem = new LineItem(30, 2);
console.info(myItem.Total);
```

As a `LineItem` class grows with more logic and properties, it might make sense to separate its business logic and data properties into different files, continuing to apply other principles like SoC.

## Conclusion

Design principles are essential tools for writing high-quality software. Here is a summary of the six principles covered in this post:

| Principle | Full Name               | Key Takeaway                                       |
| --------- | ----------------------- | -------------------------------------------------- |
| **DRY**   | Don't Repeat Yourself   | Move shared code to a common location              |
| **SoC**   | Separation of Concern   | Each module should have one focused responsibility |
| **DIE**   | Duplicate Is Evil       | Actively eliminate code duplication                |
| **KISS**  | Keep It Simple, Stupid  | Write the simplest code that solves the problem    |
| **YAGNI** | You Ain't Gonna Need It | Don't build features you don't need yet            |
| **TDA**   | Tell, Don't Ask         | Objects should manage their own data and behavior  |

These principles are guidelines, not rigid rules. Apply them thoughtfully based on your project's context, and they will help you write more maintainable, testable, and scalable code.


A guide to widely used design principles in software development, including DRY, SoC, DIE, KISS, YAGNI, and TDA, with practical example code.

Design Principles in Software Development Part 1


## Table of Contents

- [SOLID Design Principle](#solid-design-principle)
- [Single Responsibility Principle (SRP)](#single-responsibility-principle)
- [Open/Closed Principle (OCP)](#openclosed-principle)
- [Liskov Substitution Principle (LSP)](#liskov-substitution-principle)
- [Interface Segregation Principle (ISP)](#interface-segregation-principle)
- [Dependency Inversion Principle (DIP)](#dependency-inversion-principle)
- [Conclusion](#conclusion)

## Introduction

This blog talks about design principles in software development. It will
focus on the SOLID design principles and provide a few example codes. This is
Part 2 of the Design Principles series, covering the five SOLID principles
that help developers build maintainable and scalable software.

## SOLID Design Principle

SOLID design principle is an acronym for the following five design principles.
These design principles will help you build maintainable, testable, flexible,
and understandable software applications.

### Single Responsibility Principle

> "There should never be more than one reason for a class to change. In other
> words, every class should have only one responsibility."

SRP, the Single Responsibility Principle, basically states that one class
should only have one purpose or responsibility. This is similar to SoC
(Separation of Concerns), with a slight difference. If we keep this principle
in mind, it will be very helpful for software design in any area. Let's look
at the following sample code.

Assume you start to use Express.js to write a blog system. The back-end is
MongoDB and you're using Node.js Mongoose as an ORM to access the MongoDB
database. The following is an Express.js route that takes an ID from the page,
then performs a query to the MongoDB database and returns the result to the UI.
The UI code is not shown here but will take the post data and display it on the
page.

This is not a lot of code, but it has several areas of concern. You see the
code to define the MongoDB schema, the setup for the index, a query to the
Posts collection by ID, and Express.js code to call the data for the UI. Based
on the Single Responsibility Principle, we should divide all these different
areas of code into separate files. One of the reasons is maintainability. I
know the following code is just a few lines, but in reality one page's code
could be hundreds or thousands of lines. It probably calls many different
services, validation, and filters to get the data. That's why when you first
write the code, it is better to keep this principle in mind and break the code
into different files.

Let's see how we change this code.

```
const mongoose = require('mongoose');
const Schema = mongoose.Schema;

const PostsSchema = new Schema({
   slug: String,
   title: String,
   state: String,
   content: String,
   createdDate: Date,
   tags: Array
});

PostsSchema.index({
   title: 'text',
   content: 'text'
});

async findById(id: any) {
    return this.PostsSchema.findById(id);
}

exports.index = async function(req, res) {

    const model = await findById(req.params.id);

    res.render('my-page-by-id', model);

}
```

posts.schema.ts

First, I think we can move the Posts MongoDB schema to a separate file. This
will be the file you update whenever you change your collection's MongoDB
schema or add some default index.

```
const mongoose = require('mongoose');
const Schema = mongoose.Schema;

export const PostsSchema = new Schema({
   slug: String,
   title: String,
   state: String,
   content: String,
   createdDate: Date,
   tags: Array
});

PostsSchema.index({
   title: 'text',
   content: 'text'
});
```

Posts.dataService.ts

For the MongoDB database access part, create another data repository file
as PostsDataService. This file will be responsible for accessing MongoDB
and returning the result.

```
const {PostsSchema} from './Posts.schema.ts';
export class PostsDataService {

   async findById(id: any) {
        return this.PostsSchema.findById(id);
   }
}
```

index.ts

Now, the last file is the Express.js route — the controller page that handles
page requests, gets data, and returns it to the view. Ideally, there should be
another business logic layer in between, but after removing the MongoDB schema
and data access, this file now has much less responsibility. It simply
validates the request and returns the data to the UI.

```
const {PostsDataService} from './Posts.DataService.ts';

exports.index = async function(req, res) {

   if (!req.params.id) {
       // go to 404 page
      return GoTo404Page();
   }

    const model = await new PostsDataService().findById(req.params.id);

    res.render('my-page-by-id', model);

}
```

### Open/Closed Principle

> "Software entities should be open for extension, but closed for
> modification."

The Open/Closed Principle states that when you create a class, you should hide
or close its implementation from the outside, but it should be open for others
to extend its functions. Let's take a look at the previous Posts DataService
class, this time with a few more functions added.

You'll also notice that you need to create comment, users, and image MongoDB
collections, and they all have similar functions as follows. You want them all
to use the same implementation to access the MongoDB database, but you also
want to extend the functions for each collection.

```
const {PostsSchema} from './Posts.schema.ts';
export class PostsDataService {

   async findById(id: any) {
        return this.PostsSchema.findById(id);
   }

    async countAllQuery(condition:any): Promise {
        return await this.PostsSchema.count(condition);
    }

    async deleteOne(model: any): Promise {
        return await this.PostsSchema.deleteOne(model);
    }

    async update(filter: any, doc: any) {
        return await this.PostsSchema.updateOne(filter, doc);
    }}
```

Let's check how we can achieve this.

IDataServiceBase.ts

First, create an interface which has all the functions you think all the other
collections can use.

```
export interface IDataServiceBase {

    create(model: Dto): Promise;
    findAll(sort?: object, filter?: object, limit?: number, skip?: number): Promise;
    findAllByModel(model: Collection): Promise;
    findOneById(id: any): Promise;
    findOne(model: Collection): Promise;
    countAll(): Promise;
    count(model: Collection): Promise;
    update(filter: Collection, doc: Collection);
    deleteOne(model: Collection): Promise;
}
```

DataServiceBase.ts

Next, we'll create a base data class to implement the interface. All the
detailed implementation goes inside this DataServiceBase class.

```
import { Document } from 'mongoose';
export abstract class DataServiceBase
implements InterfaceServiceBase {
    create(model: TModel): Promise {
        throw new Error("Method not implemented.");
    }
    findAll(sort?: object, filter?: object, limit?: number, skip?: number): Promise {
        throw new Error("Method not implemented.");
    }
    findAllByModel(model: TDocument): Promise {
        throw new Error("Method not implemented.");
    }
    findOneById(id: any): Promise {
        throw new Error("Method not implemented.");
    }
    findOne(model: TDocument): Promise {
        throw new Error("Method not implemented.");
    }
    countAll(): Promise {
        throw new Error("Method not implemented.");
    }
    count(model: TDocument): Promise {
        throw new Error("Method not implemented.");
    }
    update(filter: TDocument, doc: TDocument) {
        throw new Error("Method not implemented.");
    }
    deleteOne(model: TDocument): Promise {
        throw new Error("Method not implemented.");
    }
}
```

### Liskov Substitution Principle

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

The Liskov Substitution Principle (LSP) means that objects of a subclass
should be able to replace objects of the parent class without breaking the
application. In other words, if class B is a subclass of class A, you should
be able to pass an instance of B anywhere an instance of A is expected, and
everything should still work correctly. This encourages designing class
hierarchies where derived classes truly extend the behavior of the base class
rather than altering it in unexpected ways. Violating LSP often leads to
fragile code that relies on type-checking or conditional logic to handle
different subclasses.

### Interface Segregation Principle

> "Many client-specific interfaces are better than one general-purpose
> interface."

ISP, the Interface Segregation Principle, is about making interfaces as small
as possible instead of having one big interface doing everything. If you use a
single large interface, you might end up with classes that implement methods
they don't actually need, leaving some declared but doing nothing.

Let's take a look at the following example. It is a data repository interface
which contains basic CRUD operations. Now, let's say you want to implement
some operations that only involve writing or reading. Would you create a class
that implements the full IDataServiceBase?

```
export interface IDataServiceBase {

    create(model: Dto): Promise;
    findAll(sort?: object, filter?: object, limit?: number, skip?: number): Promise;
    findAllByModel(model: Collection): Promise;
    findOneById(id: any): Promise;
    findOne(model: Collection): Promise;
    countAll(): Promise;
    count(model: Collection): Promise;
    update(filter: Collection, doc: Collection);
    deleteOne(model: Collection): Promise;
}
```

For that scenario, you should create interfaces only for what is needed. So I
separated IDataServiceBase into the following two interfaces. You can use each
interface to implement specific details in a separate class file.

```
export interface IWriteDataServiceBase {

    create(model: Dto): Promise;
    update(filter: Collection, doc: Collection);
    deleteOne(model: Collection): Promise;

}

export interface IReadDataServiceBase {

    findAll(sort?: object, filter?: object, limit?: number, skip?: number): Promise;
    findAllByModel(model: Collection): Promise;
    findOneById(id: any): Promise;
    findOne(model: Collection): Promise;
    countAll(): Promise;
    count(model: Collection): Promise;
}
```

You can also combine the two interfaces together if needed.

```
export interface IDataServiceBase
extends IReadDataServiceBase, IReadDataServiceBase {

}
```

### Dependency Inversion Principle

> "Depend upon abstractions, not concretions."

The Dependency Inversion Principle (DIP) states that high-level modules should
not depend on low-level modules. Both should depend on abstractions.
Additionally, abstractions should not depend on details; details should depend
on abstractions. In practice, this means that instead of a class directly
creating or referencing a concrete implementation, it should depend on an
interface or abstract class. This makes it easy to swap out implementations
without modifying the high-level code. For example, in the code we wrote
earlier, the Express.js controller depends on the PostsDataService class
directly. With DIP, you would have the controller depend on an
IDataServiceBase interface instead, allowing you to inject any implementation
at runtime.

## Conclusion

In this post, we covered the five SOLID design principles: Single
Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and
Dependency Inversion. Each principle helps you write cleaner, more
maintainable, and more flexible code. By applying SRP you keep classes
focused, OCP lets you extend behavior without modifying existing code, LSP
ensures subclasses are truly interchangeable, ISP keeps interfaces lean, and
DIP decouples high-level logic from low-level details. Keeping these
principles in mind from the start will save you significant effort as your
codebase grows.


This blog talks about design principles in software development. It includes SOLID and a few more widely used design principles, with example code.

Software Design

Design Principles in Software Development Part 1

Design Principles in Software Development Part 2