💎 Lecture 09 · Design Principles by Uncle Bob

SOLID Principles

5 principles by Robert C. Martin (Uncle Bob) — أساس الـ OOD الصحيح. OCP و DIP أهمهم في الامتحان. مرتبطين مباشرة بـ Strategy Pattern.

← All Lectures 🎯 Practice Quiz

SOLID Letters

McConnell Traits

Chapters

Practice Qs

SOLID Overview

5 guidelines لتجنب bad design. حروف SOLID = اختصار للـ 5 principles.

Single Responsibility

Open-Close

Liskov Substitution

Interface Segregation

Dependency Inversion

👨‍💼 Robert C. Martin — "Uncle Bob"

Author of Clean Code + Agile Software Craftsmanship.
SOLID = set of guidelines to avoid bad OOP design.
الـ goal: code maintainable, extensible, testable.

S — Single Responsibility Principle (SRP)

"A class should have only one reason to change."

📖 الفكرة

كل class بيمثل concept واحد ويحمل responsibility واحدة.
لو فيه 2 reasons لتغيير الـ class، يبقى لازم تقسمه لـ class اتنين.
كل class يهتم بـ one responsibility + one reason to change.

💻 Example

❌ Bad — 2 responsibilities

class User {
  String name;
  String email;

  void save() {
    // DB logic
  }
  void sendEmail() {
    // SMTP logic
  }
}

⚠️ 2 reasons to change: DB schema changes OR email server changes.

✅ Good — SRP

class User {
  String name; email;
}
class UserRepository {
  void save(User u) {...}
}
class EmailService {
  void send(User u) {...}
}

✓ Each class has ONE reason to change.

O — Open-Close Principle (OCP) ⭐

"Software entities should be open for extension, but closed for modification." — الأهم لأنه أساس Strategy Pattern.

🔌 الفكرة

اقدر تضيف functionality جديد بدون ما تغيّر existing code.

زي mixer kitchen — تقدر تغير الـ attachments بدون ما تغير الـ engine.

كيف نطبقه؟

Use Interfaces / Abstract Classes.
Use Design Patterns (Strategy, Decorator, etc.).

📚 Motivating Problem — Sorting

عايز ArrayList بسـ sort() method. ابدأ بـ bubble sort:

class ArrayList<T> {
  void sort() { /* bubble sort */ }
}

عايز تبدّل لـ merge sort؟ احذف bubble وضف merge. سهل.

عايز الاتنين متاحين؟ ضف if statement:

void sort(int sortChoice) {
  if (sortChoice == 1) { /* merge sort */ }
  if (sortChoice == 2) { /* bubble sort */ }
}

🔴 المشكلةكل ما تضيف algorithm جديد، لازم تعدل الكود. هذا violation للـ OCP. مع كل تعديل، الكلاينتس اللي بيستخدموا الـ class ممكن يتأثروا.

💡 Uncle Bob's Solution

"When writing a class, ensure that when you need to extend its behavior, you don't have to change the class but to extend it."

الحل: استخدم Abstract Classes + concrete classes لتنفيذ behavior. ده الـ Strategy Pattern — هتشوفه تفصيلاً في Lecture 12.

L — Liskov Substitution Principle (LSP)

"Subtypes must be substitutable for their base types."

📖 الفكرة (Barbara Liskov)

لو S هو subtype من T، يبقى objects من type T ممكن تتبدل بـ objects من type S بدون ما تأثر على correctness.

اللي الـ subclass ما يلغيش أو يكسرش contract الـ superclass.

🟦 Classic Example — Square vs Rectangle

❌ Violates LSP

class Rectangle {
  int w, h;
  void setWidth(int w) { ... }
  void setHeight(int h) { ... }
}

// Square is-a Rectangle?
class Square extends Rectangle {
  // w must = h always
  void setWidth(int w) {
    this.w = w;
    this.h = w;  // surprise!
  }
}

✅ Test if substitutable

void resize(Rectangle r) {
  r.setWidth(5);
  r.setHeight(4);
  assert(r.area() == 20);
}

// Passing a Square FAILS:
// setHeight changes width too
// → area = 16, not 20
// Square is NOT substitutable for Rectangle

🤯 الـ paradoxفي الـ math، square IS-A rectangle. بس في OOP، subclass = behavior. لو behavior بيكسر expectations، يبقى violation للـ LSP. الحل: ما تخليش Square ترث من Rectangle — اعملهم separate types أو حدد abstraction أعلى.

🐧 Example 2 — Bird vs Penguin

لو عندك Bird class فيها fly()، و Penguin extends Bird — بس البطريق ما بيطيرش! → بيكسر الـ substitutability.

الحل: افصل الطيور الطايرة عن غير الطايرة. استخدم interfaces / abstractions مناسبة (مثلاً Flyable منفصل).

