המושג מונחה עצמים מתייחס לשני הבטים של פיתוח תוכנה. פן אחד הוא שחלוקת איזורי פיתוח מבוסס על אובייקטים מהעולם האמיתי, ופן שני מתייחס למחלקות שממנו מייצרים אובייקטים.
אנסה להתייחס לשני הבטים אלו, ואיך דרכם אנחנו מסוגלים לבנות מערכות טובות יותר.
בפיתוח תוכנה יש חשיבות גדולה בבניית מערכת שקל לתחזק ולהרחיב. רוב תוכנות עוברים שינויים מזמן לזמן, עד כדי כך, שאם המערכת שלכם לא משתנה, כנראה שהגיע הזמן לחפש מקום עבודה בטוח יותר. כשיש שינויים, השאיפה היא שהם ייעשו בצורה הכי קלה, והכי פחות כואבת. יש כמה עקרונות שאנחנו יכולים לאמץ שיעזרו לנו להכניס שינויים שלא יכאבו, אבל הבסיס הוא לזהות את החלקים שישתנו, ואת החלקים שיש סיכוי טוב שיישארו יציבים.
נשלח ב-19/9/2011 17:58
אחריות מוגדר מה שאובייקט צריך לעשות מיוזמתו, ותפקיד זה הפעולות שאובייקט מתבקש על ידי אחרים לעשות. אם הגדרנו שתפקידו של כלי כתיבה היא להתריע חודשיים לפני תום תקופת חיי המדף שלו, אז נוכל להגדיר תפקידו לחשב את המחיר שלו. GET ו SET של ה-ATTRIBUTES של האובייקט הם לא באמת תפקידים. בכדי להגן על המאפיינים מפני שינוי לא רצוי מבחוץ, מגדירים את רוב ה-ATTRIBUTES כ- PRIVATE, ומאפשרים גישה דרך ה-ACCESSORS, ו - MUTATOR.
תפקיד צריך להיות משהו יותר רחב.
לפעמים אנחנו מתקשים למצוא למחלקה תפקיד ואחריות. זה נובע משתי סיבות, א) מרחב הבעיה לא מספיק בהיר ונהיר לנו. ב) אנחנו מנסים להכניס למחלקה אחת יותר מהביט עסקי אחת.
לדוגמא, אני יכול להגדיר את תפקיד העט לדעת לאיזה ספק לפנות במקרה ויש בו תקלה. אני יכול להגדיר את תפקיד העט להיות מסוגל לענות "כמה עטים יש בסטוק?" אלו שני תחומי אחריות, שקצת סותרים אחד את השני, ובהמשך נסביר למה.
לסיכום, אובייקט הוא הפשטה של המציאות, שיש לו זהוי, מצב והתנהגות, ומלחקה הוא הפשטה של האובייקטים, שהמשותף לו הוא היכולות ומאפיינים (ATTRIBUTES) שמאפשרים לאובייקט את המצב והנתהגות שלו. החלוקה או איחוד לכמה מחלקות או למחלקה אחת, תלוי בהגדרת תפקיד ואחריות מיוחד לכל מחלקה.
נשלח ב-19/9/2011 17:49
מנתחמערכות כתב:
ועכשיו נגיע למחלקה.
אם אובייקט הוא הפשטה של המציאות, שיש בה "מצב", "התנהגות", וזהות, אז המחלקה הוא ההגדרה שמאפשרת את היכולות והתכונות האלו.
מחלקה היא הפשטה של אובייקטים, שיש להם את הגדרת התכונות המשותפות שמאפשרות את המצבים ויכולות, וכל אובייקט ואובייקט שונה בערכים בפועל של התכונות האלו.
אז בדוגמא שלנו, בכלי כתיבה של חנות יש מחלקה כלי כתיבה, שהוגדרו בתוכו את ה-ATTRIBUTES האלו
עלותמחיר
חיי מדף
שם ספק
ואילו OPERATIONS יהיו למחלקה עט?
לזה נצטרך להגדיר את תחום התפקיד והאחריות של המחלקה.
אם למחלקה אין שום תחום אחריות, אז אין לו התנהגות, והוא סך הכל STRUCT, מבנה נתונים.
בכדי לזכות בשם מחלקה, אני צריך לתת לו התנהגות, ותחום אחריות.
אז נוכל להגדיר שכלי כתיבה חייבים לדעת האם חיי מדף שלהם תקפים להיום, ואם לא הם חייבים לדווח.
זה די מצחיק לחשוב על עט ששוכב בחנות והוא קם לתחייה לצעוק "היי, חיי מדף שלי נגמרו!!!"
אבל בתוכנה אפשר לעשות הכל.
סתתתתתם.
אמרנו שאובייקט הוא הפשטה של המציאות, לא המציאות ממש.
אבל איך טוש מחיק מסוגל לדעת האם חיי מדף שלו נגמרו?
והאם זה מה שאנחנו רוצים, שאחרי שאני כבר לא יכול למכור אותו הוא יתריע?
אז כנראה שנצטרך להוסיף לו עוד ATTRIBUTE תאריך יצור, וכנראה שנשנה את האחריות שלו, להתריע חודשיים לפני שפג חיי מדף שלו.
זה יתן לבעל החנות מספיק זמן לעשות מבצע "שתים במחיר אחד", ולהיפטר מהם שלא במחיר הפסד.
לסיכום, למחלקה חייבת להיות תפקיד ואחריות.
בניתיים הגדרנו מה זה אחריות, בהמשך נסביר מה זה תפקיד.
נשלח ב-12/9/2011 07:18
ליטאי613 כתב:
נשמע ממש כואב לעשות שינויים.
כשתנסה, תבין.
נשלח ב-12/9/2011 00:17
מנתחמערכות כתב:
המושג מונחה עצמים מתייחס לשני הבטים של פיתוח תוכנה. פן אחד הוא שחלוקת איזורי פיתוח מבוסס על אובייקטים מהעולם האמיתי, ופן שני מתייחס למחלקות שממנו מייצרים אובייקטים.
אנסה להתייחס לשני הבטים אלו, ואיך דרכם אנחנו מסוגלים לבנות מערכות טובות יותר.
בפיתוח תוכנה יש חשיבות גדולה בבניית מערכת שקל לתחזק ולהרחיב. רוב תוכנות עוברים שינויים מזמן לזמן, עד כדי כך, שאם המערכת שלכם לא משתנה, כנראה שהגיע הזמן לחפש מקום עבודה בטוח יותר. כשיש שינויים, השאיפה היא שהם ייעשו בצורה הכי קלה, והכי פחות כואבת. יש כמה עקרונות שאנחנו יכולים לאמץ שיעזרו לנו להכניס שינויים שלא יכאבו, אבל הבסיס הוא לזהות את החלקים שישתנו, ואת החלקים שיש סיכוי טוב שיישארו יציבים.
נשמע ממש כואב לעשות שינויים. ומאמר יפה
נשלח ב-11/9/2011 23:45
כן, היום אחזתי ששפת OOP מתאימה לVB , , ועוד ולא רק לשפת #C ... לא נורא עם החזרה שלי על החומר נדע עוד מהנשכחות...
נשלח ב-11/9/2011 05:53
פונץ, אכן מדובר ב-C#, אבל באותו מידה בC++, או בג'אווה. כשעושים ניתוח, או לומדים מושגי יסוד, יש יתרון מובהק לראות את הדברים. הדרך לראות את הדברים הוא על ידי שימוש בשפה ויזואלית, שהיא UML. התרגום מ-UML, לכל שפת תיכנות נעשה כמעט בלי מאמץ.
נשלח ב-7/9/2011 22:45
אוף, נראה לי לפי התכנה שציינת שלא הבנתי כלל על מה מדובר...:( חשבתי שאתה מתאר את OOP כלומר #C הלא כן..?! כי זה ממש אותו דבר-לבנתיים!
נשלח ב-7/9/2011 08:49
ניתוחית, הגדרת מחלקה כזו עבור הצרכים שהגדרתי, היא בעייתי מאד. אין שום יחודיות בכלי כתיבה מעבר לכל פריט אחר בחנות. לכל פריט יש חיי מדף וכו'. הייתי צריך להגדיר מחלקה בשם "פריט", ולתת לו את התכונות אלו.
אם נרצה לסנן ולחפש פריטים לפי קטגוריה ותת קטגוריה, נוסיף למחלקה "פריט" שני מאפיינים אלו, "קטגוריה" ו "תת קטגוריה".
וכך כל אובייקט מסוג פריט שהוא בפועל כלי כתיבה נציב קטגוריה = "כלי כתיבה", ונציב תת קטגוריה = "עט".
גם בזה יש בעייה ניתוחית, אבל נשמע מה דעתכם בינתיים.
אני מתכונן להעלות צילומי מסך של מחלקות ואובייקטים אלו. אשתמש בתוכנה ENTERPRISE ARCHITECT, שהוא כלי UML הכי זול ונפוץ בחברות בארץ.
אני גם לא מבינה כלום ממה שכתבת.. אתה יכול לכתוב בצורה מוחשית הרבה יותר למשל משהו כמו: אוביקט = כסא מחלקה = מאפייני כסא
ועכשיו נגיע למחלקה. אם אובייקט הוא הפשטה של המציאות, שיש בה "מצב", "התנהגות", וזהות, אז המחלקה הוא ההגדרה שמאפשרת את היכולות והתכונות האלו. מחלקה היא הפשטה של אובייקטים, שיש להם את הגדרת התכונות המשותפות שמאפשרות את המצבים ויכולות, וכל אובייקט ואובייקט שונה בערכים בפועל של התכונות האלו.
אז בדוגמא שלנו, בכלי כתיבה של חנות יש מחלקה כלי כתיבה, שהוגדרו בתוכו את ה-ATTRIBUTES האלו
עלותמחיר חיי מדף שם ספק
ואילו OPERATIONS יהיו למחלקה עט?
לזה נצטרך להגדיר את תחום התפקיד והאחריות של המחלקה.
אם למחלקה אין שום תחום אחריות, אז אין לו התנהגות, והוא סך הכל STRUCT, מבנה נתונים.
בכדי לזכות בשם מחלקה, אני צריך לתת לו התנהגות, ותחום אחריות. אז נוכל להגדיר שכלי כתיבה חייבים לדעת האם חיי מדף שלהם תקפים להיום, ואם לא הם חייבים לדווח. זה די מצחיק לחשוב על עט ששוכב בחנות והוא קם לתחייה לצעוק "היי, חיי מדף שלי נגמרו!!!" אבל בתוכנה אפשר לעשות הכל.
סתתתתתם. אמרנו שאובייקט הוא הפשטה של המציאות, לא המציאות ממש.
אבל איך טוש מחיק מסוגל לדעת האם חיי מדף שלו נגמרו? והאם זה מה שאנחנו רוצים, שאחרי שאני כבר לא יכול למכור אותו הוא יתריע?
אז כנראה שנצטרך להוסיף לו עוד ATTRIBUTE תאריך יצור, וכנראה שנשנה את האחריות שלו, להתריע חודשיים לפני שפג חיי מדף שלו. זה יתן לבעל החנות מספיק זמן לעשות מבצע "שתים במחיר אחד", ולהיפטר מהם שלא במחיר הפסד.
לסיכום, למחלקה חייבת להיות תפקיד ואחריות. בניתיים הגדרנו מה זה אחריות, בהמשך נסביר מה זה תפקיד.
נשלח ב-7/9/2011 05:29
מה הקשר בין אובייקט למציאות? אוביקט הוא הפשטה של המציאות, שבה אני מדגיש ומתייחס לחלק מהתכונות רלוונטיות, ומתעלם מהתכונות שלא רלוונטיים. . . . . ההפשטה תלוי בממרחב הבעיה, ומאד סובייקטיבי בעיני המאבחן / המנתח . . . .
לדוגמא, אם יש לי כמה כלי כתיבה, ואני רוצה להגדיר את האבייקטים הפיזיים בתוכנה.
אז אם יש לי כמה כלי כתיבה פיזיים, ויש לי צורך להגדיר אובייקט כזה, מה יהיו התכונות שלהם?
אם התוכנה הוא עבור חנות לכלי כתיבה, יהיה לאובייקט מחיר, חיי מדף, שם ספק וכו'
אם התוכנה הוא עבור מורה, אז התכונות העיקריות הן מחיק / לא מחיק, עובד / לא עובד.
נשלח ב-5/9/2011 17:06
יישר כוח..
נשלח ב-5/9/2011 16:57
אני אענה על שאלות, אבל מעדיף לעשות את זה באשכול נפרד. גם ככה יש לי בימים אלו עומס עבודה גדול, ואין לי זמן לכנס ולכתוב את הכמה דקות ביום באמצע העבודה. כתבתי לעצמי למייל, ואשתדל להעלות את זה בקרוב.
השאיפה שלי היא שכל מי שרוצה ללמוד מושגים אלו יוכל לעשות את זה. אני אפתח מייל שיהיה אפשר לשלוח לי שאלה, אפילו אם אני לא נכנס לכאן.
