בפוסט הקצר הזה, אני רוצה לדון בבעיית מידול קטנה - ואיך אפשר לפתור אותה בצורה סבירה, וכיצד בצורה טובה.
ניסיתי לבחור אובייקטים מעולם שמובן לכולם. כמה רדוד מצדי... בחרתי בדוגמה לא מקורית: צורות גאומטריות.
לצורך הדיון אני אציג רק ממשקים, ולא אתעכב על חלוקה ל Interfaces ו Concrete classes (שהוא באמת משני לדיון).
בואו נתחיל.
הבעיה
דמיינו שיש לנו תוכנה שדורשת לצייר צורות, את הצורות מתארים ע"פ הממשק הבא:
מיקום הצורה (x, y), לצורך הדיון - הוא לא חלק מההגדרה.
משהו לא מריח כאן טוב בהגדרה הזו...
יש משהו מאוד פרוצדורלי, ולא כ"כ OO בהגדרה הזו: ה Path נראה כמו מרכיב זיהוי מרכזי בהתייחסות לצורה - אבל הוא מיוצג כתכונה כשאר התכונות.
למשל: אנו יכולים לייצר Line עם fillColor - מצב לא תקין. הכוונה להשתמש ב fillColor היא רק עבור פוליגון.
"אז שישתמשו ב fillColor רק בפוליגון!" - כמובן שאנחנו יכולים להגדיר לאובייקט תכונה חסרת משמעות ולהתעלם ממנה - אבל זו איננה פרקטיקה מומלצת, במיוחד באובייקטים מורכבים יותר מהדוגמה הפשוטה הזו. "זו אינה סגולה לחיים ארוכים" - ניתן גם לומר. במערכות מורכבות, חלק גדול ממה שעלול לכשול - אכן יכשול, ולכן כדאי מאוד לצמצם את מרחב הדברים שיכולים לכשול.
כיצד ניתן למדל את האובייקט בצורה יותר נכונה?
יש לכם איזה רעיון?!
פתרון ראשון
אני יכול לדמיין שלחלק מהאנשים "יציק בעין" ש Point ו Line הם חסרי תכונות, אולי יכולנו לקצר את הקוד יותר?
עזבו. הבעיה כאן היא הפוכה: כנראה שקיצרנו קצת יותר מדי.
בואו נבחן את המודל שלנו עכשיו:
- DRY (חוסר חזרה על הקוד) - מצב מצוין. אין באמת הרבה מה לקצר את הקוד.
- הכמסה (encapsulation) - מצב בינוני. על הפשטת העל יש כמעט את כל התכונות, מה שאומר שכל מי ש"אוחז" ברפרנס ל BaseShape יקבל גישה לכל התכונות הללו. האם יש לזה צורך? או האם "שיתפנו" יותר מדי?
הנחת היסוד היא שהשימוש האחיד באובייקטים הוא בעזרת הפונקציה ()draw. נניח: רוצים לרוץ על מערך ולצייר את כולם, אך בכל מקרה, כל גישה מעמיקה יותר דורשת את בדיקת הטיפוס ו downcasting. - אין נזק מיידי באי-הכמסה ("אז שלא ישתמשו בזה! מה הבעיה?!") - אבל זה זרז לשימוש לא מבוקר בתכונות הללו. מפתח שמקבל הצעה לשימוש בתכונה ב autocomplete של ה IDE - לעתים רחוקות ישאל את עצמו אם נכון היה שהאובייקט יחשוף תכונה זו, או האם בכלל נכון להשתמש בה.
- כל מפתח יכול להיכנס לאובייקט ולשנות את כל שדות האובייקט ל Public - אבל זה סייג המעורר הערכה מחודשת על נכונות הפעולה (ברוב, התקין, של המקרים).
- אמינות המודל למציאות / פשטות הבנה (presentation) - הרבה יותר טוב, אך עדיין ישנם עיוותים.
- הסרנו את ה Path כתכונה, ופתרנו את הבעיה בה fillColor זמין להיכן שאינו רלוונטי - שזה מצוין.
- שמות המשתנים אינם טובים. הם "פשרה" עבור "שימוש חוזר בקוד" / או סתם מכח האינרציה - פשרה לא טובה.
כשאנחנו ממדלים אובייקטים במערכת אנו משרתים כמה צרכים:
- אנו מספקים את הצורך הבסיסי של המערכת ביישות לאחסן בה נתונים / להגדיר פונקציות. לחלופין זה היה יכול להיות מערך גלובאלי של נתונים. זו חובה כדי שהקוד יעבוד - אך זה קו האפס מבחינת הנדסת תוכנה.
- אנו מתארים כוונה / רעיון - שאנו רוצים להנחיל לשותפנו לבסיס-הקוד (להלן Presentation), ובתקווה שקבענו את הכוונה / רעיון בצורה טובה ואמינה לעולם העסקי הרלוונטי.
- אנו מגבילים את חשיפת הידע במערכת, בעזרת הכמסה - אם אנחנו עובדים לפי מודל Object Oriented.
- כן, פרקטיקה טובה של קוד, היא לא לשכפל קוד (DRY = Don't Repeat Yourself) - אבל זו לא ממש מטרה בהגדרת אובייקט.
בפועל, הפרקטיקה של DRY (מסיבות כאלו ואחרות) מוטמעת היטב בקרב אנשי-תוכנה, הרבה יותר חזק מפרקטיקות לא-פחות חשובות כמו Encapsulation או פרקיטקות מידול. התוצאה: מודלים קצרים יותר בשורות קוד - אך פחות עמידים לאורך זמן, ולאורך כמות שינויים שעומדים לעבור עליהם.
כדי לחדד מדוע האובייקטים בדוגמה שלנו אינם ממודלים בצורה טובה, נשטח שנייה את האובייקטים מהיררכיית שבה הם בנויים, ונציג אותם כפי שיופיעו ב run-time, או למשל - ב IDE כאשר אנו מקבלים המלצות שימוש ב autocomplete:
אם אנו בוחנים האובייקטים, אחד אחד - אלו לא אובייקטים כפי שהיינו מגדירים לו היו בלתי-תלויים.
בדוגמה הזו - העיוות הוא בשמות המשתנים, אך בדוגמאות מורכבות יותר יכול להיות מדובר בחתימות של פונקציות שאינן רלוונטיות או מדויקות, פונקציות לא קשורות, וכו'.
שמות המשתנים לא משפיעים נכונות התוכנה ברגע ההרצה - רק כיצד, וכמה נכון, התוכנה תתפתח לעתיד.
חשבו על זה כמו הכנת מצגת ("פרזנטזציה"): המטרה היא להעביר מסר שאנשים יבינו ויזכרו, ואף יפעלו לפיו. מי שמנוסה במצגות בוודאי יודע שהעברת מסר הוא נושא קשה, ולא כל האנשים שיהיו בפרזנציה יבינו את כל מה שרצינו להעביר.
הפרזנטציה של האובייקטים בדוגמה זו היא לא מוצלחת במיוחד. המסר לא חד, ולא מדויק.
פתרון שני
אתם בוודאי רואים שהאובייקטים מתוארים עכשיו בצרה טובה יותר, כאשר אנחנו מנתקים מעט מהקשר ביניהם - ומגדירים אותם אחד אחד.
עבור Point, הרבה יותר מדויק להסביר שתכונה מסוימת היא קוטר (או לחלופין זה יכול היה להיות רדיוס) - ולא "line width", שמשאיר מקום לפרשנות. בוודאי שיותר טבעי לי לחשוב על color ולא "line color" - כי אין קו בנקודה.
ב Polygon יותר מדויק לדבר על Border ולא Line, עניין של דייקנות - שיכולה להשתלם מאוד לאורך חיי-מערכת.
שיתפנו בין האובייקטים רק את מה שהכרחי: הפונקציה ()draw (לצורך ריבוי-צורות).
כאשר נרצה לעשות פעולה מיוחדת על קו, נשאל אם זהו קו - ונוכל להתייחס אליו ספציפית, ובצורה חדה ומדויקת.
אם כל השימוש המשותף בין אובייקטים הוא אחסון / העברה של רפרנס אליהם - זה גם יהיה סופר-לגיטימי שהממשק המשותף לא יכיל שום תכונה / פונקציה - ויהיה רק ממשק מזהה. יש אנשים שעדיין לא מרגישים נוח עם זה - וחבל.
היתרון היחידי של הפתרון הקודם היה צמצום של כמה שורות קוד - כאין וכאפס מול מודל ברור יותר.
ממשקים הוא כלי שתכליתו היא PolyMorphism (ריבוי-צורות): התייחסות אחידה לאובייקטים שונים ע"פ מכנה משותף משמעותי. אל תתלו עליהם משימות של Code-Reuse, כי זה לרוב ייגמר בפשרה לא-משתלמת..
הורשה הוא קודם-כל כלי מידול - לתיאור מודל ומציאות מסוימת, ורק אח"כ כלי עבור שימוש-חוזר בקוד (תכונה שגם זוכה ללא-מעט ביקורת). גם כאן, חשוב יותר לתאר מודל ולשקף למתכנתים האחרים את מטרת ואופי האובייקט - מאשר לחסוך כמה שורות קוד.
סיכום
בחרתי בדוגמה פשוטה מאוד, שלא מייצגת מורכבות אמיתית - אך אני מקווה שהצלחתי להעביר את הרעיון. מתוך ניסיון לחסוך קוד - אנו נוטים לעוות את המודל שלנו וליצור אובייקטים "ממוצעים" שלא מעבירים כוונה בצורה חדה, ופתוחים יותר למצבים בלתי תקנים.
DRY היא פרקטיקה חשובה מאוד - אבל יותר באזור של תוכן הפונקציות: יש כמה שורות קוד שחוזרות על עצמן? הקפידו להוציא אותן לפונקציה משותפת.
יש משתנים כפולים (או state כפול כלשהו)? אבוי - היפטרו מהעותקים מיד! ("data duplication is the mother of all Evil").
זכרו, שגם במקרים כאלו - DRY לא תמיד נכון. אם יש 5 שורות קוד שחוזרות על עצמן - אך מבטאות צרכים שונים, כנראה שלא כדאי לשתף אותן. אחד הצרכים עתיד להשתנות - ו coupling בין מימוש הצרכים, יקשה על השינוי הזה.
(הפתרון פשוט: פיצול הפונקציה ל-2 גרסאות, אחת לכל צורך - אבל הרבה פעמים אנו מפספסים את זה, ומסבכים את המערכת).
ייתכן ואתם שואלים את עצמכם "אם זה שיעור מס' 8 בהורשה - מהו שיעור 7? ". טוב, נו - זו לא הייתה כותרת מדויקת. ניסיתי לבטא שזה שיעור חשוב ב Object-Oriented (ולאו דווקא הורשה), אבל לא השיעור הראשון והחשוב ביותר. וגם לא הבסיסי ביותר. אני מדמיין אותו ... כאיפשהוא כשיעור מספר 8, מבלי מחויבות גבוהה לדיוק.
שיהיה בהצלחה!
אין תגובות:
הוסף רשומת תגובה