עיצוב שיעורים וממשקים (תרגום המאמר)

תוֹכֶן

1. מבוא
2. ממשקים
3. סמני ממשק
4. ממשקים פונקציונליים, שיטות סטטיות ושיטות ברירת מחדל
5. שיעורים מופשטים
6. שיעורים בלתי ניתנים לשינוי (קבוע).
7. שיעורים אנונימיים
8. רְאוּת
9. יְרוּשָׁה
10. ירושה מרובה
11. ירושה והרכב
12. כימוס
13. שיעורים ושיטות אחרונות
14. מה הלאה
15. הורד את קוד המקור

1. הקדמה

לא משנה באיזו שפת תכנות אתה משתמש (וג'אווה אינה יוצאת דופן), הקפדה על עקרונות עיצוב טובים היא המפתח לכתיבת קוד נקי, מובן וניתן לאימות; וגם ליצור אותו לאורך חיים ולתמוך בקלות בפתרון בעיות. בחלק זה של המדריך, אנחנו הולכים לדון באבני הבניין הבסיסיות ששפת Java מספקת ולהציג כמה עקרונות עיצוב במאמץ לעזור לך לקבל החלטות עיצוב טובות יותר. ליתר דיוק, אנו הולכים לדון בממשקים וממשקים המשתמשים בשיטות ברירת מחדל (תכונה חדשה ב-Java 8), מחלקות מופשטות וסופיות, מחלקות בלתי ניתנות לשינוי, ירושה, קומפוזיציה, ולעיין מחדש בכללי הנראות (או הנגישות) בהם נגענו בקצרה ב חלק 1 שיעור "כיצד ליצור ולהשמיד חפצים" .

2. ממשקים

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

package com.javacodegeeks.advanced.design;

public interface SimpleInterface {
void performAction();
}

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

package com.javacodegeeks.advanced.design;

public interface InterfaceWithDefinitions {
    String CONSTANT = "CONSTANT";

    enum InnerEnum {
        E1, E2;
    }

    class InnerClass {
    }

    interface InnerInterface {
        void performInnerAction();
    }

    void performAction();
}

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

public void performAction();
void performAction();

ראוי להזכיר שכל שיטה בודדת בממשק מוכרזת בצורה מרומזת אבסטרקטית , ואפילו הצהרות השיטה הללו שוות ערך:

public abstract void performAction();
public void performAction();
void performAction();

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

String CONSTANT = "CONSTANT";
public static final String CONSTANT = "CONSTANT";

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

class InnerClass {
}

static class InnerClass {
}

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

3. סמן ממשק

ממשק סמן הוא סוג מיוחד של ממשק שאין לו שיטות או מבנים מקוננים אחרים. איך ספריית Java מגדירה את זה:

public interface Cloneable {
}

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

public interface Serializable {
}

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

4. ממשקים פונקציונליים, שיטות ברירת מחדל ושיטות סטטיות

מאז השחרור של Java 8, ממשקים זכו לכמה תכונות חדשות מאוד מעניינות: שיטות סטטיות, שיטות ברירת מחדל והמרה אוטומטית מ-lambdas (ממשקים פונקציונליים). בסעיף הממשקים הדגשנו את העובדה שממשקים בג'אווה יכולים להצהיר רק על שיטות, אך אינם מספקים את היישום שלהן. עם שיטת ברירת מחדל, הדברים שונים: ממשק יכול לסמן שיטה עם מילת המפתח המוגדרת כברירת מחדל ולספק לה יישום. לדוגמה:

package com.javacodegeeks.advanced.design;

public interface InterfaceWithDefaultMethods {
    void performAction();

    default void performDefaulAction() {
        // Implementation here
    }
}

בהיותו ברמת המופע, ניתן לעקוף את שיטות ברירת המחדל על ידי כל מימוש ממשק, אך כעת ממשקים יכולים לכלול גם שיטות סטטיות , לדוגמה: חבילה com.javacodegeeks.advanced.design;

public interface InterfaceWithDefaultMethods {
    static void createAction() {
        // Implementation here
    }
}

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

@FunctionalInterface
public interface Runnable {
    void run();
}

מהדר Java מתייחס לממשקים פונקציונליים בצורה שונה ויכול להפוך פונקציית lambda למימוש ממשק פונקציונלי במקום בו זה הגיוני. הבה נבחן את תיאור הפונקציה הבא: 

public void runMe( final Runnable r ) {
    r.run();
}

כדי לקרוא לפונקציה זו ב-Java 7 ומטה, יש לספק יישום של הממשק Runnable(לדוגמה, באמצעות מחלקות אנונימיות), אך ב-Java 8 מספיק לספק יישום של שיטת run() באמצעות תחביר lambda:

runMe( () -> System.out.println( "Run!" ) );

בנוסף, ההערה @FunctionalInterface (ההערות יכוסו בפירוט בחלק 5 של המדריך) מרמזת שהמהדר יכול לבדוק אם ממשק מכיל רק שיטה מופשטת אחת, כך שכל שינוי שיבוצע בממשק בעתיד לא יפר הנחה זו .

5. שיעורים מופשטים

מושג מעניין נוסף שנתמך על ידי שפת ג'אווה הוא הרעיון של מחלקות מופשטות. מחלקות מופשטות דומות במקצת לממשקים ב-Java 7 והן קרובות מאוד לממשק שיטת ברירת המחדל ב-Java 8. שלא כמו מחלקות רגילות, לא ניתן ליצור מחלקה אבסטרקטית, אך ניתן לסווג אותה משנה (עיין בסעיף ירושה לפרטים נוספים). חשוב מכך, מחלקות מופשטות יכולות להכיל שיטות מופשטות: סוג מיוחד של מתודה ללא יישום, ממש כמו ממשק. לדוגמה:

package com.javacodegeeks.advanced.design;

public abstract class SimpleAbstractClass {
    public void performAction() {
        // Implementation here
    }

    public abstract void performAnotherAction();
}

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

6. שיעורים מיידיים

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

package com.javacodegeeks.advanced.design;

import java.util.Collection;

public class ImmutableClass {
    private final long id;
    private final String[] arrayOfStrings;
    private final Collection<String> collectionOfString;
}

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

public ImmutableClass( final long id, final String[] arrayOfStrings,
        final Collection<String> collectionOfString) {
    this.id = id;
    this.arrayOfStrings = Arrays.copyOf( arrayOfStrings, arrayOfStrings.length );
    this.collectionOfString = new ArrayList<>( collectionOfString );
}

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

public String[] getArrayOfStrings() {
    return Arrays.copyOf( arrayOfStrings, arrayOfStrings.length );
}

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

7. שיעורים אנונימיים

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

package com.javacodegeeks.advanced.design;

public class AnonymousClass {
    public static void main( String[] args ) {
        new Thread(
            // Example of creating anonymous class which implements
            // Runnable interface
            new Runnable() {
                @Override
                public void run() {
                    // Implementation here
                }
            }
        ).start();
    }
}

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

new Runnable() {
   @Override
   public void run() {
   }
}

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

package com.javacodegeeks.advanced.design;

public class AnonymousClass {
    public static void main( String[] args ) {
        new Thread( () -> { /* Implementation here */ } ).start();
    }
}

8. נראות

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

9. ירושה

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

package com.javacodegeeks.advanced.design;

public class Parent {
    // Everyone can see it
    public static final String CONSTANT = "Constant";

    // No one can access it
    private String privateField;
    // Only subclasses can access it
    protected String protectedField;

    // No one can see it
    private class PrivateClass {
    }

    // Only visible to subclasses
    protected interface ProtectedInterface {
    }

    // Everyone can call it
    public void publicAction() {
    }

    // Only subclass can call it
    protected void protectedAction() {
    }

    // No one can call it
    private void privateAction() {
    }

    // Only subclasses in the same package can call it
    void packageAction() {
    }
}

package com.javacodegeeks.advanced.design;

// Resides in the same package as parent class
public class Child extends Parent implements Parent.ProtectedInterface {
    @Override
    protected void protectedAction() {
        // Calls parent's method implementation
        super.protectedAction();
    }

    @Override
    void packageAction() {
        // Do nothing, no call to parent's method implementation
    }

    public void childAction() {
        this.protectedField = "value";
    }
}

ירושה היא נושא גדול מאוד בפני עצמו, עם הרבה פרטים עדינים ספציפיים לג'אווה. עם זאת, ישנם כמה כללים שקל לעקוב אחריהם ויכולים לעשות הרבה בשמירה על קוצר ההיררכיה של הכיתה. ב-Java, כל תת-מחלקה יכולה לעקוף את כל השיטות שעברו בירושה של האב שלה אלא אם כן היא הוכרזה סופית. עם זאת, אין תחביר או מילת מפתח מיוחדים כדי לסמן שיטה כנדחקת, מה שעלול להוביל לבלבול. זו הסיבה שהביאה @Override הוצגה : בכל פעם שהמטרה שלך היא לעקוף שיטה שעברה בירושה, אנא השתמש בהערת @Override כדי לציין אותה בתמציתיות. דילמה נוספת איתה מתמודדים מפתחי Java כל הזמן בעיצוב היא בניית היררכיות מחלקות (עם מחלקות קונקרטיות או מופשטות) לעומת יישום ממשקים. אנו ממליצים בחום להעדיף ממשקים על פני מחלקות או מחלקות מופשטות במידת האפשר. ממשקים קלים יותר, קלים יותר לבדיקה ולתחזוקה, וגם ממזערים את תופעות הלוואי של שינויים ביישום. טכניקות תכנות מתקדמות רבות, כגון יצירת מחלקות פרוקסי בספרייה הסטנדרטית של Java, מסתמכות במידה רבה על ממשקים.

10. ירושה מרובה

שלא כמו C++ ושפות אחרות, Java אינה תומכת בירושה מרובה: ב-Java, לכל מחלקה יכול להיות רק הורה ישיר אחד (עם המחלקה Objectבראש ההיררכיה). עם זאת, מחלקה יכולה ליישם מספר ממשקים, ולפיכך ערימת ממשק היא הדרך היחידה להשיג (או לדמות) ירושה מרובה ב-Java.

package com.javacodegeeks.advanced.design;

public class MultipleInterfaces implements Runnable, AutoCloseable {
    @Override
    public void run() {
        // Some implementation here
    }

    @Override
    public void close() throws Exception {
       // Some implementation here
    }
}

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

public class A implements Runnable {
    @Override
    public void run() {
        // Some implementation here
    }
}

// Class B wants to inherit the implementation of run() method from class A.
public class B extends A implements AutoCloseable {
    @Override
    public void close() throws Exception {
       // Some implementation here
    }
}

// Class C wants to inherit the implementation of run() method from class A
// and the implementation of close() method from class B.
public class C extends B implements Readable {
    @Override
    public int read(java.nio.CharBuffer cb) throws IOException {
       // Some implementation here
    }
}

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

package com.javacodegeeks.advanced.design;

public interface DefaultMethods extends Runnable, AutoCloseable {
    @Override
    default void run() {
        // Some implementation here
    }

    @Override
    default void close() throws Exception {
       // Some implementation here
    }
}

// Class C inherits the implementation of run() and close() methods from the
// DefaultMethods interface.
public class C implements DefaultMethods, Readable {
    @Override
    public int read(java.nio.CharBuffer cb) throws IOException {
       // Some implementation here
    }
}

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

interface A {
    default void performAction() {
    }
}

interface B extends A {
    @Override
    default void performAction() {
    }
}

interface C extends A {
    @Override
    default void performAction() {
    }
}

לדוגמה, קטע הקוד הבא לא יצליח להדר:

// E is not compilable unless it overrides performAction() as well
interface E extends B, C {
}

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

11. ירושה והרכב

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

// E is not compilable unless it overrides performAction() as well
interface E extends B, C {
}

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

public class Vehicle extends Engine {
    private Wheels[] wheels;
    // ...
}

איזה פתרון עיצובי יהיה נכון? הנחיות הליבה הכלליות ידועות כעקרונות IS-A (is) ו-HAS-A (מכיל). IS-A הוא קשר ירושה: תת-מחלקה עומדת גם במפרט המחלקה של מחלקת האב ווריאציה של מחלקת האב. subclass) מרחיבה את האב שלה. אם אתה רוצה לדעת אם ישות אחת מרחיבה אחרת, בצע בדיקת התאמה - IS -A (הוא).") לכן, HAS-A הוא קשר קומפוזיציה: מחלקה מחזיקה (או מכילה) אובייקט שברוב המקרים, עקרון HAS-A עובד טוב יותר מ-IS-A ממספר סיבות: 

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

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

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

