מאמר חביב כל OOP

[orengolan]

מאמר חביב כל OOP

חוץ מהמהאמר הזה תוכלו למצוא עו מאמרים באתר שלהם.

 

[ייוניי]

אהבתי

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

Every piece of knowledge must have a single, unambiguous, and authoritative representation within a system.​

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

 

[liortm]

בגישה של מייקרוסופט שכבת ה-dal

משקפת את ריכוז המידע במקום אחד.

 

[arn0n]

חוק נוסף ששוה להדגיש

המאמר טוען כנגד צימוד דינאמי - הדוגמה לקוד שעושה זאת:

getOrder().getCustomer().getAddress().getState()​

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

getOrder().getCustomer().getAddress().getState() // Should have been: getOrder.getCustomerState()​

אני ממליץ לקרוא את שאר הלינק...

 

[ייוניי]

אני בדיוק עובד עכשיו

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