+ ">
{% if site.data.locales[lang].copyright.license.template %}
- {% capture _replacement %}
+ {% capture _replacement %}
{{ site.data.locales[lang].copyright.license.name }}
{% endcapture %}
- {{ site.data.locales[lang].copyright.license.template | replace: ':LICENSE_NAME', _replacement }}
+ {{ site.data.locales[lang].copyright.license.template | replace: ':LICENSE_NAME', _replacement }}
{% endif %}
diff --git a/_posts/2023-07-22-hello.md b/_posts/2023-07-22-hello.md
index 768309e..97fa10a 100644
--- a/_posts/2023-07-22-hello.md
+++ b/_posts/2023-07-22-hello.md
@@ -1,9 +1,12 @@
---
-
title: Hello World
date: 2023-07-22 0:00:00 +0530
-tags: [hello, world]
-
+tags:
+ - hello world
+slug: hello-world
+description: Hello World
+categories: []
+disable-ty: true
---
-# Hello World
+## Hello World
diff --git a/_posts/2023-07-22-self-hosted-commenting-system.md b/_posts/2023-07-22-self-hosted-commenting-system.md
index 23ff7df..e29509a 100644
--- a/_posts/2023-07-22-self-hosted-commenting-system.md
+++ b/_posts/2023-07-22-self-hosted-commenting-system.md
@@ -1,10 +1,17 @@
---
title: Self-Hosted Commenting System
date: 2023-07-23 0:00:00 +0530
-tags: [privacy, self-hosted, comment-system, remark42]
+tags:
+ - privacy
+ - self-hosted
+ - comment-system
+ - remark42
+categories:
+ - Open Source
+ - Services
---
-# Privacy-focused lightweight commenting engine
+## Privacy-focused lightweight commenting engine
## [Remark 42](https://remark42.com/)
diff --git a/_posts/2024-04-03-solid-principles.md b/_posts/2024-04-03-solid-principles.md
new file mode 100644
index 0000000..bf476fe
--- /dev/null
+++ b/_posts/2024-04-03-solid-principles.md
@@ -0,0 +1,211 @@
+---
+title: SOLID Principles
+description: Solid Principles
+date: 2024-04-03T16:10:57.476Z
+tags:
+ - code quality
+ - oops
+categories:
+ - Programming
+ - Principles
+image:
+ path: /assets/img/posts/solid-principles.jpg
+slug: solid-principles
+---
+
+The SOLID principles are a set of **five design principles** that are intended to guide software development to create more **understandable**, **maintainable**, **extendable** and **scalable** code. These principles were introduced by **Robert C. Martin** (also known as Uncle Bob) in the early 2000s and have since become fundamental concepts in object-oriented design and programming. Here's a brief overview of each principle:
+
+## 1. Single Responsibility Principle (SRP):
+This principle states that a class should have **only one reason to change**. In other words, a class should have **only one responsibility or job**. By adhering to SRP, you ensure that classes are focused and have clear, understandable purposes, which makes them **easier to maintain and test**.
+
+**Example**: *Think of a chef in a restaurant. Instead of having a chef who both cooks meals and serves customers, you'd want separate roles. The chef should focus on cooking delicious dishes, while a waiter takes care of serving customers.*
+
+```c#
+// Before
+public class Chef
+{
+ public void CookMeals() { /*...*/ }
+ public void ServeMeals() { /*...*/ }
+}
+
+// After
+public class Chef
+{
+ public void CookMeals() { /*...*/ }
+}
+
+public class Waiter
+{
+ public void ServeMeals() { /*...*/ }
+}
+
+```
+
+## 2. Open/Closed Principle (OCP):
+This Principle suggests that software entities `(classes, modules, functions, etc.)` should be **open for extension** but **closed for modification**. This means that you should be able to **extend the behavior of a module without modifying its source code**. This is typically achieved through the use of **inheritance**, **polymorphism** and **parameters**.
+
+**Example**: *Consider a shape drawing application. Instead of modifying the existing shape classes every time you need to add a new shape, you'd create a abstact class called **Shape** and implement it in different shape classes like **Circle**, **Square**, etc. Then, when you want to add a new shape, you create a new class that implements the Shape without modifying the existing code.*
+
+```c#
+// Before
+public class Shape
+{
+ public double CircleArea(double radius) { /*...*/ }
+
+ public double SquareArea(double sideLength) { /*...*/ }
+}
+
+// After
+public abstract class Shape
+{
+ public abstract double Area();
+}
+
+public class Circle : Shape
+{
+ public override double Area() { /*...*/ }
+}
+
+public class Square : Shape
+{
+ public override double Area() { /*...*/ }
+}
+```
+
+## 3. Liskov Substitution Principle (LSP):
+This Principle states that objects of a superclass should be substitutable with objects of its subclasses without affecting the correctness of the program. In simpler terms, **a subclass should behave in such a way that it does not break the functionality that the superclass expects**.
+
+**Example**: *Consider a program that expects objects of type FlyingBird. According to LSP, if you have a class Swan that inherits from FlyingBird, you should be able to substitute an instance of Swan wherever you expect an FlyingBird without breaking the program's functionality.*
+
+```c#
+// Before
+public abstract class Bird
+{
+ public abstract void Fly() { /* I can fly */}
+}
+
+public abstract class Penguin : Bird
+{
+ // Violating LSP principle (Penguin breaks the Bird's Fly functionality)
+ public override void Fly()
+ {
+ throw new NotImplementedException("Penguins can't fly!");
+ }
+}
+
+// After
+public abstract class Bird
+{
+ public abstract void Fly() { /* I can fly */}
+}
+
+public abstract class Swan : Bird
+{
+ public override void Fly() { /* I can fly */ }
+}
+```
+
+## 4. Interface Segregation Principle (ISP)
+This Principle suggests that clients should not be forced to depend on interfaces they do not use. In other words, **interfaces should be fine-grained and specific to the client's needs**. This involves breaking large interfaces into smaller, more focused interfaces.
+
+**Example**: *Lets consider **IPerson** interface which has methods to work and eat. **Robot** class cannot implement IPerson interface as it cannot eat. IPerson should be splitted in to smaller interfaces like **IEater** and **IWorker** so Robot can implement IWorker.*
+```c#
+// Before
+public interface IPerson
+{
+ void Work();
+ void Eat();
+}
+
+public class Robot : IPerson
+{
+ public void Work() { /*...*/ }
+ public void Eat() { /*...*/ } // Doesn't make sense for a robot
+}
+
+// After
+public interface IWorker
+{
+ void Work();
+}
+
+public interface IEater
+{
+ void Eat();
+}
+
+public class Robot : IWorker
+{
+ public void Work() { /*...*/ }
+}
+
+public class Man : IEater, IWorker
+{
+ public void Work() { /*...*/ }
+ public void Eat() { /*...*/ }
+}
+```
+
+## 5. Dependency Inversion Principle (DIP)
+This Principle states that high-level modules should not depend on low-level modules. Instead, **both should depend on abstractions**. This principle encourages the use of interfaces or abstract classes to decouple classes from their concrete implementations. Abstractions should not depend on details. Details should depend on abstractions.
+
+**Example**: *If UserService directly depends on the concrete implementation of MySQLDatabase. This violates DIP since the high-level class UserService is directly dependent on a low-level class.
+**If we want to switch to a different database system (e.g., PostgreSQL), we need to modify the UserService class**.
+Instead of depending on concrete implementations, the high-level class UserService should depend on abstractions. Let's create a Database interface as an abstraction:*
+
+```c#
+// Before
+
+/* Low-level module */
+class MySQLDatabase {
+ getUserData(id: number): string {
+ // Logic to fetch user data from MySQL database
+ }
+}
+
+/* High-level module */
+class UserService {
+ private database: MySQLDatabase;
+
+ constructor() {
+ this.database = new MySQLDatabase();
+ }
+
+ getUser(id: number): string {
+ return this.database.getUserData(id);
+ }
+}
+
+// After
+
+/* Abstract interface (abstraction) for the low-level module */
+interface Database {
+ getUserData(id: number): string;
+}
+
+/* low-level module implementing the Database interface */
+class MySQLDatabase implements Database {
+ getUserData(id: number): string {}
+}
+
+/* low-level module implementing the Database interface */
+class PostgreSQLDatabase implements Database {
+ getUserData(id: number): string {}
+}
+
+/* High-level module */
+class UserService {
+ private database: Database;
+
+ constructor(database: Database) {
+ this.database = database;
+ }
+
+ getUser(id: number): string {
+ return this.database.getUserData(id);
+ }
+}
+```
+This way, the UserService class depends on the Database abstraction, not on concrete implementations, fulfilling the Dependency Inversion Principle.
+
+**Note:** I'm excited to share this post that's like a treasure chest filled with nuggets of wisdom from different articles I've come across. Some of the examples taken from these articles [1](https://dev.to/galwaycoder/the-solid-principles-in-software-design-explained-53n) [2](https://dev.to/lukeskw/solid-principles-theyre-rock-solid-for-good-reason-31hn).
\ No newline at end of file
diff --git a/assets/img/posts/solid-principles.jpg b/assets/img/posts/solid-principles.jpg
new file mode 100644
index 0000000..2734c44
Binary files /dev/null and b/assets/img/posts/solid-principles.jpg differ
diff --git a/frontmatter.json b/frontmatter.json
new file mode 100644
index 0000000..153d321
--- /dev/null
+++ b/frontmatter.json
@@ -0,0 +1,70 @@
+{
+ "$schema": "https://frontmatter.codes/frontmatter.schema.json",
+ "frontMatter.taxonomy.contentTypes": [
+ {
+ "name": "default",
+ "pageBundle": false,
+ "previewPath": null,
+ "fields": [
+ {
+ "title": "Title",
+ "name": "title",
+ "type": "string"
+ },
+ {
+ "title": "Description",
+ "name": "description",
+ "type": "string"
+ },
+ {
+ "title": "Publishing date",
+ "name": "date",
+ "type": "datetime",
+ "default": "{{now}}",
+ "isPublishDate": true
+ },
+ {
+ "title": "Tags",
+ "name": "tags",
+ "type": "tags"
+ },
+ {
+ "title": "Categories",
+ "name": "categories",
+ "type": "categories"
+ },
+ {
+ "title": "image",
+ "name": "image",
+ "type": "fields",
+ "fields": [
+ {
+ "title": "path",
+ "name": "path",
+ "type": "image"
+ }
+ ]
+ },
+ {
+ "title": "disable-ty",
+ "name": "disable-ty",
+ "type": "boolean"
+ }
+ ]
+ }
+ ],
+ "frontMatter.framework.id": "jekyll",
+ "frontMatter.content.publicFolder": "assets",
+ "frontMatter.preview.host": "http://localhost:4000",
+ "frontMatter.content.pageFolders": [
+ {
+ "title": "drafts",
+ "path": "[[workspace]]/_drafts"
+ },
+ {
+ "title": "posts",
+ "path": "[[workspace]]/_posts"
+ }
+ ],
+ "frontMatter.git.enabled": true
+}
\ No newline at end of file