עקרון אחריות יחידה בג'אווה

1. סקירה כללית

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

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

* SRP = עקרון אחריות יחידה

2. עקרון אחריות יחידה

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

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

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

מחלקה ציבורית TextManipulator {טקסט מחרוזת פרטי; TextManipulator ציבורי (טקסט מחרוזת) {this.text = טקסט; } מחרוזת ציבורית getText () {טקסט חזרה; } חלל ריק appendText (מחרוזת newText) {text = text.concat (newText); } מחרוזת ציבורית findWordAndRlace (מחרוזת, מחרוזת החלפת מילים) {if (text.contains (word)) {text = text.replace (word, replacementWord); } החזר טקסט; } מחרוזת ציבורית findWordAndDelete (מילת מחרוזת) {if (text.contains (word)) {text = text.replace (word, ""); } החזר טקסט; } חלל ציבורי printText () {System.out.println (textManipulator.getText ()); }}

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

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

מחלקה ציבורית TextPrinter {TextManipulator textManipulator; ציבורי TextPrinter (TextManipulator textManipulator) {this.textManipulator = textManipulator; } חלל ציבורי printText () {System.out.println (textManipulator.getText ()); } חלל ריק printOutEachWordOfText () {System.out.println (Arrays.toString (textManipulator.getText (). split (""))); } public void printRangeOfCharacters (int startingIndex, int endIndex) {System.out.println (textManipulator.getText (). substring (startingIndex, endIndex)); }}

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

3. כיצד עקרון זה יכול להטעות?

הטריק של יישום SRP בתוכנה שלנו הוא לדעת את האחריות של כל כיתה.

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

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

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

זה מוביל אותנו לנקודה הבאה.

4. לכידות

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

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

בואו נחזור לשלנו TextManipulator שיטות כיתה:

... חלל ריק appendText (מחרוזת newText) {text = text.concat (newText); } מחרוזת ציבורית findWordAndRlace (מחרוזת, מחרוזת החלפת מילים) {if (text.contains (word)) {text = text.replace (word, replacementWord); } החזר טקסט; } מחרוזת ציבורי findWordAndDelete (מילת מחרוזת) {if (text.contains (word)) {text = text.replace (word, ""); } החזר טקסט; } ...

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

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

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

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

מרטין היץ 'ובדהד מונטזרי הציגו את LCOM4, ​​שסונארק מדד זמן מה, אך מאז פחת.

5. מסקנה

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

כמו תמיד, הקוד זמין ב- GitHub.


$config[zx-auto] not found$config[zx-overlay] not found