🧑‍💼 Example 3 — Employee vs VolunteerEmployee ⭐

عندك Employee hierarchy، و VolunteerEmployee extends Employee. بس الـ VolunteerEmployee ملوش salary/payment → الـ calcPay() بتبقى مشكلة.

🔴 ليه ده أسوأ؟الكود اللي المفروض يشتغل على الـ Employee base class هيضطر يعمل explicit reference لواحد من الـ derivatives (يـفحص: هل ده VolunteerEmployee؟). ده violation صريح للـ LSP:

VolunteerEmployee مش substitutable لـ Employee.
الـ users بتوع Employee بيتأثروا بمجرد وجود الـ VolunteerEmployee.

✅ الحل (من السلايدات)

الـ Volunteers مش employees أصلاً.
VolunteerEmployee ما يورّثش من Employee.
ما يتبعتش لـ functions بتحتاج calcPay().

I — Interface Segregation Principle (ISP)

"Clients should not be forced to depend upon interfaces they do not use."

📖 الفكرة

قسّم الـ "fat" interfaces لـ smaller, more specific ones.

الـ "Fat" interfaces بتؤدي لـ "polluted" classes — مجبرين implement methods ما يحتاجوهاش (غالباً بيرموا NotImplementedException).

💻 Example

❌ Fat interface

interface Worker {
  void work();
  void eat();
  void sleep();
}

class Robot implements Worker {
  void work() {...}
  void eat() {
    throw new
      NotImplementedException();
  }
  // Robots don't eat/sleep!
}

✅ Segregated interfaces

interface Workable {
  void work();
}
interface Feedable {
  void eat();
}

class Robot implements
                Workable {
  void work() {...}
}
class Human implements
        Workable, Feedable {
  void work() {...}
  void eat() {...}
}

🚪 Example 2 — Door & SecurityDoor

عندك IDoor { lock(); unlock(); isOpen(); }. جه عايز SecurityDoor تطلّق alarm لو فضلت مفتوحة → ضفت timeOut() للـ IDoor.

🔴 المشكلةمش كل الأبواب timed! إضافة timeOut() للـ IDoor بتلوّثه (polluted interface) وبتجبر كل door تعمل dummy implementation.

✅ Segregated

interface IDoor {
  void lock();
  void unlock();
  bool isOpen();
}
interface ITimerClient {
  void timeOut();
}

class SecurityDoor implements
              IDoor, ITimerClient {
  void timeOut() {...}
}

📋 Vehicle Example

// ❌ Vehicle{ drive(); fly(); }
// Car.fly() → OOPS
// Drone.drive() → OOPS

// ✅ Split them:
interface Drivable { void drive(); }
interface Flyable   { void fly(); }

class Car      implements Drivable
class Airplane implements Drivable, Flyable
class Drone    implements Flyable

📌 نقاط مهمة من السلايدات

Many client-specific interfaces > one general-purpose interface.
Fat interface = Fat class — حتى التغيير في method مش مستخدمة ممكن يأثر على الـ users.
ISP مش معناه interface واحد لكل class — المعنى: group clients by type (لو غيّرت لـ ClientA ما يأثرش على ClientB/ClientC).
مثال واقعي: ASP.NET Membership Provider أجبر الـ custom provider على implement 27 method/property — fat interface كلاسيكي.

D — Dependency Inversion Principle (DIP) ⭐

"High-level modules should not depend on low-level modules. Both should depend on abstractions."

📖 الفكرة

Abstractions should not depend on details.
Details should depend on abstractions.

في الـ traditional design: high-level modules بتعتمد على low-level. أي تغيير في low-level بيخرب high-level.

في الـ DIP: الاتنين بيعتمدوا على interface (abstraction).

💻 Example

❌ Direct dependency

class MySQLDatabase {
  void save(String data) {...}
}

class UserService {
  private MySQLDatabase db;

  UserService() {
    // hard-coded dependency
    db = new MySQLDatabase();
  }
}

⚠️ UserService can't switch to Postgres without code change.

✅ Depend on abstraction

interface Database {
  void save(String data);
}
class MySQLDatabase
            implements Database {...}
class PostgresDatabase
            implements Database {...}

class UserService {
  private Database db;

  UserService(Database db) {
    this.db = db;  // injected
  }
}

✓ Easy swap. Easy testing (inject mock).

💡 Strongly Related to Strategy Patternالـ DIP بيعمل الـ foundation للـ Strategy. لما UserService بيعتمد على Database interface بدل concrete، تقدر تستبدل implementations في runtime — exactly الـ Strategy Pattern.

🧷 Practical Notes (من السلايدات)

