שדות פרטיים ב-JavaScript: התחביר # לפרטיות במחלקות

הבעיה עם קו תחתון

במשך שנים לא היו ב-JavaScript שדות פרטיים. המוסכמה הייתה להוסיף למאפיין קידומת של קו תחתון ולקוות שכולם יכבדו אותה:

class Counter {
    constructor() {
        this._count = 0;
    }
    increment() {
        this._count++;
    }
}

const c = new Counter();
c.increment();
console.log(c._count);   // 1 - nothing stops this
c._count = 999;          // or this
console.log(c._count);   // 999

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

JavaScript מודרנית פתרה את זה עם שדות פרטיים אמיתיים, שמסומנים ב-#.

ה-# הופך אותו לפרטי

מוסיפים לשם השדה את הקידומת # בהצהרה ובכל מקום שבו ניגשים אליו:

class Counter {
    #count = 0;

    increment() {
        this.#count++;
    }

    get value() {
        return this.#count;
    }
}

const c = new Counter();
c.increment();
c.increment();
console.log(c.value);    // 2

מתוך המחלקה, this.#count עובד כרגיל. מבחוץ, הוא פשוט לא קיים:

class Counter {
    #count = 0;
    increment() { this.#count++; }
}

const c = new Counter();
// console.log(c.#count);   // SyntaxError at parse time
console.log(c["#count"]);   // undefined - not the same property

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

מתודות ו-getters פרטיים

לא רק שדות אפשר לסמן כפרטיים. מתודות, getters ו-setters מקבלים כולם את הקידומת #:

class BankAccount {
    #balance = 0;

    deposit(amount) {
        this.#assertPositive(amount);
        this.#balance += amount;
    }

    get balance() {
        return this.#balance;
    }

    #assertPositive(n) {
        if (n <= 0) throw new Error("Amount must be positive");
    }
}

const acc = new BankAccount();
acc.deposit(100);
console.log(acc.balance);    // 100
// acc.#assertPositive(5);   // SyntaxError

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

איברים סטטיים פרטיים

גם איברים סטטיים יכולים להיות פרטיים. מוסיפים להם # באותה צורה:

class IdGenerator {
    static #nextId = 1;

    static generate() {
        return IdGenerator.#nextId++;
    }
}

console.log(IdGenerator.generate());   // 1
console.log(IdGenerator.generate());   // 2
// console.log(IdGenerator.#nextId);   // SyntaxError

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

מחלקות יורשות לא רואות אותם

זה מפתיע אנשים שמגיעים מ-Java או מ-C#. השדות הפרטיים של JavaScript הם פרטיים למחלקה, לא פרטיים למופע. מחלקה יורשת לא יכולה להגיע לשדות הפרטיים של מחלקת האב:

class Animal {
    #name;
    constructor(name) {
        this.#name = name;
    }
    describe() {
        return `an animal named ${this.#name}`;
    }
}

class Dog extends Animal {
    bark() {
        // return `${this.#name} says woof`;   // SyntaxError
        return `${this.describe()} says woof`;
    }
}

console.log(new Dog("Rex").bark());

אין protected ב-JavaScript. אם מחלקה יורשת צריכה את הנתונים, מחלקת האב חייבת לחשוף מתודה, getter או (לעיתים רחוקות יותר) שדה שאינו פרטי. העיצוב הזה מכוון: פרטי זה באמת פרטי, והירושה לא פורצת בו חורים.

בדיקת שדה פרטי עם in

לפעמים רוצים לוודא שאובייקט באמת שייך למחלקה שלכם, מה שנקרא בדיקת מותג (brand check). האופרטור in עובד עם שמות של שדות פרטיים בתוך המחלקה:

class Wallet {
    #balance = 0;

    static isWallet(obj) {
        return #balance in obj;
    }
}

const real = new Wallet();
const fake = { balance: 100 };

console.log(Wallet.isWallet(real));   // true
console.log(Wallet.isWallet(fake));   // false

מכיוון שרק Wallet יכולה ליצור אובייקטים עם #balance, הביטוי #balance in obj הוא בדיקה אמינה לכך ש-obj הוא מופע אמיתי של Wallet. במקרי קצה מסוימים זה מהיר ובטוח יותר מ-instanceof, כי אי אפשר לזייף שדות פרטיים מבחוץ.

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

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

class Point {
    #x;
    constructor(x) { this.#x = x; }
    getX() { return this.#x; }
}

const p = new Point(5);
console.log(p.getX());       // 5

const fake = {};
// Point.prototype.getX.call(fake);   // TypeError: Cannot read private member #x

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

מתי להשתמש ב-#

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

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

השתמשו במאפיינים ציבוריים כשמשהו הוא באמת חלק מהממשק. השתמשו ב-getter (get name()) כשאתם רוצים גישת קריאה בלבד לשדה פרטי. וותרו על מוסכמת הקו התחתון: היא הייתה פתרון עוקף לחוסר שהשפה כבר השלימה.

class Temperature {
    #celsius;

    constructor(celsius) {
        this.#celsius = celsius;
    }

    get celsius() { return this.#celsius; }
    get fahrenheit() { return this.#celsius * 9 / 5 + 32; }
}

const t = new Temperature(20);
console.log(t.celsius);      // 20
console.log(t.fahrenheit);   // 68
// t.celsius = 100;          // TypeError: no setter - read-only

#celsius הוא האחסון הנסתר; celsius ו-fahrenheit הם תצוגות לקריאה בלבד. מי שמשתמש במחלקה לא יכול לקלקל את המצב הפנימי, והמחלקה חופשית לשנות בהמשך את האופן שבו היא שומרת את הערך.

הבא בתור: Prototypes

מחלקות הן בעיקר סוכר תחבירי מעל מערכת ה-prototypes של JavaScript, המודל הוותיק והבסיסי יותר שעליו השפה בנויה באמת. הבנה של prototypes מסבירה למה this מתנהג כמו שהוא מתנהג, איך ירושה עובדת באמת ומה מחלקה עושה כשהיא extends מאחורי הקלעים. זה הדף הבא.