גטרים/מקבעים. רוע. ונקודה

מאמר מאת אגור בוגנקו 19 בספטמבר 2014 | פורסם ב: Core Java הדיון הישן הזה נפתח על ידי אלן הולוב במאמרו המפורסם, עוד בשנת 2003, מדוע שיטות גטר ו-seter הן רעות - הן גטרים/מקבעים אנטי-דפוס והאם עלינו להימנע מהם, או שמא זה משהו שאנחנו' בטוח שיהיה צורך בתכנות מונחה עצמים. אני אוסיף את שני הסנטים שלי לדיון הזה. התמצית של הטקסט שלהלן היא זו: מגפרים וסטרים הם נוהג גרוע; למי שמשתמש בהם אין תירוץ. אבל שוב, כדי למנוע אי הבנה, אני בכלל לא מציע שיש להימנע משימוש ב-get/set בכל מקום אפשרי. לא. אני אומר שאפילו לא נתת להם להתקרב לקוד שלך . מה דעתך על האמירה הזו? ראוי לתשומת לבך? האם אתה משתמש בדפוס get/set כבר 15 שנים והאם אתה ארכיטקט ג'אווה מוערך? ואתה אפילו לא רוצה להקשיב לשטויות האלה מאדם זר? ובכן... אני מבין את הרגשות שלך. כך הרגשתי עד שנתקלתי בספרו של דיוויד ווסט "חשיבת אובייקט" – זה הספר הטוב ביותר על תכנות מונחה עצמים שקראתי אי פעם. אז בבקשה. תירגע ותנסה להבין מה אני מנסה להסביר. נושא המחלוקת ישנם מספר טיעונים נגד "מקבלים" (שם אחר ל-getters ו-seters) בעולם מונחה עצמים. וכולם טיעונים נכונים מאוד. בואו נסתכל עליהם במהירות. שאל, אל תספר : אלן הולוב אומר, "אל תבקש מידע שאתה צריך כדי לבצע עבודה; 'בקש' מהישות שיש לה את המידע הזה לעשות את העבודה עבורך." עיקרון האנקפסולציה הפר : אובייקט יכול להיות מופרד על ידי אובייקטים אחרים מכיוון שהם מסוגלים להטמיע כל נתונים לתוך האובייקט, באמצעות קובעים. אובייקט פשוט לא יכול להכיל את מצבו שלו בצורה מאובטחת מספיק מכיוון שכל אחד יכול לשנות את המצב הזה. נתגלו פרטי יישום : אם אתה יכול לקבל אובייקט אחד מאובייקט אחר, אז אנחנו מסתמכים יותר מדי על פרטי היישום של האובייקט הראשון. אם מחר זה ישתנה (לדוגמה, סוג התוצאה), אז נצטרך לשנות את הקוד. כל ההצדקות לעיל בהחלט הגיוניות, אבל זה מפספס את הנקודה החשובה ביותר. תפיסה שגויה בסיסית רוב המתכנתים מאמינים שאובייקט הוא מבנה נתונים עם שיטות. אני מצטט את מאמרו של בוז'ידאר בוז'נוב: גטרים וקבעים אינם מרושעים. אבל רוב האובייקטים שעבורם נוצרים גטרים ומגדירים פשוט מכילים נתונים. תפיסה מוטעית זו היא תוצאה של אי הבנה ענקית! אובייקטים לא "רק מאחסנים נתונים". אובייקטים אינם מבני נתונים עם שיטות מצורפות. מושג זה של "אחסון נתונים" הגיע משפות תכנות ופרוצדורליות מונחה עצמים, במיוחד C ו-COBOL. אני אחזור שוב: אובייקט הוא לא רק אוסף של רכיבי נתונים ופונקציות שמתפעלים אותם. אובייקט אינו אובייקט נתונים. מה אז? כדור וכלב בתכנות אמיתי מונחה עצמים, אובייקטים הם יצורים חיים, בדיוק כמוך וכמוני. הם אורגניזמים חיים, עם התנהגות, תכונות ומחזור חיים משלהם. האם לאורגניזם חי יכול להיות מגדיר? האם אתה יכול לחבר ("להגדיר") כדור לכלב? אל תחשוב. אבל זה בדיוק מה שקטע הקוד שלהלן עושה:

Dog dog = new Dog();
dog.setBall(new Ball());

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

Dog dog = new Dog();
Ball ball = dog.getBall();

או דוגמה אפילו יותר מגוחכת:

Dog dog = new Dog();
dog.setWeight("23kg");

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

Dog dog = new Dog();
dog.take(new Ball());
Ball ball = dog.give();

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

Dog dog = new Dog("23kg");
int weight = dog.weight();

כלב הוא אורגניזם חי בלתי ניתן לשינוי שלא יאפשר לאף אחד מבחוץ לשנות את משקלו, או גודלו, או שמו וכו'. היא יכולה "לספר", לפי בקשה, את משקלה או את שמה. אין שום דבר רע בשיטות ציבוריות החושפות שאילתות עבור מאפיינים "פנימיים" מסוימים של אובייקט. אבל שיטות אלו אינן "מקבלים" והן לעולם לא צריכות לקבל את הקידומת "קבל". אנחנו לא "יוצאים" מהכלב. אנחנו לא מבינים את שמה. אנחנו מבקשים ממנה לומר לנו את שמה. אתה רואה את ההבדל? אנחנו אפילו לא מדברים על סמנטיקה כאן. אנו מבדילים את הגישה הפרוצדורלית לתכנות מהגישה המונחה עצמים. בתכנות פרוצדורלי, אנו עובדים עם נתונים, מבצעים אותם, מקבלים אותם, מגדירים אותם ומוחקים אותם במידת הצורך. אנחנו אחראים, ונתונים הם פשוט מרכיב פסיבי. כלב הוא כלום עבורנו - הוא פשוט "מכיל נתונים". אין לה חיים משלה. אנחנו יכולים לקבל (לקבל) את כל מה שאנחנו צריכים ממנו באופן חופשי ולהכניס (להגדיר) כל מידע לתוכו. כך עובדות (עבדו) C, COBOL, Pascal ושפות פרוצדורליות אחרות. והמצב הפוך לגמרי בעולם מונחה עצמים. כאן אנו מתייחסים לחפצים כאל אורגניזמים חיים, עם תאריך לידה ורגע מוות משלהם, עם אישיות והרגלים משלהם, אם תרצו. אנחנו יכולים לבקש מהכלב לתת לנו פיסת נתונים (למשל, משקלו) והוא יכול להחזיר לנו את המידע. אבל תמיד זכרו שהכלב הוא המרכיב הפעיל. היא מחליטה מה קורה לאחר הבקשה. ובגלל זה זה שגוי לחלוטין שהשיטות של אובייקט מתחילות עם set או get. וזה אפילו לא על הפרת אנקפסולציה, כפי שאנשים רבים חושבים. זה קשור לעובדה שאו שאתה חושב כמו אובייקט או שאתה עדיין כותב COBOL עם תחביר Java. נ.ב . וכן, אתם עשויים לשאול: "מה לגבי JavaBeans, JPA, JAXB ועוד הרבה ממשקי API של Java שתלויים ב-get/set?" מה לגבי הפונקציה המובנית ברובי שמקלה על יצירת אביזרים? ובכן, מה אני אגיד לך... אין לך מזל. הרבה יותר קל להישאר בעולם הפרימיטיבי של COBOL הפרוצדורלי מאשר להבין ולאמץ את העולם המופלא של חפצים אמיתיים. P.P.S. _ שכחתי לומר, כן, הכנסת תלות דרך מקבע היא גם אנטי-דפוס נוראי. אבל עוד על זה בפוסט הבא! מאמר מקורי