ليه DIP؟ الـ concrete classes بتتغير كتير (volatile)، الـ abstractions بتتغير أقل. الـ abstractions = "hinge points" (نقاط ارتكاز ثابتة). وبيدعم الـ Open/Close Principle.
آمن إنك تعتمد على concrete classes مستقرة (stable) زي String و Vector — مش كل concrete class ممنوعة. تجنّب الـ volatile concrete classes بس.
UML check: الـ dependency arrows المفروض تشاور على interfaces / abstract classes — مش على concrete classes.

Steve McConnell — Views on Design

من كتاب "Code Complete" — Chapter 5. جوهر الـ design = managing complexity.

📍 Where Does Design Fit?

الـ design بيقع بين الـ requirements والـ code — مرحلتين:

Requirements → Architecture / High-Level Design → Low-Level Design → Code

🪜 Levels of Design

High-level design — الـ system components والـ connections بينهم.
Low-level design — الـ objects · classes · algorithms · variables.
الحد بين الاتنين blurry (مش واضح تماماً).

💬 Quotes عن الـ Design "The driving force behind design is managing complexity." · "The goal of software design techniques is breaking complicated problems into simple pieces." · "The key to performance is elegance, not battalions of special cases." — Bentley & McIlroy

7 Characteristics of Good Design

Minimal Complexity

Divide & conquer · use abstractions · reduce coupling · increase cohesion · remove dead code · avoid clever tricks · comment · document.

Loose Coupling

قلّل الـ connections بين أجزاء البرنامج. بيبسّط الـ integration / testing / maintenance.

Strong Cohesion

الـ routines بتدعم الـ purpose المركزي للـ module. الهدف: maximize cohesion.

Extensibility

تطوّر النظام من غير ما تخرّب structure-ه. التغييرات المتوقعة تسبب أقل trauma.

Reusability

إعادة استخدام أجزاء في systems تانية.

Maintainability

أسهل في إصلاح الـ bugs · التحسين · إضافة features.

Leanness

مفيش أجزاء زيادة. Voltaire: "الكتاب يخلص لما مفيش حاجة تانية ممكن تتشال". الكود الزيادة بيزوّد effort الـ dev/review/testing/maintenance.

🎯

Practice Quiz — Lecture 9

8 أسئلة على SOLID + McConnell. Q3 في امتحانات Winter 2023 بـ 24 marks على DIP + Adapter + Observer.

Question 1 Practice — SRP

What does "Single Responsibility Principle" mean?

A A class should have only one method

B A class should have only one attribute

C A class should have only one reason to change

D A class should have only one instance

✅ الإجابة الصح: C — One reason to change SRP = single concept + single responsibility = one reason to change.

A, B — Classes can have multiple methods/attributes — that's normal. · D — That's Singleton pattern.

Question 2 Practice — OCP

"Software entities should be open for extension, but closed for modification" means:

A Classes should never be modified

B Add new functionality by extending, not by changing existing code

C All classes must be marked final

D Don't use inheritance

✅ الإجابة الصح: B OCP = extend behavior without modifying source. Achieved by interfaces, abstract classes, or design patterns (Strategy, Decorator).

A — Bug fixes are allowed; "closed for modification" means closed against extensions changing logic. · C — final blocks all extension, opposite of OCP. · D — Inheritance is actually part of how OCP is achieved.

Question 3 Practice — Strategy/OCP

A sort() method uses an if/else chain to switch between bubble, merge, and quick sort. To add a new sort algorithm requires editing this chain. Which principle is violated?

A Open-Close Principle

B Single Responsibility

C Liskov Substitution

D Interface Segregation

✅ الإجابة الصح: A — OCP كل ما تضيف algorithm جديد، تعدل الكود الموجود. Open for extension = NO. Closed for modification = NO. الحل: Strategy Pattern.

B (SRP) — The class still has one responsibility (sorting). · C (LSP) — No subclass involved. · D (ISP) — No interface issue.

Question 4 Practice — LSP

A Square class extends a Rectangle class. Setting width on Square also changes height, breaking caller assumptions. Which principle is violated?

A Open-Close

B Single Responsibility

C Liskov Substitution

D Dependency Inversion

✅ الإجابة الصح: C — LSP Square's behavior breaks the contract of Rectangle. Code expecting Rectangle won't work correctly with Square.

Question 5 Practice — ISP

A Worker interface has methods work(), eat(), sleep(). A Robot class implementing it must throw NotImplementedException for eat and sleep. Which principle is violated?

A SRP

B OCP

C LSP

D ISP

✅ الإجابة الصح: D — ISP The Worker interface is too "fat". Robot is forced to depend on methods it doesn't use. الحل: split into Workable, Feedable, Sleepable.

Question 6 Practice — DIP

Which of these correctly applies Dependency Inversion?

A class Service { MySQLDb db = new MySQLDb(); }

