content: blog

fezcode · fezcode · commit ff03cc2bd1dc · 2026-02-12T22:53:52.000+03:00
diff --git a/public/posts/interview-journal/01-solid-principles.txt b/public/posts/interview-journal/01-solid-principles.txt
@@ -0,0 +1,65 @@
+# Interview Journal: #1 - SOLID Principles
+
+In the world of software engineering, specifically object-oriented design, the SOLID principles are the bedrock of clean, maintainable, and scalable code. Coined by Robert C. Martin (Uncle Bob), these five principles help developers avoid "code rot" and build systems that are easy to refactor and extend.
+
+As this is the first entry in my **Interview Journal**, I want to dive deep into these principles, explaining them with clear examples and why they matter in a professional environment.
+
+---
+
+## 1. Single Responsibility Principle (SRP)
+> "A class should have one, and only one, reason to change."
+
+This is perhaps the most misunderstood principle. It doesn't mean a class should only have one method. It means a class should be responsible for one *actor* or one specific part of the functionality.
+
+**Bad Example:**
+A `User` class that handles both user data and saving that data to a database.
+**Good Example:**
+A `User` class for data and a `UserRepository` class for persistence.
+
+## 2. Open/Closed Principle (OCP)
+> "Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification."
+
+You should be able to add new functionality without changing existing code. This is usually achieved through interfaces and abstract classes.
+
+**Scenario:**
+If you have a `DiscountService`, instead of using a giant `switch` statement for every new discount type, you define a `DiscountStrategy` interface. Adding a new discount means adding a new class, not touching the `DiscountService`.
+
+## 3. Liskov Substitution Principle (LSP)
+> "Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program."
+
+If `Class B` is a subclass of `Class A`, you should be able to pass `B` anywhere `A` is expected without the program breaking.
+
+**Common Violation:**
+The classic Square-Rectangle problem. If a `Square` inherits from `Rectangle` but overrides the `setHeight` to also change the `width`, it breaks the expectations of a `Rectangle` user.
+
+## 4. Interface Segregation Principle (ISP)
+> "Many client-specific interfaces are better than one general-purpose interface."
+
+Clients should not be forced to depend on methods they do not use. Split large interfaces into smaller, more specific ones.
+
+**Example:**
+Instead of a `SmartDevice` interface with `print()`, `fax()`, and `scan()`, create `Printer`, `Fax`, and `Scanner` interfaces. A basic printer shouldn't be forced to implement a `fax()` method.
+
+## 5. Dependency Inversion Principle (DIP)
+> "Depend upon abstractions, [not] concretions."
+
+1. High-level modules should not depend on low-level modules. Both should depend on abstractions.
+2. Abstractions should not depend on details. Details should depend on abstractions.
+
+**In Practice:**
+Instead of a `Store` class instantiating a `StripePayment` object directly, it should depend on an `IPaymentProvider` interface. This allows you to swap Stripe for PayPal without changing the `Store` logic.
+
+---
+
+## Why SOLID Matters in Interviews
+Interviewers look for more than just "I know what the letters stand for." They want to see:
+- **Trade-offs:** When *not* to over-engineer with SOLID.
+- **Real-world application:** Can you spot a violation in a code review?
+- **Architectural Thinking:** How these principles lead to patterns like Strategy, Factory, and Dependency Injection.
+
+In the next journal entry, we'll look at **Design Patterns** and how they implement these SOLID foundations.
+
+---
+*Date: 2026-02-12*
+*Category: dev*
+*Tags: solid, architecture, interview, clean-code, dev*
diff --git a/public/posts/interview-journal/02-cpp-rule-of-5.txt b/public/posts/interview-journal/02-cpp-rule-of-5.txt
@@ -0,0 +1,60 @@
+# Interview Journal: #2 - C++ Rule of Five (and Three and Zero)
+
+In C++, resource management is a critical skill. Unlike languages with garbage collection, C++ gives you direct control over the lifecycle of your objects. This power comes with the responsibility of correctly managing memory, file handles, and network sockets.
+
+The **Rule of Five** is a guideline for modern C++ (C++11 and later) that defines which special member functions you need to implement if your class manages resources.
+
+---
+
+## The Evolution: The Rule of Three
+Before C++11, we had the **Rule of Three**. It stated that if you needed to define any of the following, you probably needed to define all three:
+1.  **Destructor:** To release resources.
+2.  **Copy Constructor:** To perform a deep copy.
+3.  **Copy Assignment Operator:** To handle assignment (like `a = b`).
+
+If you didn't define these, the compiler would generate default versions that perform shallow copies, leading to double-free errors or memory leaks.
+
+## The Modern Standard: The Rule of Five
+With the introduction of **Move Semantics** in C++11, the Rule of Three expanded to the Rule of Five. We added two more functions to handle "moving" resources instead of copying them:
+4.  **Move Constructor:** Transfer ownership of resources from a temporary object.
+5.  **Move Assignment Operator:** Transfer ownership during assignment.
+
+### The Functions at a Glance:
+```cpp
+class MyResource {
+public:
+    // 1. Destructor
+    ~MyResource();
+
+    // 2. Copy Constructor
+    MyResource(const MyResource& other);
+
+    // 3. Copy Assignment
+    MyResource& operator=(const MyResource& other);
+
+    // 4. Move Constructor
+    MyResource(MyResource&& other) noexcept;
+
+    // 5. Move Assignment
+    MyResource& operator=(MyResource&& other) noexcept;
+};
+```
+
+---
+
+## The Rule of Zero
+The **Rule of Zero** suggests that you should design your classes so that you don't have to define *any* of the special five functions. 
+
+How? By using **RAII (Resource Acquisition Is Initialization)** wrappers like `std::unique_ptr`, `std::shared_ptr`, or `std::vector`. These classes already handle the Rule of Five correctly. If your class only contains such members, the compiler-generated defaults will work perfectly.
+
+---
+
+## Interview Tips:
+- **Why `noexcept`?** Move constructors and move assignment operators should be marked `noexcept`. This is crucial for performance, as containers like `std::vector` will only use moves during resizing if they are guaranteed not to throw.
+- **Copy-and-Swap Idiom:** Mentioning this idiom shows deep knowledge. It's a robust way to implement copy/move assignment operators that provides strong exception safety.
+- **Resource Management:** Always relate these rules back to *ownership*. Who owns the memory? When is it released?
+
+---
+*Date: 2026-02-12*
+*Category: dev*
+*Tags: cpp, cplusplus, memory-management, rule-of-five, interview, dev*
diff --git a/public/posts/posts.json b/public/posts/posts.json
@@ -1149,5 +1149,35 @@
     },
     "authors": ["fezcode"],
     "image": "/images/defaults/sina-salehian-HqmTUJD73mM-unsplash.jpg"
+  },
+  {
+    "title": "Interview Journal",
+    "date": "2025-01-01",
+    "updated": "2025-01-01",
+    "slug": "interview-journal",
+    "description": "A series dedicated to technical interview preparation, architectural patterns, and deep dives into software engineering fundamentals.",
+    "series": {
+      "posts": [
+        {
+          "slug": "solid-principles",
+          "title": "Interview Journal: #1 - SOLID Principles",
+          "filename": "/interview-journal/01-solid-principles.txt",
+          "date": "2025-01-01",
+          "category": "dev",
+          "tags": ["solid", "architecture", "interview", "clean-code", "dev"],
+          "authors": ["fezcode"]
+        },
+        {
+          "slug": "cpp-rule-of-5",
+          "title": "Interview Journal: #2 - CPP Rule of 5",
+          "filename": "/interview-journal/02-cpp-rule-of-5.txt",
+          "date": "2025-01-01",
+          "category": "dev",
+          "tags": ["cpp", "cplusplus", "memory-management", "rule-of-five", "interview", "dev"],
+          "authors": ["fezcode"]
+        }
+      ]
+    },
+    "authors": ["fezcode"]
   }
 ]
