דפוסי תכנות מונחה עצמים ב-TypeScript: מדריך לתכנון מחלקות ואסטרטגיות ירושה

בעולם פיתוח התוכנה המודרני, TypeScript הפכה לאבן יסוד לבניית אפליקציות חזקות, ניתנות להרחבה וקלות לתחזוקה. מערכת הטיפוסים החזקה שלה, הבנויה על גבי JavaScript, מספקת למפתחים את הכלים לתפוס שגיאות מוקדם ולכתוב קוד צפוי יותר. בליבה של העוצמה של TypeScript טמונה התמיכה המקיפה שלה בעקרונות תכנות מונחה עצמים (OOP). עם זאת, רק לדעת איך ליצור מחלקה זה לא מספיק. שליטה ב-TypeScript דורשת הבנה מעמיקה של תכנון מחלקות, היררכיות ירושה והפשרות בין דפוסי ארכיטקטורה שונים.

מדריך זה מיועד לקהל עולמי של מפתחים, מאלה שמגבשים את כישוריהם הבינוניים ועד לאדריכלים מנוסים. נעמיק במושגי הליבה של OOP ב-TypeScript, נחקור אסטרטגיות יעילות לתכנון מחלקות ונתמודד עם הוויכוח העתיק: ירושה לעומת קומפוזיציה. בסופו של דבר, תהיו מצוידים בידע לקבל החלטות עיצוביות מושכלות שיובילו לבסיסי קוד נקיים, גמישים ועמידים יותר לעתיד.

הבנת עמודי התווך של OOP ב-TypeScript

לפני שנצלול לדפוסים מורכבים, בואו ניצור בסיס איתן על ידי חזרה על ארבעת עמודי התווך הבסיסיים של תכנות מונחה עצמים כפי שהם חלים על TypeScript.

1. אנקפסולציה

אנקפסולציה היא העיקרון של איגום נתוני אובייקט (מאפיינים) והשיטות הפועלות על נתונים אלה ליחידה אחת - מחלקה. זה גם כרוך בהגבלת גישה ישירה למצב הפנימי של אובייקט. TypeScript משיגה זאת בעיקר באמצעות משני גישה: public, private ו-protected.

דוגמה: חשבון בנק שבו ניתן לשנות את היתרה רק באמצעות שיטות הפקדה ומשיכה.

            class BankAccount {
  private balance: number = 0;

  constructor(initialBalance: number) {
    if (initialBalance >= 0) {
      this.balance = initialBalance;
    }
  }

  public deposit(amount: number): void {
    if (amount > 0) {
      this.balance += amount;
      console.log(`Deposited: ${amount}. New balance: ${this.balance}`);
    }
  }

  public getBalance(): number {
    // We expose the balance through a method, not directly
    return this.balance;
  }
}
            

              
                Copy
              
            
          

2. הפשטה

הפשטה פירושה הסתרת פרטי יישום מורכבים וחשיפה רק של התכונות החיוניות של אובייקט. זה מאפשר לנו לעבוד עם מושגים ברמה גבוהה מבלי שנצטרך להבין את המכניקה המורכבת שמתחת. ב-TypeScript, הפשטה מושגת לעתים קרובות באמצעות מחלקות abstract ו-interfaces.

דוגמה: כשאתם משתמשים בשלט רחוק, אתם פשוט לוחצים על כפתור "הפעלה". אתם לא צריכים לדעת על אותות האינפרא אדום או על המעגלים הפנימיים. השלט מספק ממשק מופשט לפונקציונליות של הטלוויזיה.

3. ירושה

ירושה היא מנגנון שבו מחלקה חדשה (תת-מחלקה או מחלקה נגזרת) יורשת מאפיינים ושיטות ממחלקה קיימת (מחלקה-על או מחלקת בסיס). זה מקדם שימוש חוזר בקוד ומבסס קשר "is-a" ברור בין מחלקות. TypeScript משתמשת במילת המפתח extends לירושה.

דוגמה: `מנהל` הוא סוג של `עובד`. הם חולקים מאפיינים נפוצים כמו `שם` ו-`מזהה`, אך ל`מנהל` עשויים להיות מאפיינים נוספים כמו `כפופים`.

            class Employee {
  constructor(public name: string, public id: number) {}

  getProfile(): string {
    return `Name: ${this.name}, ID: ${this.id}`;
  }
}

class Manager extends Employee {
  constructor(name: string, id: number, public subordinates: Employee[]) {
    super(name, id); // Call the parent constructor
  }

  // Managers can also have their own methods
  delegateTask(): void {
    console.log(`${this.name} is delegating tasks.`);
  }
}
            

              
                Copy
              
            
          

4. פולימורפיזם