B class Service { Database db; Service(Database d) { this.db = d; }}

C class Service extends Database { }

D class Service { static MySQLDb db = new MySQLDb(); }

✅ الإجابة الصح: B الـ Service بيعتمد على Database interface (abstraction)، وبيتم inject الـ concrete implementation. ده DIP — depend on abstractions, not concretes.

A, D — direct dependency على concrete MySQLDb. Violation. · C — inheritance، مش dependency.

Question 7 Practice — McConnell

According to McConnell (Code Complete), what is the driving force behind software design?

A Maximizing performance

B Managing complexity

C Writing the fewest lines of code

D Using as many design patterns as possible

✅ الإجابة الصح: B — Managing complexity McConnell: "The driving force behind design is managing complexity." الهدف تكسير المشاكل المعقّدة لأجزاء بسيطة. (الـ 7 characteristics بتخدم الهدف ده: minimal complexity, loose coupling, strong cohesion, extensibility, reusability, maintainability, leanness).

A — "The key to performance is elegance, not battalions of special cases" — الأداء مش الـ driving force. · C — leanness مفيدة، بس مش "أقل سطور" بأي ثمن. · D — الـ patterns وسيلة، مش هدف.

Question 8 Practice — comprehensive

Which SOLID principle is the foundation for the Strategy Pattern?

A Single Responsibility

B Liskov Substitution

C Interface Segregation

D Open-Close Principle

✅ الإجابة الصح: D — OCP Strategy = encapsulate algorithms in classes, swap them at runtime. الـ system بيكون open for adding new algorithms (just create a new strategy class) and closed for modification (the context class never changes). DIP بيدعم الـ OCP لكن الأساس هو OCP.

📋

Cheat Sheet

SOLID + McConnell في صفحة واحدة.

🔵 SOLID

S — SRP

One reason to change per class

O — OCP ⭐

Open for extension, closed for modification

L — LSP

Subtype substitutable for base

I — ISP

No fat interfaces; split & specialize

D — DIP ⭐

Depend on abstractions, not concretes

📐 McConnell — 7 Good Design Traits

1. Minimal Complexity

Simple > clever (driving force)

2. Loose Coupling

Few connections

3. Strong Cohesion

Routines serve one purpose

4. Extensibility

Change w/o damaging structure

5. Reusability

Reuse parts elsewhere

6. Maintainability

Easy fix/enhance/add

7. Leanness

No extra parts (Voltaire)

🔑 Quick Identifiers

if/else chain → ?

OCP violation. Use Strategy.

class with 2 jobs → ?

SRP violation

throw NotImplemented → ?

ISP violation

new ConcreteClass() in constructor → ?

DIP violation

subclass breaks parent contract → ?

LSP violation

👨‍💼 Authors

Uncle Bob

Robert C. Martin · Clean Code · SOLID

McConnell

Steve · Code Complete · 7 design traits

Liskov

Barbara Liskov · 1987 · LSP

⚡

Rapid Revision

Flashcards · Mistakes · Doctor favorites.

SOLID expanded؟

tap

SRP · OCP · LSP · ISP · DIP

SOLID author؟

tap

Robert C. Martin (Uncle Bob)

SRP in 1 line؟

tap

One reason to change

OCP in 1 line؟

tap

Open for extension, closed for modification

LSP in 1 line؟

tap

Subtype substitutable for base

ISP in 1 line؟

tap

No fat interfaces — split & specialize

DIP in 1 line؟

tap

Depend on abstractions, not concretes

if/else chain for behavior = which violation؟

tap

OCP — fix with Strategy

McConnell: driving force of design؟

tap

Managing complexity

🚨 Common Mistakes

1. خلط SRP و ISPSRP عن الـ class (one job). ISP عن الـ interface (no fat APIs).

2. اعتبار "Square extends Rectangle" validفي math نعم، في OOP لأ — بيكسر LSP.

3. DIP = "use interfaces"مش بس استخدام interfaces. DIP = الـ high-level يعتمد على abstraction، و الـ low-level يعتمد على نفس الـ abstraction.

4. McConnell's design traits = 7 مش 10الـ 7 الصح: Minimal complexity · Loose coupling · Strong cohesion · Extensibility · Reusability · Maintainability · Leanness. (Fan-in/Fan-out مش ضمن الـ list بتاعة الدكتور).

⭐ What Dr. El-Ramly Loves

🔥 SOLID في الامتحان

Q3 (15-24 marks) — Apply Strategy + DIP + Adapter في كود يدوي. اقرأ Lec 12 كمان.
OCP scenario — يدي كود فيه if/else ويطلب identify الـ violation.
DIP code — Winter 2025 Q1.09 — أي كود implement DIP؟
Match principle to scenario — squarerectangle = LSP, fat interface = ISP, إلخ.