הרעיון של אנקפסולציה בתכנות מונחה עצמים הוא להסתיר את כל פרטי היישום (כמו מצב הפעלה, שיטות פנימיות וכו') מהעולם החיצון. היתרונות של אנקפסולציה הם תחזוקה וקלות השינוי. היישום הפנימי של הכיתה נסתר, העבודה עם נתוני הכיתה מתרחשת אך ורק באמצעות שיטות ציבוריות של הכיתה (בעיה אמיתית אם אתה מפתח ספרייה או מסגרת המשמשת אנשים רבים). Encapsulation ב-Java מושגת באמצעות כללי נראות ונגישות. ב-Java, זה נחשב לשיטות עבודה מומלצות לעולם לא לחשוף שדות ישירות, רק דרך מגפרים ו-seters (אלא אם כן השדות מסומנים כסופיים). לדוגמה:

package com.javacodegeeks.advanced.design;

public class Encapsulation {
    private final String email;
    private String address;

    public Encapsulation( final String email ) {
        this.email = email;
    }

    public String getAddress() {
        return address;
    }

    public void setAddress(String address) {
        this.address = address;
    }

    public String getEmail() {
        return email;
    }
}

דוגמה זו מזכירה את מה שנקרא JavaBeans בשפת Java: מחלקות Java סטנדרטיות נכתבות על פי סט של מוסכמות, שאחת מהן מאפשרת גישה לשדות רק באמצעות שיטות getter ו-seter. כפי שכבר הדגשנו בסעיף הירושה, אנא הקפידו תמיד על חוזה הפרסום המינימלי בכיתה, תוך שימוש בעקרונות האנקפסולציה. כל מה שלא צריך להיות ציבורי צריך להיות פרטי (או מוגן/חבילה פרטי, תלוי בבעיה שאתה פותר). זה ישתלם בטווח הארוך בכך שייתן לך חופש לעצב מבלי לבצע שינויים שוברים (או לפחות למזער אותם). 

13. שיעורים ושיטות סופיות

ב-Java, יש דרך למנוע ממחלקה להפוך לתת-מחלקה של מחלקה אחרת: יש להכריז על המחלקה האחרת כסופית. 

package com.javacodegeeks.advanced.design;

public final class FinalClass {
}

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

package com.javacodegeeks.advanced.design;

public class FinalMethod {
    public final void performAction() {
    }
}

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

14. מה הלאה

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

15. הורד את קוד המקור

אתה יכול להוריד את המקור כאן - advanced-java-part-3 מקור: כיצד לעצב שיעורים an