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