הועלה לאתר:  
מספר עמודים: 53
הורדת המסמך בגרסה להדפסהלהורדת המסמך בשלמותו

תכנות מונחה עצמים

מאמר מאת: ניר אדר

4.2.1. סיווג שפות

מספר מושגים:

  • ערך (value): אוסף ביטים המייצג מצב של עצמים.
  • סוג (type): משמעות לאוסף הביטים המהווים ערך. ניתן להגיד שסוג זהו מנגנון לפירוש המשמעות של ערך. בנוסף – טיפוס מגדיר ערכים שהם חוקיים וערכים שהם לא חוקיים עבורו.
  • משתנה (variable): שם לתא בזיכרון שיכול להתקין ערך.

למה בעצם אנחנו צריכים לדבר על ערכים וסוגים כאשר אנחנו מדברים על הורשה?

נניח שיש לנו את הביטוי a + b. נשאל: איזה פעולה תבוצע? אם a, b הינם שלמים, יתבצע חיבור בשלמים. אם a, b הם מספרים מסוג float יתבצע חישוב נקודה צפה. אם הם מחלקות, ייקרא

ה-operator+ שהוגדר עבורם.

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

סיווג שפות לפי חשיבות הסוגים:

  • Strongly Typed Languages: הסוג מחובר חזק אל הערך. לא ניתן לשבור את הקשר במסגרת השפה. דוגמאות לשפות: ML, Eiffel, Modula.
  • Weakly Typed Languages: לערכים יש סוגים מתאימים, אבל המתכנת יכול לשבור או להתעלם מהסוג. שפות: C, Turbo-Pascal.
  • Untyped Languages: לערכים אין סוג מוגדר. שפות לדוגמא: Assembly, Lisp, ....

סיווג שפות לפי זמן אכיפת הסוגים:

  • Dynamic Typing: חוקי הסוגים נאכפים בזמן ריצה. למשתנים אין סוג המשוייך אליהם. דוגמא: PROLOG, Smalltalk.
  • Static Typing: חוקי הסוגים נאכפים בזמן ההידור. לכל משתנה קיים סוג המתאים לו. שפות: C, פקסל, Eiffel, ML.



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

בשפת C אפילו הביטוי הבא חוקי, וזאת כי הסוגריים הופכים לפעולת החיבור:

int *p;

3[p];

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

ה-NEXT לכתובת הקודמת, ובכך להשיג רשימה דו כיוונית בעלות של רשימה חד כיוונית.

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

לפיכך – לפי הגישה של OOP, המנסה להפריד בין המימוש לבין הממשק, טיפוסיות חלשה היא בהחלט דבר לא חיובי.

תגיות המסמך:

לפרק הקודם4.2. מערכות סוגים ו-Strict Inheritance
לפרק הבא4.2.2. Static Strong Typing
מאת: ניצן

Borland style vptr

לפי מה שאני מכיר:
"חסרון בגישה זו: גם כאשר איננו משתמשים ב-dynamic binding – אנחנו משלמים במקום"
לא נכון , עבור מחלקה A שאין לה מתודות דינמיות לא יווצר כלל המצביע, ולמשל עבור מחלקה B שיורשת מA פשוט נוסיף בהתחלה את המצביע, ואחרי הבלוק של A את שאר האינפורמציה של B . וככה לא משלמים על מה שלא משתמשים ועקרונות C++ נשמרים.
מה שכן באמת הcasting קצת יותר מסובך....
שיתוף:
| עוד