פולימורפיזם, שפירושו "צורות רבות", מאפשר להתייחס לאובייקטים של מחלקות שונות כאובייקטים של מחלקת-על משותפת. הוא מאפשר לממשק בודד (כמו שם שיטה) לייצג צורות בסיסיות שונות (יישומים). זה מושג לעתים קרובות באמצעות דריסת שיטות.

דוגמה: שיטת `render()` שמתנהגת אחרת עבור אובייקט `מעגל` לעומת אובייקט `ריבוע`, למרות ששניהם `צורה`.

            abstract class Shape {
  abstract draw(): void; // An abstract method must be implemented by subclasses
}

class Circle extends Shape {
  draw(): void {
    console.log("Drawing a circle.");
  }
}

class Square extends Shape {
  draw(): void {
    console.log("Drawing a square.");
  }
}

function renderShapes(shapes: Shape[]): void {
  shapes.forEach(shape => shape.draw()); // Polymorphism in action!
}

const myShapes: Shape[] = [new Circle(), new Square()];
renderShapes(myShapes);
// Output:
// Drawing a circle.
// Drawing a square.
            

              
                Copy
              
            
          

הוויכוח הגדול: ירושה לעומת קומפוזיציה

זוהי אחת מהחלטות העיצוב הקריטיות ביותר ב-OOP. החוכמה המקובלת בהנדסת תוכנה מודרנית היא "להעדיף קומפוזיציה על פני ירושה". בואו נבין מדוע על ידי חקירת שני המושגים לעומק.

מהי ירושה? יחס "is-a"

ירושה יוצרת צימוד הדוק בין מחלקת הבסיס למחלקה הנגזרת. כשאתם משתמשים ב-`extends`, אתם מציינים שהמחלקה החדשה היא גרסה מיוחדת של מחלקת הבסיס. זהו כלי רב עוצמה לשימוש חוזר בקוד כאשר קיים קשר היררכי ברור.

• יתרונות:
  • שימוש חוזר בקוד: לוגיקה נפוצה מוגדרת פעם אחת במחלקת הבסיס.
  • פולימורפיזם: מאפשר התנהגות פולימורפית אלגנטית, כפי שנראה בדוגמת ה`צורה` שלנו.
  • היררכיה ברורה: הוא מדמה מערכת סיווג מלמעלה למטה מהעולם האמיתי.
• חסרונות:
  • צימוד הדוק: שינויים במחלקת הבסיס עלולים לשבור מחלקות נגזרות שלא במכוון. זה ידוע בתור "בעיית מחלקת הבסיס השבירה".
  • גיהנום היררכיה: שימוש יתר עלול להוביל לשרשראות ירושה עמוקות, מורכבות ונוקשות שקשה להבין ולתחזק.
  • בלתי גמיש: מחלקה יכולה לרשת רק ממחלקה אחרת ב-TypeScript (ירושה יחידה), מה שיכול להיות מגביל. אינך יכול לרשת תכונות ממחלקות מרובות ולא קשורות.

מתי ירושה היא בחירה טובה?

השתמשו בירושה כאשר היחסים הם באמת "is-a" והם יציבים ובלתי סבירים להשתנות. לדוגמה, `CheckingAccount` ו-`SavingsAccount` הם שניהם סוגים בסיסיים של `BankAccount`. היררכיה זו הגיונית וסביר להניח שלא תשונה.

מהי קומפוזיציה? יחס "has-a"

קומפוזיציה כרוכה בבניית אובייקטים מורכבים מאובייקטים קטנים ועצמאיים יותר. במקום שמחלקה תהיה משהו אחר, יש לה אובייקטים אחרים המספקים את הפונקציונליות הנדרשת. זה יוצר צימוד רופף, מכיוון שהמחלקה מקיימת אינטראקציה רק עם הממשק הציבורי של האובייקטים המורכבים.

• יתרונות:
  • גמישות: ניתן לשנות את הפונקציונליות בזמן ריצה על ידי החלפת אובייקטים מורכבים.
  • צימוד רופף: המחלקה המכילה אינה צריכה לדעת את הפעולה הפנימית של הרכיבים שבהם היא משתמשת. זה מקל על בדיקת ותחזוקת קוד.
  • נמנע מבעיות היררכיה: ניתן לשלב פונקציונליות ממקורות שונים מבלי ליצור עץ ירושה סבוך.
  • אחריות ברורה: כל מחלקת רכיבים יכולה לדבוק בעיקרון האחריות הבודדת.
• חסרונות:
  • יותר קוד סטנדרטי: זה יכול לדרוש לפעמים יותר קוד כדי לחבר את הרכיבים השונים בהשוואה למודל ירושה פשוט.
  • פחות אינטואיטיבי עבור היררכיות: הוא לא מדמה טקסונומיות טבעיות באופן ישיר כמו ירושה.

