Microsoft PowerPoint - lec2.ppt

תמליל

1 מרחב הש מות (namespace) אוהד ברזילי אוניברסיטת תל אביב

2 מה בתו כנית? לקוח וס פק במערכת תוכנה ממשקים הכרת מרחב השמות מניעת תלות פוטנציאלית בין רכיבים במערכת ע"י עיצוב חלופי של מבנה הממשקים 2 א ונ י ב רס י ט ת תל א ב י ב

3 ל קו ח וספ ק במערכת תו כנה ספק (supplier) הוא מי שקוראים לו (לפעמים נקרא גם שרת, (server לקוח (client) הוא מי שקרא לספק או מי שמשתמש בו (לפעמים נקרא גם משתמש, (user דוגמא: void do_something() // doing... בדוגמא זו הפונקציה main היא לקוחה של הפונקציה do_something() main ה יא ספקית של do_something main() do_something(); 3 א ונ י ב רס י ט ת תל א ב י ב

4 ל קו ח וספ ק במערכת תו כנה הספק והלקוח עשויים להיכתב בזמנים שונים, שונים ואז כמובן לא יופיעו באותו קובץ במקומות שונים וע"י אנש ים void do_something() // doing... supplier.cpp main() do_something(); client.cpp 4 א ונ י ב רס י ט ת תל א ב י ב

5 ל קו ח וספ ק במערכת תו כנה מנקודת מבטו של הלקוח קוד המקור של הספק עשוי לא להיות זמין כלל supplier.o main() client.cpp do_something(???); 5 א ונ י ב רס י ט ת תל א ב י ב

6 ל קו ח וספ ק במערכת תו כנה כדי לתקשר בין הספק והלקוח עליהם להגדיר ממשק,interface) מנשק) בינהם בצד הספק בצד הלקוח supplier.h void do_something(); תכנות מונחה עצמים בשפת ++C 6 אוניברסיטת תל אביב #include supplier.h main() do_something(???); client.cpp #include supplier.h void do_something() // doing... supplier.cpp

7 ל קו ח וספ ק במערכת תו כנה לאחר תהליך ההידור מקבל הלקוח גם קובץ בינארי (h.) וגם קובץ כותרות (.OBJ או (o. בצד הלקוח supplier.o בצד הספק supplier.o supplier.h void do_something(); supplier.h void do_something(); תכנות מונחה עצמים בשפת ++C 7 אוניברסיטת תל אביב #include supplier.h main() do_something(); client.cpp #include supplier.h void do_something() // doing... supplier.cpp

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

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

10 ל קו ח וספ ק במערכת תו כנה void do_something(); בצד הספק בצד הלקוח supplier.h מ מ מש ע"פ המ משק את הפ ו נקציות משתמ ש בפונקציות לפ י ה מ משק #include supplier.h main() do_something(); client.cpp #include supplier.h void do_something() // doing... supplier.cpp 10 א ונ י ב רס י ט ת תל א ב י ב

11 המודו ל Calendar // representation struct Date int d, m, y; ; cal.h // interface for users void init_date(date& d, int, int, int); // initialize d void add_year(date& d, int n); // add n years to d void add_month(date& d, int n); // add n months to d void add_day(date& d, int n); // add n days to d Date next_weekend();// returns the next weekend Date // inner use only bool valid(const Date& d) ; // checks if d is valid // global variable extern Date today; 11 א ונ י ב רס י ט ת תל א ב י ב

12 מו דו ל כמרחב שמו ת אנו רוצים מבנה תחבירי שיציין את ה"רכיביות" של Calendar מיקום כל ההגדרות באותו קובץ אינו מפורש מספיק (למשל אינו נאכף ע"י המהדר) נעטוף את ההגדרות במרחב שמות: namespace Calendar // representation struct Date int d, m, y; ; // interface for users void init_date(date& d, int, int, int); // initialize d א ונ י ב רס י ט ת תל א ב י ב

13 אופר טור השיוך :: לקוח של Calendar צריך מעת ה לציין א ת מרחב השמות בכל שימוש (כמעט) main() Date d; Calendar::Date d; // Error // OK Calendar::init_date(d,7,7,2005); init_date(d,7,7,2005); d = next_weekend() d = Calendar::next_weekend() // OK // also OK - argument- // dependent lookup // Error // OK 13 א ונ י ב רס י ט ת תל א ב י ב

14 אופר טור השיוך :: המממש של Calendar צריך גם הוא לציין א ת מרחב ה ש מות בכל מימוש // Date.c void add_year(date& d, int n) d.y += n; void Calendar::add_year(Date& d, int n) d.y += n; // Error // OK בתוך מרחב השמות א ין צ ורך לחזור על השם המ לא Date Calendar::next_weekend() Date rslt = 7,7,2005; // no need for Calendar::Date return rslt; 14 א ונ י ב רס י ט ת תל א ב י ב

15 הצהרת משתמ ש כאשר לקוח של Calendar עושה שימוש נרחב בשרותים מסוימים של,Calendar הוא יכול לחסוך את הסרבול התחבירי ע"י יבוא של שמות מסוימים מתוך המרחב (using declaration) main() using Calendar::Date; using Calendar::init_date; // using all overloaded versions Date d; // Same as Calendar::Date d; init_date(d,7,7,2005); // Same as Calendar::init_date(d,7,7,2005); d = next_weekend() // Error not imported 15 א ונ י ב רס י ט ת תל א ב י ב

16 הנחיית שימו ש כאשר לקוח של Calendar עושה שימוש נרחב בכל השרותים של,Calendar הוא יכול לחסוך את הסרבול התחבירי ע"י יבוא כל מרחב השמות directive) (using main() using namespace Calendar; Date d; init_date(d,7,7,2005); d = next_weekend() 16 א ונ י ב רס י ט ת תל א ב י ב

17 הנחיית שימו ש ייבוא מרחבי שמות רבים בשלמותם מ עקר מתוכן א ת מרחב השמות פקודה זו הוספה לשפה בעיקר כדי להקל הטמעה של קוד שנכתב מחוץ למרחב שמות לתוך מערכת התומכת בכך (כדוגמת שילוב ספריות C בתוכנית (C++ שימוש נרחב בתכונה זו מרמז בדרך כלל על התלויות הפנימיות במערכת 17 א ונ י ב רס י ט ת תל א ב י ב

18 ריבוי ממ שקים (exported) לא כל השרותים המוגדרים ב Calendar אמורים ל היות מיוצאים למשל הפונקציה Date&) bool valid(const א מורה לשמש את מממשי Calendar בלבד void Calendar::add_day(Date& d, int n) d.d += n; if (!valid(d)) // illegal date fix it לדוגמא כך: 18 א ונ י ב רס י ט ת תל א ב י ב

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

20 ריבוי ממ שקים בצד המ מ מש בצד הלקוח namespace Calendar // only exported features Calendar namespace Calendar // all features Calendar בצורה גרפית המערכת נראית כך: Calendar Calendar מ מ משים לקוחות החיצים מתארים את היחס "תלוי במימוש המוצג ע"י" 20 א ונ י ב רס י ט ת תל א ב י ב

21 ריבוי ממ שקים הפתרון שהוצג בשקף הקודם הוא פתרון פשוט וטוב החסרון העיקרי הוא שלו הוא ש- Calendar ו- Calendar מתארים שני מרחבי שמות בעלי אותו שם (ניתן להשיג זאת ע"י שימוש בקובצי h. שונים). המהדר (compiler) ההגדרות הכפולות לא יוכל ת מיד לבדוק א ת עקביות בעיה זו נפתרת כמעט תמיד ע"י שימוש במהדרים חכמים וע"י המקשר (linker) 21 א ונ י ב רס י ט ת תל א ב י ב

22 עי צ וב חלו פ י בצד המ מ מש בצד הלקוח namespace Calendar_interface using Calendar::Date; using Calendar::init_date; // for all exported operations Calendar_interface namespace Calendar // all features Calendar בצורה גרפית המערכת נראית כך: Calendar Calendar_interface מ מ משים לקוחות 22 א ונ י ב רס י ט ת תל א ב י ב

23 עי צ וב חלו פ י בעיצוב זה ברור שהמשתמשים תלויים רק בתכונ ות שיוצאו עבורם ע"י Calendar_interface (ולא יושפעו משינויים בפעולות פנ ימיות) ואולם בגישה הקונסרבטיבית שאותה אנו נוקטים, גרף התלויות מראה תלות (טרנזיטיבית) בין המשתמשים ובין Calendar נרצה למנוע מראית עין זו, ע"י עיצוב חלופי 23 א ונ י ב רס י ט ת תל א ב י ב

24 עי צ וב חלו פ י (2) בצד המ מ מש בצד הלקוח namespace Calendar // only exported features Calendar namespace Calendar // all features Calendar namespace Calendar_interface using Calendar::Date; using Calendar::init_date; // for all exported operations Calendar_interface 24 א ונ י ב רס י ט ת תל א ב י ב

25 עי צ וב חלו פ י (2) Calendar בצורה גרפית המערכת נראית כך: Calendar_interface Calendar מ מ משים לקוחות ההבדל היחיד מהגרסה הראשונה הוא הוספת ממשק הביניים Calendar_interface עדיין אנו סומכים על הקומפיילר שיעזור לנו לפתור בע יות חוסר עקביות בין ההגדרות 25 א ונ י ב רס י ט ת תל א ב י ב

26 עי צ וב חלו פ י (3) בצד הלקוח namespace Calendar_interface void init_date(date& d, int, int, int); void add_year(date& d, int n); // for all exported operations Calendar_interface void Calendar_interface::init_date(Date& d, int dd, int mm, int yy) Calendar::init_date(d, dd, mm, yy); // for all exported operations Calendar_interface implementation 26 א ונ י ב רס י ט ת תל א ב י ב

27 עי צ וב חלו פ י (3) בצורה גרפית המערכת נראית כך: Calendar_interface Calendar Calendar_interface implenetation מ מ משים לקוחות פתרון זה ממזער את התלויות במערכת זהו כנראה OVERKILL 27 א ונ י ב רס י ט ת תל א ב י ב

28 מניעת התנגשות שמות קשה להכליל את שנ י הקבצים הללו בא ותה תוכנית: // my.h: char f (char); int f(int); struct String /*... */ ; // your.h: char f(char); double f(double); struct String /*... */ ; 28 א ונ י ב רס י ט ת תל א ב י ב

29 מניעת התנגשות שמות ע כשיו קל: namespace my char f (char); int f(int); struct String /*... */ ; namespace your char f(char); double f(double ); struct String /*... */ ; 29 א ונ י ב רס י ט ת תל א ב י ב

30 שימו ש בספרי ות C // stdio.h: namespace std //... int printf (const char *... ); //... using namespace std ; 30 א ונ י ב רס י ט ת תל א ב י ב

31 שימו ש בספרי ות C ל שומרי סביבה // cstdio: namespace std //... int printf (const char *... ); // א ונ י ב רס י ט ת תל א ב י ב

32 שימוש בס פרי ות C למתנגדי שכפול הקוד // stdio.h: #include <cstdio> using namespace std; 32 א ונ י ב רס י ט ת תל א ב י ב

33 ת פ קי ד י מ רחב השמו ת לבטא קשר לוגי-רעיוני בין אוסף של פעולות למנוע ממשתמשים גישה לפעולות לא להם לחסוך למשתמש את הטירחה (התחבירית) מטרות אלו באמצעים אחרים בהשגת 33 א ונ י ב רס י ט ת תל א ב י ב

34 מרחב השמות והעו ל ם האמי תי הערה: מרח ב השמות משמש לניהול רכיבים בקנה מידה ג דול בהר בה מאלה שנתאר כאן מחלקות מייתרות למעשה את השימוש במר חב ש מות לתאור מב נה נתונים אח ד בתור מודול מרח ב שמות טיפוסי מכיל עשרות מח לקות ויותר השימוש במרחבי שמות מקובל מאוד בשפות (שם הוא נקרא (package Java ו- C# 34 א ונ י ב רס י ט ת תל א ב י ב

35 הפ ס קה