בחינת שאלות ותשובות מראיון עבודה למשרת מפתח Java. חלק 3

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

20. אילו מרכיבים בשפה מאפשרים אנקפסולציה?

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

21. אילו מרכיבים בשפה מאפשרים תורשה?

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

public class Lion extends Cat

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

1. לקרוא לבנאי של מעמד-על. לדוגמה, למחלקה Cat יש משתנה שם פנימי שיש לאתחל בבנאי. בבנאי כיתת Lion , זה ייראה כך:

   public Lion(final String name) {
      super(name);
   }

2. להתייחס לשדות ולשיטות של ההורה. לדוגמה, בכיתה Cat , יש לנו שדה גיל אתחול :

   public class Cat {
      int age = 10;

אבל יש לנו את אותו שדה אתחול ב- Lion :

public class Lion extends Cat {
   int age = 15;

ואם באובייקט אריה אנו רוצים להתייחס למשתנה הגיל של אובייקט האב, אז עלינו לעשות זאת באמצעות super :

super.name

22. אילו אלמנטים בשפה אחראים לפולימורפיזם?

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

public class Cat implements Animal

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

23. מה זה SOLID? תן דוגמאות

SOLID הוא ראשי תיבות של חמשת עקרונות עיצוב OOP הבסיסיים של רוברט מרטין. S (עקרון אחריות יחידה) : קובע שלכיתה צריכה להיות מטרה/אחריות אחת בלבד. במילים אחרות, לא כדאי ליצור שיעורים שעושים הכל. אם תעשה זאת, תוכל לשחזר את תבנית האנטי "חפץ אלוהים". אם יש לך אובייקט Cat , צריכות להיות לו שיטות רק לאינטראקציה עם הפונקציונליות הפנימית שלו, אבל הוא לא אמור להכיל שום היגיון עסקי שאינו קשור למופע זה. למשל, מנגנון כלשהו לאחסון חפצים מסוג זה. יש להעביר את הפונקציונליות הזו (חיצונית לישות של חתול ) למחלקות או שירותים אחרים, שתפקידם לספק את ההיגיון העסקי עבור האובייקטים המתאימים. O (עקרון פתוח-סגור) : עיקרון זה מתואר באופן הבא: ישויות תוכנה (מחלקות, מודולים, פונקציות וכו') צריכות להיות פתוחות להרחבה אך סגורות לשינוי. לדוגמה, נניח שאנו זקוקים לפונקציונליות דומה לפונקציונליות של מחלקה Cat הקיימת אך מעט שונה מהפונקציונליות . במקום לשנות את הפונקציונליות של המחלקה Cat ובכך לשבור את הקוד בכל מקום בו הוא כבר בשימוש, נוכל להשתמש בירושה או בהרכב . לפיכך, אנו משיגים את המטרה שלנו לשנות את הפונקציונליות של מחלקת החתול , ואנו עושים זאת מבלי לשנות את המחלקה עצמה ומבלי לשבור דבר. L (עקרון ההחלפה של ליסקוב) : זהו עקרון ההחלפה של ברברה ליסקוב. העיקרון אומר שפונקציה שלוקחת סוג בסיס צריכה להיות מסוגלת להשתמש בתתי סוגים של סוג בסיס זה מבלי לדעת מה קורה. לדוגמה, כיתת החתול שלנו צריכה להיות ניתנת להחלפה בכל אחד מהצאצאים שלה, נניח, אריה , מבלי לשנות מהותית את ההתנהגות שלו. ההיגיון הכללי (ההתנהגות) נשאר זהה, אך פרטי היישום של פונקציונליות ספציפית משתנים. I (עקרון הפרדת ממשקים) : עיקרון זה קובע שעדיף שיהיו ממשקים מיוחדים (ממוקדים צר) רבים מאשר אוניברסלי אחד. לדוגמה, נניח שמפתח מיישם ממשק כלשהו. הם צריכים רק אחת מהשיטות שלו, אבל לממשק יש עוד תשע שיטות שאינן מתייחסות להיגיון של השיטה הנדרשת. במקרה זה, המפתח יצטרך ליישם עשר שיטות ממשק, תשע מהן מיותרות עבורו! במקום זאת, עדיף ליצור עשרה ממשקים שונים שתוכל ליישם לפי הצורך. ובכן, אם לא עשרה, אז כמה, כל אחד עם שיטות הקשורות באופן הדוק למטרה היחידה של הממשק. D (עקרון היפוך תלות): העיקרון אומר שמודולים ברמה גבוהה יותר לא צריכים להיות תלויים במודולים ברמה נמוכה יותר. עיקרון זה גם קובע: "הפשטה לא צריכה להיות תלויה בפרטים. פרטים צריכים להיות תלויים בהפשטות". עלינו לבנות את ההיגיון שלנו על ידי התייחסות לממשקים ולהעביר אובייקטים קונקרטיים של מחלקות שמיישמות את הממשק הנדרש. לדוגמה, נניח שיש לנו ממשק Cat וכמה יישומים, למשל, Lion ו- HouseCat . אנו בונים את ההיגיון שלנו במיוחד כדי ליצור אינטראקציה עם ממשק החתול . רק אז אנחנו מחליפים את הממשק ביישום ספציפי ( Lion או HouseCat ), אבל לא להיפך.

24. מה זה מחלקה, אובייקט וממשק?

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

25. מהו שיעור POJO? תן דוגמה לשיעור כזה

POJO (Plain Old Java Object) הוא אובייקט מחלקה פשוט שאינו יורש מאף מחלקה ספציפית ואינו מיישם שום ממשקי שירות מעבר לאלו הדרושים למודל העסקי. במילים אחרות, שיעור POJO הוא רק שיעור ללא דרישות מיוחדות. הדרישה היחידה היא היעדר פעמונים ושריקות שונות הקשורות למסגרת מסוימת. ככלל, מחלקות אלו אינן יורשות מחלקות אחרות (למעט מחלקות POJO באותה חבילה), אינן מיישמות ממשקים (לעיתים נעשה חריג עבור ממשקי סמנים מהספרייה הסטנדרטית כגון Serializable או Cloneable ), אין להשתמש בהערות , ואינם תלויים בספריות של צד שלישי. שימו לב של- POJO יכולות להיות שיטות המכילות לוגיקה עסקית ובנאים מכל סוג. אם נאפשר הערות שאינן משנות את הסמנטיקה של המחלקה (כלומר הערות שהיעדרן אינו משנה את המטרה או הלוגיקה של האובייקט), אזי POJOs יכולים לכלול גם ישויות JPA ואובייקטי DTO שהוסרו מ- XML או JSON , שהכללים שלהם הם המפורטים בהערות. דבר נוסף שכדאי לזכור לגבי שיעורי POJO הוא שמוטב לעקוף את שיטות השווים וה- hashCode שלהם מכיוון שזה יכול לעזור להם למלא את תפקידם טוב יותר. דוגמה לשיעור POJO :

public class User {
   private Long id;
   private String firstName;
   private String lastName;
   private Long age;

   public User(final Long id, final String firstName, final String lastName, final long age) {
       this.id = id;
       this.firstName = firstName;
       this.lastName = lastName;
       this.age = age;
   }

   public Long getId() {
       return this.id;
   }

   public String getFirstName() {
       return this.firstName;
   }

   public String getLastName() {
       return this.lastName;
   }

   public Long getAge() {
       return this.age;
   }

   @Override
   public boolean equals(final Object o) {
       if (this == o) return true;
       if (o == null || this.getClass() != o.getClass()) return false;
       final User user = (User) o;
       return Objects.equals(this.id, user.id) &&
               Objects.equals(this.firstName, user.firstName) &&
               Objects.equals(this.lastName, user.lastName) &&
               Objects.equals(this.age, user.age);
   }

   @Override
   public int hashCode() {
       return Objects.hash(this.id, this.firstName, this.lastName, this.age);
   }
}

26. אילו אלמנטים מחלקה יכולה להכיל?

מחלקה יכולה להכיל את האלמנטים הבאים:

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

27. ספר לנו על ירושה בג'אווה. מהם הספציפיות של מילת המפתח העל?

למעלה, דיברתי בעבר על ירושה ועל מילת המפתח העל בג'אווה. אזכיר עוד כמה נקודות חשובות:

1. אנחנו יכולים לרשת רק מחלקה אחת: לג'אווה אין ירושה מרובה ב-Java. עם הופעתן של שיטות ברירת המחדל ב-Java 8, הצהרה זו תהפוך לשנויה במחלוקת מאוד.
2. גם שיטות ותחומים פרטיים עוברים בירושה. פשוט לא ניתן לגשת אליהם מכיתת הילד (אבל אם, למשל, יש לנו שדה פרטי ויש לנו מגברים וקובעים ציבוריים או מוגנים , אז נוכל להשתמש בהם כדי לגשת לשדה).
3. שיעורי הגמר אינם ניתנים בירושה.
4. לא ניתן לעקוף שיטות סופיות (אך הן יכולות לעבור בירושה ולהעמיס).
5. שיטות ומשתנים סטטיים אינם עוברים בתורשה (מכיוון שהם מחוברים למחלקות, לא לאובייקטים).
6. כאשר יורשים מחלקות מופשטות, יש ליישם את השיטות המופשטות שלהן, או שגם כיתת הילד חייבת להיות מופשטת.
7. אם יש בנאים שאינם ברירת מחדל בהורה, יש לעקוף אותם בכיתה הילד (אבל @Override לא כתוב מעליהם).
8. אתה יכול להרחיב את משנה הגישה לשיטות שנדחקו במחלקת הילד: פרטי -> ברירת מחדל -> מוגן -> ציבורי .
שיטות שנדרוסות בכיתה הילד יכולות לזרוק חריגים צרים יותר, למשל: Exception -> IOException -> FileNotFoundException.

28. מהן חתימות השיטה? ספק דוגמאות לחתימות נכונות ולא נכונות

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

doSomething(int, double, double)

דוגמה לחתימה שגויה:

void doSomething(int firstArg, int secondArg) throws Exception

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