דוגמה מעשית: המכונית

`מכונית` היא דוגמה מושלמת לקומפוזיציה. `מכונית` היא לא סוג של `מנוע`, וגם לא סוג של `גלגל`. במקום זאת, ל`מכונית` יש `מנוע` ויש `גלגלים`.

            // Component classes
class Engine {
  start() {
    console.log("Engine starting...");
  }
}

class GPS {
  navigate(destination: string) {
    console.log(`Navigating to ${destination}...`);
  }
}

// The composite class
class Car {
  private readonly engine: Engine;
  private readonly gps: GPS;

  constructor() {
    // The Car creates its own parts
    this.engine = new Engine();
    this.gps = new GPS();
  }

  driveTo(destination: string) {
    this.engine.start();
    this.gps.navigate(destination);
    console.log("Car is on its way.");
  }
}

const myCar = new Car();
myCar.driveTo("New York City");
            

              
                Copy
              
            
          

עיצוב זה גמיש מאוד. אם אנו רוצים ליצור `מכונית` עם `מנוע חשמלי`, איננו זקוקים לשרשרת ירושה חדשה. אנו יכולים להשתמש בהזרקת תלות כדי לספק ל`מכונית` את הרכיבים שלה, מה שהופך אותה למודולרית עוד יותר.

            interface IEngine {
  start(): void;
}

class PetrolEngine implements IEngine {
  start() { console.log("Petrol engine starting..."); }
}

class ElectricEngine implements IEngine {
  start() { console.log("Silent electric engine starting..."); }
}

class AdvancedCar {
  // The car depends on an abstraction (interface), not a concrete class
  constructor(private engine: IEngine) {}

  startJourney() {
    this.engine.start();
    console.log("Journey has begun.");
  }
}

const tesla = new AdvancedCar(new ElectricEngine());
tesla.startJourney();

const ford = new AdvancedCar(new PetrolEngine());
ford.startJourney();
            

              
                Copy
              
            
          

אסטרטגיות ודפוסים מתקדמים ב-TypeScript

מעבר לבחירה הבסיסית בין ירושה לקומפוזיציה, TypeScript מספקת כלים רבי עוצמה ליצירת עיצובי מחלקות מתוחכמים וגמישים.

1. מחלקות מופשטות: השרטוט לירושה

כאשר יש לכם יחס "is-a" חזק, אך אתם רוצים להבטיח שלא ניתן ליצור מופעים של מחלקות בסיס בעצמן, השתמשו במחלקות `abstract`. הן פועלות כשרטוט, מגדירות שיטות ומאפיינים נפוצים, ויכולות להכריז על שיטות `abstract` שמחלקות נגזרות חייבות ליישם.

מקרה שימוש: מערכת עיבוד תשלומים. אתם יודעים שלכל שער חייבות להיות שיטות `pay()` ו-`refund()`, אך היישום ספציפי לכל ספק (לדוגמה, Stripe, PayPal).

            abstract class PaymentGateway {
  constructor(public apiKey: string) {}

  // A concrete method shared by all subclasses
  protected connect(): void {
    console.log("Connecting to payment service...");
  }

  // Abstract methods that subclasses must implement
  abstract processPayment(amount: number): boolean;
  abstract issueRefund(transactionId: string): boolean;
}

class StripeGateway extends PaymentGateway {
  processPayment(amount: number): boolean {
    this.connect();
    console.log(`Processing ${amount} via Stripe.`);
    return true;
  }

  issueRefund(transactionId: string): boolean {
    console.log(`Refunding transaction ${transactionId} via Stripe.`);
    return true;
  }
}

// const gateway = new PaymentGateway("key"); // Error: Cannot create an instance of an abstract class.
const stripe = new StripeGateway("sk_test_123");
stripe.processPayment(100);
            

              
                Copy
              
            
          

2. ממשקים: הגדרת חוזים להתנהגות

ממשקים ב-TypeScript הם דרך להגדיר חוזה עבור הצורה של מחלקה. הם מציינים אילו מאפיינים ושיטות מחלקה חייבת לכלול, אך הם אינם מספקים יישום כלשהו. מחלקה יכולה `implement` ממשקים מרובים, מה שהופך אותם לאבן יסוד של עיצוב קומפוזיציוני ומנותק.

ממשק לעומת מחלקה מופשטת

• השתמשו במחלקה מופשטת כאשר אתם רוצים לשתף קוד מיושם בין מספר מחלקות קשורות זו לזו.
• השתמשו בממשק כאשר אתם רוצים להגדיר חוזה להתנהגות שיכולה להיות מיושמת על ידי מחלקות נפרדות ולא קשורות.

