הדגמה של Singleton - חלק 4
Communication.Instance ואז קוראים ל-Login. הגישה נשארת נוחה, והמופע נוצר רק כשצריך.new Communication() מחוץ למחלקה נכשלת בזמן הקומפילציה. זה מסמן למתכנת שיש מופע אחד בלבד.Instance צריכים להיות מחוברים. אם משתמש בטעות יוצר מופע מתוך המחלקה עצמה, הבעיה נשארת.פרקי ההרצאה: הדגמה של Singleton - חלק 4
תמלול ההרצאה: הדגמה של Singleton - חלק 4
הטקסט המלא של הדקות הראשונות בהרצאה «הדגמה של Singleton - חלק 4» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
אוקיי אז אנחנו רוצים עכשיו להמשיך אנחנו רוצים לפתור את התרגיל שהמצאנו או יותר נכון אנחנו רוצים לממש סינגלטון כמקובל עכשיו מה זה אומר כמקובל אז באופן כללי כשמדובר בדיזיין פאטרנס יש ספר שהוא התנ״ך של הדיזיין פאטרנס נעבור אליו זה הספר הראשי תיבות שלו שנהוגות זה שזה ראשי תיבות gang of four, כי יש לו ארבעה
כותבים. שם הספר הוא design patterns elements of reusable object oriented software. אז זה הפתרון, ככה נראה הפתרון המקובל של סינגלטון, וזה מה שאנחנו רוצים לממש, וזה מה שיפתור לנו את הבעיה.
אז איך נראה סינגלטון בעצם? אז לסינגלטון, כמו שאנחנו רואים, יש לו שדה סטטי כאן ועוד שדה סטטי כאן. השדה הסטטי הראשון היא פונקציה שקוראים לה אינסטנס והיא פשוט מחזירה שדה שקוראים לו יוניק אינסטנס, שזה השדה הזה, זה הרעיון.
אז בואו נזכור את זה בראש תוך כדי שאנחנו מתחילים לממש ואז גם נסביר למה זה עונה על כל הצרכים. אז בואו נעבור לקוד שלנו. בואו נעבור קודם לציור, אז אמרנו שאנחנו רוצים מצד אחד לוודא שיש רק Communication 1 מקסימום.
זאת אומרת, עלול להיות 0 מקסימום 1, אבל אנחנו רוצים גמישות שבקלות יחסית אפשר לעבור ל-2 ויותר. אוקיי, נעבור עכשיו ל-code שלנו, ואז כרגע Static אומר שאי אפשר להקצות יותר מ-1.
עכשיו, אם אני אסיר את המילה Static, זה לא אומר שעכשיו אני יכול, אם אני מסיר את המילה סטטיק, אז אני F6. הוא אומר בילד סקסידד, הקונסטרקטור הזה עדיין זמין, אבל אני כבר יכול להקצות הרבה קומיוניקיישן.
הבעיה היא שעדיין כל הפונקציות, כן? לוגין היא רק דוגמה לאחת מהפונקציות, אבל כל הפונקציות שלי כרגע, מכיוון שעד לרגע זה המחלקה כולה הייתה סטטיק, זה אומר שכל השדות בהכרח עד לרגע זה היו סטטיים.
אז אם אני מסיר את המילה סטטיק מההגדרה של המחלקה, עדיין כל הפונקציות הן סטטיים. עכשיו אני צריך לעבור פונקציה-פונקציה ולהסיר את המילה סטטיק.
ואני לא יודע אם... ואז אני צריך לבדוק. זה שינוי מסיבי. וגם יכול להיות שיהיו לי פה עוד משתנים, עוד שדות. את כולם, את כל המילה סטטיק, אני חייב להסיר, ואז להתחיל לבחון את הקלאס, לראות אם הוא עובד, הוא בנוי לעבודה של אובייקטים שצריך לשבת לבחון את זה.
אז מה שאנחנו רוצים זה מראש לבנות עם כמה שפחות המילה סטטי. אז בעצם אנחנו רוצים לבנות את קומוניקיישן כאובייקט.
בואו נסיר את המילה סטטי וגם את הסטטי קונסטרקטור נסיר יפה ונחזור נעשה f6 ואז נראה שיש לנו שגיאה אין אובייקט כן דאבל קליק אז אין אובייקט או אני אפסיק על זה כאן אין אובייקט רפרנס is required for non static field.
יוצא שעכשיו הפונקציה לוגין היא כבר לא סטטית אז היא לא זמינה כשדה של המחלקה. יפה, אז מה שאנחנו באמת רוצים, אנחנו רוצים לבטל את הקריאה הזו, במקום אנחנו רוצים לעבור למודל של Communication C שווה New Communication ו-C נקודה והנה כבר יש לנו את הפונקציה לוגין שהסבנו אותה מסטטית ללא סטטית.
יפה, בואו ננסה את זה להריץ. בואו נשים אולי כאן breakpoint ונריץ F5. יפה, אני לוחץ על לוגין, אז אנחנו מגיעים לברייק פוינט, F11, F11, F11, יפה, אנחנו מגיעים לפונקציה לוגין והכל נראה מצוין.
טוב, אבל F5 ונסגור, אבל בזה אין חידוש, נכון? כי כרגע המילה סטטיק בכלל לא מופיעה בשום מקום ולמעשה כרגע קומיוניקיישן הוא קלאס רגיל ככל הקלאסים, אני יכול ליצור הרבה קלאסים כאלה.
יתרה על כך יוצא שבכל פעם שאני לוחץ על הוגין אני מייצר קלאס קומיוניקיישן חדש. אם שוב נריץ נלחץ על הוגין אנחנו מגיעים לברייק פוינט ומייצרים קלאס חדש ומפעילים אותו.
יפה, אבל אם שוב אני לוחץ על הוגין אני שוב יוצר קלאס חדש. אני בכל לחיצה יוצר קלאס חדש וזה לא מה שאנחנו רוצים. נניח שזה לא מה שאנחנו רוצים. נניח שבזמן תכנון המערכת קיבלנו החלטה שלא, שאנחנו רוצים רק אחד כזה מקסימום. זאת אומרת, אם וכאשר לוגין מופעלת, אז אמור להיווצר בפעם הראשונה נגיד קומיוניקיישן
חדש, אבל בפעם הבאה שלוגין מופעלת לא. לא אמור להיווצר אחד חדש, הוא אמור להיות ממוחזר. נניח שאנחנו רוצים אחד מקסימום, אבל עם מינימום שימוש במילה סטטיק, ולא להגדיר את המחלקה כולה כסטטיק.
אז את זה איך עושים? אז שוב אנחנו בראש שומרים את הציור הזה, ועכשיו נממש ונבין מה אנחנו עושים. אז אנחנו רוצים, נכון? אנחנו רוצים בעצם שיהיה רק קומיוניקיישן אחד, אבל כאן אני יוצר כל פעם אחד חדש, אז אני לא רוצה להשתמש בניו בכל קליק.
אז מה כן? אז מה שאני יכול לעשות זה בעליית המערכת להגדיר משתנה גלובלי שהוא יהיה סטטי, כן, כרגע אנחנו לא נלך עם הפתרון. בשלב ראשון לא נלך עם הפתרון של GOF.
כן, זה נקרא לזה פתרון GOF, פתרון גנג אוף וואר. פתרון GOF הוא הקלאסי לפתרון סינגלטון. לא נתחיל ממנו, נתחיל מפתרון יותר, נבנה את זה בשלבים.
אז אני יכול להגדיר כזה אחד גלובלי, ואליו לפנות. אז בואו נעשה קונטרול X או קונטרול Z, בואו פשוט נעביר אותו, שתראו איך אני מעביר אותו, פשוט אני אעביר אותו החוצה.
אז יש לי עכשיו את השיא הזה, נעשה שיפט F5, נעצור את הריצה. אז יש לי עכשיו רכיב קומיוניקיישן שאני מקצה אותו. שימו לב שאני מקצה אותו כשדה של החלון הראשי.
זאת אומרת, אם אין לי חלון ראשי, אז אין לי אותו, אבל בסדר, לעת עתה זה בסדר. חלון ראשי, לא דאגנו שיהיה רק אחד. זאת אומרת, אם בטעות נוצר חלון ראשי נוסף, אז יהיה לנו גם קומוניקיישן שני, ועדיין לא מנענו מהאפשרות שמישהו ייצור קומוניקיישן נוסף.
זאת אומרת, עדיין אני יכול ליצור קומוניקיישן נוסף. גם זו דרך, כן? זה בעצם, אני יוצר קומוניקיישן חדש ופונה ללוגין של הקומוניקיישן החדש.
זאת אומרת, לא מנענו יצירה של הרבה קומוניקיישנס, אבל בסדר, זו רמה של פתרון, שבחלון עצמו יש לי קומוניקיישן אחד, אליו אני פונה, זאת אומרת, פתרנו את הבעיה שאני יוצר הרבה קומוניקיישן, שבכל פנייה ללוגין אני יוצר קומוניקיישן חדש.
אבל לא פתרנו את הבעיה שבטעות מישהו כן ייצור קומוניקיישן חדש. את זה לא פתרנו. לא פתרנו שמישהו ייצור קומוניקיישן חדש.
אבל אם את זה אני מריץ, אני אראה שרק קומוניקיישן אחד נוצר, ורק כאשר החלון נוצר, שזה גם בעייתי, כי אם החלון נוצר, זה עדיין לא אומר שאני רוצה תקשורת.
כי יכול להיות שהוידאו קונפרנס שלי הוא לא רק בנוי לתקשורת, יכול להיות שהוא גם בנוי לנגן קבצים שהוקלטו, ואז בכלל לא צריך לעשות לו גין, לא צריך להתחבר לשרת.
יכול להיות שיש עוד דברים שאני יכול לעשות עם האפליקציה שלי, שאני יכול ליצור חלון ולא ליצור תקשורת. ואז, אם אני בכל זאת כופה יצירת רכיב תקשורת בעליית החלון, יוצא שאני מעכב את עליית החלון, שזה פוגע בביצועים של המערכת.
כן, בן אדם לוחץ על האייקון, הוא מצפה מיד לראות את החלון מופיע, ובפעם הראשונה החלון מתעכב, כי הוא גם צריך ליצור רכיב תקשורת. אוקיי, אז זה פחות, זה פחות טוב, יש עם זה קצת בעיות.
אז בעצם מה שאנחנו אומרים זה, אנחנו רוצים לעכב עד כמה שאפשר את יצירת החלון, סליחה, יצירת התקשורת רק כאשר הבן אדם לוחץ על לוגין.
אנחנו רוצים לעכב את זה רק ללחיצה של הלוגין. אז מה שאני יכול לעשות זה, אני יכול לשים כאן נקודה פסיק ולשאול אם c שווה null רק אז להקצות קומיוניקיישן חדש.
אוקיי, ואז יוצא שאני יוצר קומיוניקיישן חדש רק כאשר בן אדם לוחץ על לוגין. זאת אומרת, לעליית החלון סתם, החלון לא הולך להתעכב ביצירת קומיוניקיישן חדש, כן? זה לא יצירת קומיוניקיישן חדש, זו יצירת משתנה של המחלקה, משתנה של האובייקט של המחלקה, שרק יודע להצביע אל קומיוניקיישן.
אבל הוא בעצמו צ'ופצ'יק, הוא בעצמו בסך הכל מספר בתים, הוא רק מצביע, אין פה הקצאה משמעותית, ההקצאה היא זניחה. אז זה לא הולך לעכב את עליית החלון.
אז את עליית החלון שהיא תעלה, שהחלון יעלה מהר בפעם הראשונה פתרנו בעזרת ה-if הזה. אבל עדיין מישהו בטעות עלול לכתוב כזה קוד ולייצר הרבה קומוניקיישן, שזו לא הארכיטקטורה שרצינו.
אבל בסדר, זה עוד שלב בנדבך. עוד שלב בפיתוח, זה עוד נדבך בפיתוח. עכשיו, בעיה נוספת היא שקומוניקיישן כרגע הוא שדה של החלון, אז יוצא, כמובן המערכת תלויה בחלון, אין לי את השדה הזה ללא החלון, וגם כשיש לי את החלון, אז השיא הזה נגיש, אבל בעצם אולי הוא בכלל לא נוצר.
זאת אומרת, הוא לא נגיש, הוא פרייבט, אבל בוא נגיד, אוקיי, הוא פרייבט, הוא לא נגיש, אז בוא נהפוך אותו לנגיש גם עבור רכיבי תוכנה אחרים.
עכשיו רכיבי התוכנה האחרים, נחזור לציור כמו האודיו רקורדר הוידאו רקורדר גם הם יכולים לגשת לקומוניקיישן קומפונט דרך המיין ווינדו הפכנו את הקומוניקיישן קומפונט לשדה במיין ווינדו אז יוצא שאם יש מיין ווינדו אז רכיבי התוכנה האלה יכולים לגשת אל השדה אבל השדה הזה הוא רק מצביע ואם הם ייגשו אל השדה הזה יכול להיות
שהם ייגשו בעצם אליו כאשר הוא נל יפה אז מה שאפשר לעשות זה אולי את הבדיקה הזו לשים במקום אחד. כך שכל רכיב תוכנה שרוצה לגשת אל C יפעיל את הקוד הזה וייצור קומיוניקיישן.
והקוד הזה יהיה זמין תמיד. זאת אומרת, ללא תלות ביצירה של מיין ווינדו.