Practical Insights On SOLID DRY KISS Explained In `Noob Vs Pro` Analogy
Tags: programming, coding, beginners, opensource
Published: 2023-07-11 15:18:24

Hello, fellow developers! 

Today, we're diving deep into the world of SOLID, DRY, and KISS - three magical acronyms that can level up your coding skills. Buckle up, and let's get started!

---

## The SOLID Pillars of Development

Let's start with SOLID. It's not just a word to describe something firm and rigid; in the world of software development, SOLID is a crucial acronym that encapsulates five key design principles. When applied correctly, these principles can significantly improve your ability to write modular, flexible, and robust code.

### 1. Single Responsibility Principle (SRP)

Imagine you have a class in your Flutter code, and it's doing everything - storing user data, saving it to a database, validating input. Hold on, isn't that too much for one class? That's where the Single Responsibility Principle comes into play, asserting that a class should have one, and only one, reason to change.

Take a look at the following 'Noob Way' of writing a user class:



```dart
class User {
  String name;
  String email;

  User({this.name, this.email});

  void saveUser() {
    // Database save logic
  }
}
```

Here, the User class is doing too much: it’s not just storing user data, it’s also responsible for saving it to the database. This violates SRP. Here's the 'Pro Way' to do it:

```dart
class User {
  String name;
  String email;

  User({this.name, this.email});
}

class UserRepository {
  void saveUser(User user) {
    // Database save logic
  }
}
```

By separating the data storage and persistence responsibilities into two distinct classes, our code becomes more modular and easier to manage.

### 2. Open-Closed Principle (OCP)

Imagine you have a logger class in your app that prints logs to the console. Later, you decide you also want to save logs to a file. What do you do? Modify the existing logger class? No, that would violate the Open-Closed Principle, which states that classes should be open for extension, but closed for modification.

Look at the following 'Noob Way' of writing a logger class:

```dart
class Logger {
  void log(String message) {
    print(message);
  }
}
```

If we want to modify this logger to also support file logging, we'd have to change the existing class. This isn't great for maintainability or flexibility. Instead, let's follow the 'Pro Way':

```dart
abstract class Logger {
  void log(String message);
}

class ConsoleLogger extends Logger {
  @override
  void log(String message) {
    print(message);
  }
}
```

With this structure, we can easily extend our logging system with a new class like `FileLogger` without having to modify the existing `ConsoleLogger`.


### 3. Liskov Substitution Principle (LSP)

Ever heard of the saying, "If it looks like a duck, quacks like a duck, but needs batteries – you probably have the wrong abstraction." That's Liskov Substitution Principle for you. It insists that subclasses must be substitutable for their base classes without causing any hiccups.

Consider the following 'Noob Way' of dealing with birds:

```dart
class Bird {
  void fly() {
    print('Flying');
  }
}

class Penguin extends Bird {}
```

At first glance, this might seem fine. But wait, penguins can't fly! So, having a Penguin class extend Bird, which can fly, doesn't make sense. Let's revise this the 'Pro Way':

```dart
abstract class Bird {}

abstract class FlyingBird extends Bird {
  void fly();
}

class Sparrow extends FlyingBird {
  @override
  void fly() {
    print('Flying');
  }
}

class Penguin extends Bird {}
```

Now that's better! We have our `FlyingBird` class for birds that can fly, and our `Penguin` class can just extend `Bird` without any flying-related confusion.

### 4. Interface Segregation Principle (ISP)

Let's say you have an interface Worker with methods work and eat. If you have a Robot class implementing Worker, it will be forced to implement eat method as well. But hang on, robots don't eat! This is where Interface Segregation Principle comes in, stating that no client should be forced to depend on interfaces it doesn't use.

Check out the following 'Noob Way' of implementing a worker interface:

```dart
abstract class Worker {
  void work();
  void eat();
}

class Robot implements Worker {
  @override
  void work() {
    print('Working');
  }

  @override
  void eat() {
    // Robots don't eat!
  }
}
```

That doesn't look right, does it? Here's the 'Pro Way':

```dart
abstract class Worker {
  void work();
}

abstract class Eater {
  void eat();
}

class Robot implements Worker {
  @override
  void work() {
    print('Working');
  }
}

class Human implements Worker, Eater {
  @override
  void work() {
    print('Working');
  }

  @override
  void eat() {
    print('Eating');
  }
}
```

