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

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

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

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

21. אילו יסודות שפה אחראים בירושה?

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

public class Lion extends Cat

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

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

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

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

   public class Cat {
      int age = 10;

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

public class Lion extends Cat {
   int age = 15;

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

super.name

22. אילו יסודות שפה אחראים לפולימורפיזם?

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

public class Cat implements Animal

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

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

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

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

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

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

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

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

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

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

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

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

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

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

doSomething(int, double, double)

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

void doSomething(int firstArg, int secondArg) throws Exception

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