תקשורת בין UI ו SOCKETים

[MasterDK]

היי יש לי בעית DESIGN כרגיל.

השפה היא JAVA אבל זה לא ממש משנה לשאלה שלי.

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

1. Network Client - זה הצד שאחראי להרכיב את החבילות, לשלוח אותם ולקבל תשובות (חיוביות או שליליות).

2. GUI Client - זה החלק האינטרקטיבי של הלקוח שארחאי לספק ממשק למשתמש בשביל להפעיל את ה NC (ולא רק, לא כל פעולה שהמשתמש יעשה ב GUI חייבת להיות מתורגמת לשליחת מידע ברשת).

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

הכל היה יכול להיות פשוט אם התקשרות לא הייתה דו כיוונית אבל היא כן, כלומר כאשר יש ERROR/SUCCESS ה NC צריך להודיע על זה למשתמש, וכאשר המשתמש לוחץ על LOGIN לדוגמא ה GUI אמור להודיע על זה ל NC.

בשביל לממש את התקשורת ביניהם חשבתי על שתי דרכים:

1. GUI יממש אינרפייס מסויים נקרא לו UiReactor, ו NC יממש אינרפייס מסויים נראה לי NetwrokReactor. בעת יצירת ה GUI הוא יקבל רפרנס ל NR, ובעת יצירת ה NC הוא יקבל רפרנס ל UIR. ואז התקשרות היא פשוט קריאה למתודות מהאינטרפייס בכל צעד.

2. להכניס קומפונט שלישי נקרא לו BRIDGE. בדרך הזו ה GUI לא ידע על NC ו NC לא ידע על GUI אבל שניהם ידעו על "הגשר". גם במקרה הזה ה GUI ו ה NC יממשו אינרפייסים מסויימים שהגשר יקבל רפרפנס אליהם מה שיאפשר לו להעביר הודעות בין ה NC וה GUI. אומנם צצה פה עוד בעיה איך ה GUI ו NC יתקשרו עם ה BRIDGE? פתרון א' זה שהם יקבלו רפרנס לאינטרפייס שהגשר יממש (ופה אני מגיע למבנה של שיטה 1 רק על תוספת קומפונט שלם) ופתרון ב' ה BRIDGE יהיה SINGLETON ובכך יוכלו ה NC וה GUI לגשת אליו ולשלוח הודעות אחת בין השני.

שתי הפתרונות נראים לי גרועים למרות שהפתרון עם ה BRIDGE נראה אלגנטי יותר.

אשמח לעצות!

תודה רבה מראש.

[ktbnus]

אתה בכיוון הנכון, אבל קצת לא מדוייק, http://en.wikipedia.org/wiki/Observer_pattern .

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

[MasterDK]

תודה קראתי את זה, אבל זה לא בדיוק מה שאני צריך.

observer זה אחד שמודיע לאלו שנרשמו לקבל ממנו הודעות.

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

[ktbnus]

observer מאפשר לאובייקט המוכל לתקשר עם האובייקט שמכיל אותו מבלי ליצור dependency circle. האובייקט המכיל יכול לתקשר עם האובייקט המוכל בלי קשר. למה בדיוק אתה צריך ששניהם יהיו observers?

[MasterDK]

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

in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods.

לא כתוב כאן כלום על זה שהאוייבטק המוכל מתקשר בצורה כלשהיא עם האובייקט המכיל אותו.

[ktbnus]

לשם הבהרה, כשאמרתי observer התכווני ל observer pattern ולא לאובייקט.

איך הכפתור, מודיע לframe או panel שלחצו עליו? הרי הוא מוכל בו - אבל הוא ( הכפתור) לא יודע את זה. הוא עושה את זה בדיוק בצורה הזו.

יש לך שני אינטרפייים IOBSERVER ו ISUBJECT.

הframe ממש את Iobserver ו הכפתור ISubject

ISubject מכיל מטודות להוספה והסרה של OBSERVERS ומתודה updateObservers.

ה IOBSERVER מכילה מטודה של notify. הכפתור מכיל אוסף של Iobserver .

הframe מוסיף את עצמו בתור observer ל button. כאשר ב button מתרחש משהו( כגון לחיצה), והוא רוצה לעדכן את כל ה observers שלו. המטודה updateobservers מבצעת קריאה למטודה notify של כל observer.

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

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

[MasterDK]

כן אבל שים לב בדוגמא שהבאת הכפתור תמיד מודיע ל frame שלחצו עליו, כי הכפתור הוא זה שמכיל את ה frame (אם נסתכל על observer pattern למרות שבפועל ה frame מכיל את הכפתור אם נסתכל על היהררכיה).

נניח ואני רוצה עכשיו לבצע פעולה X על ה frame אבל הפעולה הזו תקפה גם לגבי כל מה שה frame מכיל בתוכו בצורה הייררכית, להלן הכפתור. איך אני עושה את זה? אני אצטרך ללמש את observer pattern עבור ה frame, כאשר ה frame יהיה ה observer והכפתור יהיה ה subject. אבל מלפני כבר הגדרנו שהכפתור הוא ה observer וה frame הוא ה subject, ואתה מקבל dependency cycle שזה המצב בו אני נמצא.

מילא tם ה GUI שלי רק היה צריך להודיע ל network שלחצו על login/register, אבל גם ה network אמור לדבר עם ה GUI, כלומר שניהם יהיו observerים וגם subjectים. זה הבעיה שאני מנסה לפתור.

[ktbnus]

בדיוק פה הנקודה. הכפתור לא מכיל את ה frame. הכפתור מכיל IOBSERVER.

public class MyFrame extends JFrame implements IObserver
}
MyButton button = new MyButton();
button.AddObserver( this);
{

public class MyButton implements ISubject
{
List<IObserver> observerList;

public AddObserver(IObserver obs){...}
}

במצב הזה אין dependency cycle. הכפתור יכל לעדכן את הטופס בכל מה שהוא צריך. והטופס יכל לפנות לכפתור איך ומתי שהוא רוצה.

[MasterDK]

הבנתי אותך.. בגלל בהכפתור מוכל בתוך ה FRAME אז זה מסתדר. תודה על ההסבר!

אני קצת בספק אם המבנה של GUI מכיל את ה NETWORK מתאים במקרה שלי. קול פנימי אומר לי שזה יהיה לא נכון להכליל את NETWORK בתוך ה GUI (או להיפך)...

מה גם שלא תמיד התשובה שה GUI יקבל מה NETWORK תיהיה מיידית, אני ארצה כנראה לממש גם פה שיטה של EVENT DRIVEN, ה GUI ישלח הודעה ל NETWORK (לדוגמא "תעשה אימות של משתמש X עם סיסמא Y") הפעולה של יצירת החבילה, שליחתה, המתנה לתשובה, קבלת התשובה, parsing של התשובה וחזרה ל GUI, יכולה לקחת זמן מסויים ואו שאני אצטרך לפתוח לזה THREAD חדש, או לשים את ההודעה בתור מסויים לרשום CALLBACK (לדוגמא "תעשה אימות של משתמש X עם סיסמא Y, כשתקבל תשובה תקרא ל GUI::operationDone()"). וככה אני לא אחסום את ה GUI מלעשות דברים אחרים.