This way, our `Robot` class can just implement `Worker` without having to worry about any eating-related functionalities.

### 5. Dependency Inversion Principle (DIP)

The Dependency Inversion Principle encourages us to write code that depends upon abstractions, not upon concrete details. Essentially, it's all about the high level modules (those calling a function) not depending on the low level modules (those being called).

Here's the 'Noob Way' of creating a user repository:

```dart
class MySQLDatabase {
  void save(String data) {
    print('Saving data to MySQL Database');
  }
}

class UserRepository {
  final MySQLDatabase database;

  UserRepository(this.database);

  void saveUser(String userData) {
    database.save(userData);
  }
}
```

This `UserRepository` class is tightly coupled with the `MySQLDatabase`. But what if we want to switch to a different database system in the future? We'd have to rewrite our `UserRepository`! Instead, we should follow the 'Pro Way':

```dart
abstract class Database {
  void save(String data);
}

class MySQLDatabase implements Database {
  @override
  void save(String data) {
    print('Saving data to MySQL Database');
  }
}

class UserRepository {
  final Database database;

  UserRepository(this.database);

  void saveUser(String userData) {
    database.save(userData);
  }
}
```

In this scenario, our `UserRepository` depends on an abstract `Database`, allowing us to easily change the database implementation in the future without any major code overhaul.

That wraps up our overview of the SOLID principles.

Now let's understand DRY and KISS principles.

---

## The DRY and KISS Principles - Power Tools for Development

### Don't Repeat Yourself (DRY)

This one's a classic! 'Don't Repeat Yourself' or DRY, as we like to call it, is all about reducing repetition in your code. Duplication can make your code hard to maintain and unnecessarily long. Instead, aim for reusing parts of your code to make it cleaner and more efficient.

Consider this example:

Noob Way:

```dart
void printUserData(User user) {
  print('Name: ' + user.name);
  print('Email: ' + user.email);
}

void printAdminData(Admin admin) {
  print('Name: ' + admin.name);
  print('Email: ' + admin.email);
}
```

In this case, we're repeating the same printing logic twice. We're better off following the 'Pro Way':

Pro Way:

```dart
void printUserData(User user) {
  print('Name: ' + user.name);
  print('Email: ' + user.email);
}

void printAdminData(Admin admin) {
  printUserData(admin);
}
```

By reusing `printUserData` in `printAdminData`, we've eliminated duplication and made our code simpler and easier to maintain.

### Keep It Simple, Stupid (KISS)

The KISS principle urges us to keep our code as simple and straightforward as possible. By avoiding unnecessary complexity, we make our code more understandable and easier to maintain.

Check out this 'Noob Way' example:

Noob Way:

```dart
List<int> getEvens(List<int> numbers) {
  return numbers.where((number) => number.isEven).toList();
}

List<int> getOdds(List<int> numbers) {
  return numbers.where((number) => number.isOdd).toList();
}

void printNumbers() {
  List<int> numbers = [1, 2, 3, 4, 5];
  print(getEvens(numbers));
  print(getOdds(numbers));
}
```

Here, we've created two additional functions `getEvens` and `getOdds` that are only used once. This unnecessarily complicates our code. Instead, we should stick to the 'Pro Way':

Pro Way:

```dart
void printNumbers() {
  List<int> numbers = [1, 2, 3, 4, 5];
  print(numbers.where((number) => number.isEven).toList());
  print(numbers.where((number) => number.isOdd).toList());
}
```

By doing everything within `printNumbers`, we've kept our code simple and straight-forward, just as the KISS principle recommends.

---

## Conclusion

And that's a wrap on our overview of the SOLID, DRY, and KISS principles. Remember, the goal here is to write clean, efficient, and maintainable code. While these principles can guide us, don't forget the most important principle of all - write code that makes sense to you and your team. After all, you're the one who's going to be working with it!

Until next time, keep on coding!

---

## Before we go...

Thanks for reading!

If you loved this, drop a like and consider following me :)

I share insights on flutter, open-source & software development to help you become a 10x developer.

Got any doubt or wanna chat? React out to me on [twitter](https://twitter.com/iamyatendrak) or [linkedin](https://www.linkedin.com/in/yatendra2001/).