מקרה שימוש: במערכת, ייתכן שאובייקטים שונים רבים יצטרכו להיות מסודרים לפורמט מחרוזת (לדוגמה, לצורך רישום או אחסון). אובייקטים אלה (`User`, `Product`, `Order`) אינם קשורים אך חולקים יכולת נפוצה.

            interface ISerializable {
  serialize(): string;
}

class User implements ISerializable {
  constructor(public id: number, public name: string) {}

  serialize(): string {
    return JSON.stringify({ id: this.id, name: this.name });
  }
}

class Product implements ISerializable {
  constructor(public sku: string, public price: number) {}

  serialize(): string {
    return JSON.stringify({ sku: this.sku, price: this.price });
  }
}

function logItems(items: ISerializable[]): void {
  items.forEach(item => {
    console.log("Serialized item:", item.serialize());
  });
}

const user = new User(1, "Alice");
const product = new Product("TSHIRT-RED", 19.99);
logItems([user, product]);
            

              
                Copy
              
            
          

3. Mixins: גישה קומפוזיציונית לשימוש חוזר בקוד

מכיוון ש-TypeScript מאפשרת רק ירושה יחידה, מה אם אתם רוצים לעשות שימוש חוזר בקוד ממקורות מרובים? כאן נכנס לתמונה דפוס ה-mixin. Mixins הן פונקציות שלוקחות בנאי ומחזירות בנאי חדש שמרחיב אותו בפונקציונליות חדשה. זוהי צורה של קומפוזיציה המאפשרת לכם "לערבב" יכולות לתוך מחלקה.

מקרה שימוש: אתם רוצים להוסיף התנהגויות `Timestamp` (עם `createdAt`, `updatedAt`) ו-`SoftDeletable` (עם מאפיין `deletedAt` ושיטת `softDelete()`) למחלקות מודלים מרובות.

            // A Type helper for mixins
type Constructor = new (...args: any[]) => T;

// Timestamp Mixin
function Timestamped(Base: TBase) {
  return class extends Base {
    createdAt: Date = new Date();
    updatedAt: Date = new Date();
  };
}

// SoftDeletable Mixin
function SoftDeletable(Base: TBase) {
  return class extends Base {
    deletedAt: Date | null = null;

    softDelete() {
      this.deletedAt = new Date();
      console.log("Item has been soft deleted.");
    }
  };
}

// Base class
class DocumentModel {
  constructor(public title: string) {}
}

// Create a new class by composing mixins
const UserAccountModel = SoftDeletable(Timestamped(DocumentModel));

const userAccount = new UserAccountModel("My User Account");
console.log(userAccount.title);
console.log(userAccount.createdAt);
userAccount.softDelete();
console.log(userAccount.deletedAt);
            

              
                Copy
              
            
          

מסקנה: בניית אפליקציות TypeScript עמידות לעתיד

שליטה בתכנות מונחה עצמים ב-TypeScript היא מסע מהבנת תחביר ועד לאימוץ פילוסופיית עיצוב. לבחירות שאתם עושים בנוגע למבנה מחלקות, ירושה וקומפוזיציה יש השפעה עמוקה על הבריאות ארוכת הטווח של האפליקציה שלכם.

הנה הנקודות העיקריות עבור תרגול הפיתוח הגלובלי שלכם:

1. התחילו עם עמודי התווך: ודאו שיש לכם הבנה מוצקה של אנקפסולציה, הפשטה, ירושה ופולימורפיזם. הם אוצר המילים של OOP.
2. העדיפו קומפוזיציה על פני ירושה: עיקרון זה יוביל אתכם לקוד גמיש, מודולרי ובדיק יותר. התחילו עם קומפוזיציה והגיעו לירושה רק כאשר קיים יחס "is-a" ברור ויציב.
3. השתמשו בכלי הנכון למשימה:
   • השתמשו בירושה להתמחות אמיתית ושיתוף קוד בהיררכיה יציבה.
   • השתמשו במחלקות מופשטות כדי להגדיר בסיס משותף למשפחה של מחלקות, לשתף חלק מהיישום תוך אכיפת חוזה.
   • השתמשו בממשקים כדי להגדיר חוזים להתנהגות שיכולה להיות מיושמת על ידי כל מחלקה, קידום ניתוק קיצוני.
   • השתמשו בMixins כאשר אתם צריכים להרכיב פונקציונליות לתוך מחלקה ממקורות מרובים, להתגבר על המגבלות של ירושה יחידה.

על ידי חשיבה ביקורתית על הדפוסים הללו והבנת הפשרות שלהם, אתם יכולים לתכנן אפליקציות TypeScript שהן לא רק חזקות ויעילות היום, אלא גם קלות להתאמה, להרחבה ולתחזוקה לשנים הבאות - לא משנה היכן בעולם אתם או הצוות שלכם עשויים להיות.