וקטורים, Hashtables ורשימות

-      הקדמה

-     ממשק רשימות

-     תוכנית דוגמא לרשימות

    -   חלקי קוד מעניינים בתוכנית רשימות

    -   רישום תוכנית לתוכנית רשימות

                     -   מחלקת וקטור

-   Hashtable מחלקת 

-    תוכנית דוגמא

-   סקירה  

הקדמה

השיעורים הקודמים עסקו במבני מידע שאתה צריך ליצור בעצמך. Java  מספקת מספר מבני נתונים בהם תוכל להשתמש ללא צורך ליצור מבנים משלך. המחלקות המעניקות מבנים אלה מוכלות בחבילת java.util. בשיעור זה, נתעניין במחלקת וקטור, מחלקת Hashtable, ובממשק רשימות.

חבילת ה- java.util מעניקה בנוסף מחלקת מחסנית, אבל על פי ספרים אחדים בנושא, היא אינה מתנהגת בדרך בה היינו מצפים שמחסנית תתנהג (לא בדקתי זאת בעצמי). בפרט, מחלקת מחסנית כנראה מרחיבה את מחלקת הוקטור דבר המאפשר לאתחל אובייקט ממחלקת חסנית, ואז לגשת לפונקציות של מחלקת וקטור אשר מפרות את התנהגות ה- LIFO לה אנו בדרך כלל מצפים.

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

ממשק רשימות

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

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

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

·  להחזיק בצורה רציפה את כל האובייקטים המאוחסנים באובייקט העובר רישום (למעשה אנו מחזיקים פוינטרים לאובייקטים מכיוון שב-Java , פוינטרים לאובייקטים, ולא האובייקטים עצמם מאוחסנים בתוך אובייקטים אחרים).

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

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

מחלקה אשר מיישמת ממשק רשימות צריכה להעניק הגדרה עבור שתי הפונקציות הבאות אשר הוכרזו בממשק.

public boolean hasMoreElements()   public Object nextElement()

 

היתרונות של ממשק רשימות באים לידי ביטוי כאשר למחלקה העוסקת בסטים של אובייקטים יש יכולת לספק  אובייקט של מחלקה אשר מיישם את ממשק הרשימות (אובייקט רשימות) בעל יכולת לבצע רישום של אובייקט במחלקה אשר עוסק בסטים של אובייקטים.

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

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

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

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

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

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

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

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