1 Abstract Classes האם קיים אובייקט בשם רהיט? האם קיים אובייקט בשם כלי תחבורה? האם קיים אובייקט בשם כלי כתיבה? האם קיים אובייקט בשם אדם? האם קיים אובייקט בשם צורה? האם במציאות היומיומית שלנו מושגים אלו הינם אובייקטים?

2 Abstract Classes האם קיים אובייקט בשם רהיט?, לא! במציאות היומיומית רהיט אינו אובייקט כי אם סיווג. שולחן, כסא, ארון, מדף, מיטה וכו' הינם אובייקטים, המכנה המשותף של כולם שהם רהיטים. האם קיים אובייקט בשם כלי תחבורה?, לא! במציאות היומיומית כלי תחבורה אינו אובייקט כי אם סיווג. מכונית, מטוס, אופניים, אופנוע וכו' הינם אובייקטים, המכנה המשותף של כולם שהם כלי תחבורה. האם קיים אובייקט בשם צורה?, לא! במציאות היומיומית צורה אינה אובייקט כי אם סיווג. עיגול, מלבן, משולש, ריבוע הינם אובייקטים, המכנה המשותף של כולם שהם צורות.

3 Abstract Classes החשיבה האנושית מתבססת על סטריאוטיפים. סטריאוטיפ, משמעותו, ידע מוקדם. המוח האנושי מסווג עצמים למשפחות/קטגוריות. כאשר בן האנוש נוקב בשמו של עצם מסויים, בני שיחו שולפים את הידע המוקדם שיש להם על אותו העצם. ללא תכונה זו השיח האנושי לא יכול היה להתקיים. לדוגמה: כאשר אדם מספר על המכונית החדשה שהוא רכש, הוא אינו צריך להסביר מה זה מכונית, לבני שיחו יש ידע קודם על מכוניות. אם החשיבה האנושית לא היתה מתבססת על ידע מוקדם שרכשנו, אותו מסכן היה צריך להסביר מה זה מכונית, מה זה רכישה, מה זה חנות, מה זה כסף וכו'. האם ניתן להביא תכונה זו לידי ביטוי גם לעולם התיכנות מונחה העצמים?

4 Abstract Classes ב- OOP ניתן להגדיר מחלקות אבסטרקטיות. הגדרה מחלקות אבסטרקטיות הינן מחלקות שלא ניתן לייצר מהן אובייקטים והן משמשות כבסיס לגזירה בלבד. במקרים בהם יש צורך להגדיר מחלקות בסיס לאובייקטים ממשיים ניתן להגדירם כמחלקות אבסטרקטיות. לדוגמה: במציאות לא קיימת יישות בשם צורה. ניתן לראות בצורה כסטריאוטיפ. בתוכנית גראפית יש משמעות חשובה למחלקה בסיסית בשם צורה. אין טעם לאפשר הקצאת אובייקט ממחלקה צורה כי אין לה משמעות קונקרטית. ניתן למנוע זאת על ידי הגדרת המחלקה צורה כמחלקה אבסטרקטית.

5 Abstract Classes class App { static void Main(string[] args) { Base b1 = new Base(); Base b2 = new Derived(); }  בכל מקרה שבו מוגדרת מחלקה בסיסית ואין צורך או אין היגיון לאפשר הקצאת אובייקטים ממחלקה זו, נקפיד להגדירה כמופשטת.

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

7 Abstract Method דוגמה: בקוד שבדוגמה, אין צורך לספק מימוש במחלקת הבסיס ולכן נעדיף להגדירה כמתודה אבסטרקטית. abstract class Shape { public abstract decimal CalcArea() } class Circle:Shape { public override decimal CalcArea() { … } } class Rectangle:Shape { public override decimal CalcArea() { … } } class Triangle:Shape { public override decimal CalcArea() { … } }

8 Abstract Method כל המחלקות הנגזרות חייבות לממש את המתודות האבסטרקטיות שהוגדרו במחלקת הבסיס. abstract class Shape { public abstract decimal CalcArea() } class Circle:Shape {... } class Rectangle:Shape { public override decimal CalcArea() { … } } class Triangle:Shape { public override decimal CalcArea() { … } } שגיאת קומפילציה.

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