עקרון הפרדת ממשק ב- Java
1. הקדמה
במדריך זה נדון בעקרון הפרדת הממשק, אחד מעקרונות ה- SOLID. ייצוג ה"אני "ב-" SOLID ", הפרדת ממשקים פירושה פשוט שעלינו לפרק ממשקים גדולים יותר לקטנים יותר.
ובכך להבטיח ששיעורי יישום לא צריכים ליישם שיטות לא רצויות.
2. עקרון הפרדת ממשק
עיקרון זה הוגדר לראשונה על ידי רוברט סי מרטין כ: "אין לכפות על לקוחות להיות תלויים בממשקים שאינם משתמשים בהם“.
מטרתו של עיקרון זה היא צמצם את תופעות הלוואי של שימוש בממשקים גדולים יותר על ידי פריצת ממשקי יישומים לקטנים יותר. זה דומה לעקרון האחריות היחידה, כאשר כל מחלקה או ממשק משרתים מטרה אחת.
תכנון יישומים מדויק והפשטה נכונה הם המפתח מאחורי עקרון הפרדת הממשק. למרות שזה ייקח יותר זמן ומאמץ בשלב התכנון של יישום ועשוי להגדיל את מורכבות הקוד, בסופו של דבר נקבל קוד גמיש.
נבדוק כמה דוגמאות בחלקים המאוחרים יותר שבהם יש לנו הפרה של העיקרון ואז נתקן את הבעיה על ידי יישום נכון של העיקרון.
3. ממשק ויישום לדוגמא
בואו נבחן מצב שיש לנו תַשְׁלוּם ממשק המשמש יישום תשלום בנק:
ממשק ציבורי תשלום {void initiatePayments (); מצב אובייקט (); רשימת getPayments (); }והיישום:
class class BankPayment מיישם תשלום {@Override public void initiatePayments () {// ...} @Override public Object Object () {// ...} @Override public רשימת getPayments () {// ...}}לשם פשטות, בואו נתעלם מהיישום העסקי בפועל של שיטות אלה.
זה ברור מאוד - עד כה, המעמד המיישם תשלום בנק צריך את כל השיטות ב תַשְׁלוּם מִמְשָׁק. לפיכך, הוא אינו מפר את העיקרון.
4. זיהום הממשק
כעת, ככל שאנו מתקדמים בזמן, ותכונות נוספות נכנסות, יש צורך להוסיף תשלום הלוואה שֵׁרוּת. שירות זה הוא גם סוג של תַשְׁלוּם אבל יש לו עוד כמה פעולות.
כדי לפתח תכונה חדשה זו, נוסיף את השיטות החדשות ל- תַשְׁלוּם מִמְשָׁק:
ממשק ציבורי תשלום {// שיטות מקוריות ... void intiateLoanSettlement (); בטל initiateRePayment (); }הבא, יהיה לנו את תשלום הלוואה יישום:
מחלקה ציבורית LoanPayment מיישמת תשלום {@Override public void initiatePayments () {throw new UnsupportedOperationException ("זה לא תשלום בנקאי"); } @Override מצב אובייקט ציבורי () {// ...} @Override public רשימה getPayments () {// ...} @Override public void intiateLoanSettlement () {// ...} @Override public void initiateRePayment () {// ...}}עכשיו, מאז תַשְׁלוּם הממשק השתנה ונוספו שיטות נוספות, כל שיעורי ההטמעה צריכים כעת ליישם את השיטות החדשות. הבעיה היא שיישומם אינו רצוי ועלול להוביל לתופעות לוואי רבות. הנה ה תשלום הלוואה מחלקת יישום צריכה ליישם את initiatePayments () ללא שום צורך ממשי בכך. וכך, העיקרון מופר.
אז מה קורה עם שלנו תשלום בנק מעמד:
בכיתה ציבורית BankPayment מיישם תשלום {@Override public void initiatePayments () {// ...} @Override public Object Object () {// ...} @Override public רשימת getPayments () {// ...} @Override public void intiateLoanSettlement () {throw new UnsupportedOperationException ("זה לא תשלום הלוואה"); } @Override public void initiateRePayment () {throw new UnsupportedOperationException ("זה לא תשלום הלוואה"); }}שים לב שה- תשלום בנק היישום יישם כעת את השיטות החדשות. ומכיוון שזה לא זקוק להם ואין שום היגיון כלפיהם, זה פשוט זורק לא נתמךOperationException. זה המקום בו אנו מתחילים להפר את העיקרון.
בחלק הבא נראה כיצד נוכל לפתור בעיה זו.
5. יישום העקרון
בחלק האחרון זיהמנו את הממשק בכוונה והפרנו את העיקרון. בחלק זה נבדוק כיצד להוסיף את התכונה החדשה לתשלום הלוואה מבלי להפר את העיקרון.
בואו נשבור את הממשק לכל סוג תשלום. המצב הנוכחי:
שים לב בתרשים הכיתתי, ובהתייחס לממשקים בסעיף הקודם, כי ה- סטָטוּס() ו getPayments () דרושות שיטות בשתי היישומים. מצד שני, initiatePayments () נדרש רק ב תשלום בנק, וה initiateLoanSettlement () ו initiateRePayment () השיטות מיועדות רק ל תשלום הלוואה.
עם מיון זה, בואו נפרק את הממשקים וניישם את עקרון הפרדת הממשק. לפיכך, כעת יש לנו ממשק משותף:
ממשק ציבורי תשלום {מצב אובייקט (); רשימת getPayments (); }ושני ממשקים נוספים לשני סוגי התשלומים:
ממשק ציבורי בנק מאריך את התשלום {void initiatePayments (); }ממשק ציבורי הלוואה מרחיבה את התשלום {void intiateLoanSettlement (); בטל initiateRePayment (); }והיישומים בהתאמה, החל מ תשלום בנק:
class class BankPayment מיישם בנק {@Override public void initiatePayments () {// ...} @Override public Object Object () {// ...} @Override public רשימת getPayments () {// ...}}ולבסוף, המתוקן שלנו תשלום הלוואה יישום:
מחלקה ציבורית LoanPayment מיישמת הלוואה {@Override public void intiateLoanSettlement () {// ...} @Override public void initiateRePayment () {// ...} @Override public Object Object () {// ...} @Override רשימה ציבורית getPayments () {// ...}}עכשיו, בואו נסקור את דיאגרמת הכיתה החדשה:
כפי שאנו רואים, הממשקים אינם מפרים את העיקרון. היישומים אינם חייבים לספק שיטות ריקות. זה שומר על ניקיון הקוד ומפחית את הסיכוי לבאגים.
6. מסקנה
במדריך זה בדקנו תרחיש פשוט, בו חרגנו לראשונה מעקרון הפרדת הממשק וראינו את הבעיות שסטייה זו גרמה. ואז הראינו כיצד ליישם את העיקרון בצורה נכונה על מנת להימנע מבעיות אלה.
במקרה שאנו עוסקים בממשקי מורשת מזוהמים שאיננו יכולים לשנות, דפוס המתאם יכול להיות שימושי.
עקרון הפרדת הממשק הוא מושג חשוב בעת תכנון ופיתוח אפליקציות. הקפדה על עקרון זה מסייעת להימנע ממשקים נפוחים בעלי אחריות מרובה. בסופו של דבר זה עוזר לנו לעמוד גם בעקרון האחריות היחידה.
כמו תמיד, הקוד זמין ב- GitHub.
