none
Inherit Windows Forms, האם זה מומלץ? RRS feed

  • שאלה

  • שלום לכולם,

    אני עובדת בC#, VS2010 4.0

    יש לי מסך מורכב מהרבה אוביקטים, שאני רוצה להוריש אותו ל2(ואלי בהמשך ליותר) מסכים.

    המסכים היורשים תואמים ב85% מהדברים.

    אני רוצה לבצע הורשה כדי להימנע מIF מיותרים,

    בעבודה שלי , מתכנתים בBV בסביבת VS ישנה אומריםשהם עשו את זה וזה בעיה גדולה וקשה(כאשר ארצה לשנות את האב) ולא להתחיל עם זה.

    מה אתם אומרים? מה דעתכם? מה הסיכונים של זה?

    או הפניה למאמרים הדנים בזה.

    תודה מראש.

    יום שני 21 יולי 2014 08:17

תשובות

  • זה שאלה מאוד מעניינת ויכולה לפתוח דיון מאוד מעניין מפני שאין כאן תשובה חד משמעית.

    * לפני שאני מתחיל אני רוצה להקדים ולאמר שחוסר ידע יכול להוביל הרבה פעמים לפסילת הדרך היותר מתאימה, ומהנסיון שלי (סליחה על ההכללה, ואני רק מדבר על נסיון של מה שאני פגשתי, ולא על כל המפתחים) הרמה של מפתחים ב VB.NET באופן כללי הרבה יותר נמוכה מהרמה של המפתחים ב C# בישראל. הרבה מאוד מפתחים מגיעים מעולם ה VBS והתפיסה שלהם עדיין נמצאת שם ולא במודל האובייקטים (זה מתקשר ישירות לדיון כאן! מכיוון שהם יטו לפסול את השימוש בהורשה גם כשזה הדבר הנכון)

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

    אז מה ניתן להגיד על הנושא עצמו?

    מצד אחד את צודקת לחלוטין והשימוש בהורשה נועד בדיוק למקרים אלו! הרעיון הבסיסי הוא לא לכתוב קוד פעמיים, Code-Re-Use הוא מושג "חצי רשמי" בנשא. השאלה כיצד מממשים את הפיתוח! כי מצד שני בהחלט מדובר בפוטניאל ליצירת מורכבות לא נכונה ומיותרת.

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

    לכן בשלב ראשון הייתי מבצע הפרדה במחשבה על הורשה של מחלקות מבחנה לוגית: למשל כלב ודג וחתול, הם סוג של חיה ולכן זו הורשה לוגית טובה בדרך כלל להחזיק מחלקה של חיה ומחלקות בנים של כלב,דג, וחתול. לבין הורשה שנועדה רק למטרות עיצוב (זה א פסול! ופילו נכו אבל צריך לחשוב על כך). במקרה של הורשה לשם עיצוב כמו במקרה של קונטרולים צריך לבדוק במת מה הגמישות שזה נתן לנו. היום יש לך A בתוך B בתו C שבתוך D אז מה יקרה מחר אם תרצי להציג חלק מ B במיקום אחד וחלק מ B במיקום אחר בעיצוב הבא? מצב כזה מצביע על כך שהמחלקה או הקונטרול של B כניראה לא היה צריך להיות קונטרול אחד ולא מדובר במשהו שציר היה להיות קופסא שחורה אלא בנוי מראש מ 2 קונטרולים. אחרת ייתכן שעתה פירוק הקונטרול עלול לגרום לכך שכל הקונטרולים שירשים אותו כבר לא מתאימים!

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

    בקיצור: כמו תמיד כל מקרה לגופו של עניין אבל:

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


    [Personal Site] [Blog] [Facebook]signature

    יום שני 21 יולי 2014 10:09
    מנחה דיון

כל התגובות

  • זה שאלה מאוד מעניינת ויכולה לפתוח דיון מאוד מעניין מפני שאין כאן תשובה חד משמעית.

    * לפני שאני מתחיל אני רוצה להקדים ולאמר שחוסר ידע יכול להוביל הרבה פעמים לפסילת הדרך היותר מתאימה, ומהנסיון שלי (סליחה על ההכללה, ואני רק מדבר על נסיון של מה שאני פגשתי, ולא על כל המפתחים) הרמה של מפתחים ב VB.NET באופן כללי הרבה יותר נמוכה מהרמה של המפתחים ב C# בישראל. הרבה מאוד מפתחים מגיעים מעולם ה VBS והתפיסה שלהם עדיין נמצאת שם ולא במודל האובייקטים (זה מתקשר ישירות לדיון כאן! מכיוון שהם יטו לפסול את השימוש בהורשה גם כשזה הדבר הנכון)

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

    אז מה ניתן להגיד על הנושא עצמו?

    מצד אחד את צודקת לחלוטין והשימוש בהורשה נועד בדיוק למקרים אלו! הרעיון הבסיסי הוא לא לכתוב קוד פעמיים, Code-Re-Use הוא מושג "חצי רשמי" בנשא. השאלה כיצד מממשים את הפיתוח! כי מצד שני בהחלט מדובר בפוטניאל ליצירת מורכבות לא נכונה ומיותרת.

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

    לכן בשלב ראשון הייתי מבצע הפרדה במחשבה על הורשה של מחלקות מבחנה לוגית: למשל כלב ודג וחתול, הם סוג של חיה ולכן זו הורשה לוגית טובה בדרך כלל להחזיק מחלקה של חיה ומחלקות בנים של כלב,דג, וחתול. לבין הורשה שנועדה רק למטרות עיצוב (זה א פסול! ופילו נכו אבל צריך לחשוב על כך). במקרה של הורשה לשם עיצוב כמו במקרה של קונטרולים צריך לבדוק במת מה הגמישות שזה נתן לנו. היום יש לך A בתוך B בתו C שבתוך D אז מה יקרה מחר אם תרצי להציג חלק מ B במיקום אחד וחלק מ B במיקום אחר בעיצוב הבא? מצב כזה מצביע על כך שהמחלקה או הקונטרול של B כניראה לא היה צריך להיות קונטרול אחד ולא מדובר במשהו שציר היה להיות קופסא שחורה אלא בנוי מראש מ 2 קונטרולים. אחרת ייתכן שעתה פירוק הקונטרול עלול לגרום לכך שכל הקונטרולים שירשים אותו כבר לא מתאימים!

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

    בקיצור: כמו תמיד כל מקרה לגופו של עניין אבל:

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


    [Personal Site] [Blog] [Facebook]signature

    יום שני 21 יולי 2014 10:09
    מנחה דיון
  • pituah כמה מתכנתים VB יש בכלל בארץ..

    בנוסף, VB לא נלמדת בשום מקום רשמי כך שישנה משוואה VB = חובבן/אוטודידקט. אין הבדל לדעתי בשפות, בשתיהם הOOP מאוד מוחשי כל הזמן אבל אפשר שלא להבין אותו בכלל, כמעט לא שייך ללמוד אותו מהפקטיקה המעשית, מוכרחים ללמוד את התיאוריה (דבר שבלי מורה/ספר/קורס כמעט בלתי אפשרי).

    יום שני 21 יולי 2014 11:35
  • pituah כמה מתכנתים VB יש בכלל בארץ..

    בנוסף, VB לא נלמדת בשום מקום רשמי כך שישנה משוואה VB = חובבן/אוטודידקט. אין הבדל לדעתי בשפות, בשתיהם הOOP מאוד מוחשי כל הזמן אבל אפשר שלא להבין אותו בכלל, כמעט לא שייך ללמוד אותו מהפקטיקה המעשית, מוכרחים ללמוד את התיאוריה (דבר שבלי מורה/ספר/קורס כמעט בלתי אפשרי).

    לומדים יש מתכנתים שהתחילו לפתח לפני 20 שנים ויותר והם עברו מVB6 לVBNET.

    למה אתה חושב שכולם כולם התקדמו?

    יום שני 21 יולי 2014 11:41
  • לומדים, לא דיברתי על הבדל בשפות!

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

    דיברתי על ישראל בלבד ולכן הדגשתי את המילה ישראל גם בהבלטה וגם בקו תחתון כדי שיהיה ברור.

    * דרך אגב הייתי מאוד עדין כדי לא לפגוע באף אחד :-)

    ** אחת הסיבות לכך למפתחים בישראאל טובים ב C# זה לא העובדה שהם למדו C# לדעתי אלא העובדה שלחלק ניכר יש בסיס בתכנות "אמיתי" כמו C או לפחות C++ (שפות NATIVE או \שפות שעוברות קימפול מלא). ובשפות אלו היה להם את הבסיס הטוב. הלימוד המסודר הוא כמובן חלק במשוואה וחלק חשוב, אבל לא יכול להתחרות לדעתי עם מי שמגיע עם בסיס טוב של שפות בסיסיות יותר אותן הוא למד מסודר וטוב.


    [Personal Site] [Blog] [Facebook]signature

    יום שני 21 יולי 2014 15:51
    מנחה דיון
  • יפיפיה אני התחלתי עם VB (הרבה לפני גרסה 6) למעשה התחלתי עם בייסיק (לפני VB היה B) אם כבר מדברים בשנת 83 בערך, והתקדמתי לVB6 וגם ל VB.NET, ואני מקווה שאני נחשב לא גרוע מאוד :-) אני ביצעתי הכללה ויש יוצאים מהכלל כמובן. דרך אגב, אני למדתי בדרך גם C וגם Fortran (פורטרן היא השפה היחידה שלמדתי בקורס מסודר באוניברסיטה ולא לבד) ועוד הרבה שפות בדרך, יותר או פחות לעומק, עד שעברתי ל C# כשפה מרכזית. מפעם לפעם אני אפילו יכול להיתקל בקוד של VB.NET שאני צריך לעבוד עליו. למרות הרקע שלי ב VB.NET אני עדיין טוען את מה שכתבתי למעלה :-)

    [Personal Site] [Blog] [Facebook]signature

    יום שני 21 יולי 2014 15:56
    מנחה דיון
  • פיתוח, שוב תודה על התשובות הארוכות המעמיקות ומהמחכימות.

    אני כבר מכירה את דעתך על מפתחי VB.. כך שזה לא חדש לי.

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

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

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

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

    ועכשיו באתי להוסיף גם את חתול למערכת. אני מתלבטת האם בכל מקום שחתול נבדל לעשות IF או להעביר איכשהו (שזה כבר לא דרך טובה להתחיל הורשה אני יודעת) את חתול לחיה ולהוריש ממנו את שניהם.

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

    האם אני לא יכולה לדרוס לאב את המאפין VISIBLE של כפתור, או את המאפין LOCATION?

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

    יום שלישי 22 יולי 2014 06:36
  • פיתוח, שוב תודה על התשובות הארוכות המעמיקות ומהמחכימות.

    אני כבר מכירה את דעתך על מפתחי VB.. כך שזה לא חדש לי.

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

    :-)

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

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

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

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

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

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

    ועכשיו באתי להוסיף גם את חתול למערכת. אני מתלבטת האם בכל מקום שחתול נבדל לעשות IF או להעביר איכשהו (שזה כבר לא דרך טובה להתחיל הורשה אני יודעת) את חתול לחיה ולהוריש ממנו את שניהם.

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

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

    אבל זה לא המצב כפי שאני מבין.

    הזכרתי את טכנולוגיית MVC אז אולי זה המקום להמשיך את ההשוואה ולהגיד שכאן אנחנו במשהו שיותר מתאים לשימוש בטכנולוגיה WebForm שהיא מבוססת עבודה עם קונטרולים וחסרת ההפרדה בין השכבות של המודולים וה GUI בבסיס שלה (בדומה ל Windows Forms). אם כי כמובן גם בטכנולוגיות אלו אפשר וצריך להלביש את רעיון "הפרדת הרשויות" (סתם שם לא קשר שתמיד עולה לי בראש כשמדברים על הפרדת השכבות).

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

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

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

    ברמת User Control הראייה כרב שונה לחלוטין. במקרה זה עלינו לחשוב על כיוון ויזואלי. שימי לב שאני כל הזמן מדבר על קונטרולים לעומת מחלקות. לא כל קונטרול הוא השלכה שיירה של אחד לאחד ממחלקה מסויימת!
    http://msdn.microsoft.com/en-us/library/aa302342.aspx

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

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

    עכשיו אנחנו חוזרים לדון על רונטרולים ולא רק מחלקות, ז"א על הצד ה של ה VIEW

    האם אני לא יכולה לדרוס לאב את המאפין VISIBLE של כפתור, או את המאפין LOCATION?

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

    כן, ניתן לדרוס מאפיינים.

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


    [Personal Site] [Blog] [Facebook]signature

    יום שלישי 22 יולי 2014 15:25
    מנחה דיון
  • פיתוח,

    להבהרה: 1.כשכתבתי תכונות התכוונתי גם לקוד שקורה בCLICK של כפתורים וגרידים.

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

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

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

    יום רביעי 23 יולי 2014 09:48
  • >> "האם כדאי להעתיק את המסך הזה ולשנות לו את השם ואת מה שצריך בשביל החתול"

    אני לא בין בדיוק למה הכונה בשאלה אבל העתקת קוד היא כמעט אף פעם לא פתרון נכון או מומלץ.

    * לפעמים הפתרון היעיל לשימוש בקוד משתף בלי קשר להורשה (נניח ממתודה מסויימת שרוצים להריץ בכל מני מקומות בקוד), זה שימוש במחלקה נפרדת שניתן לגשת אליה מכל מקום גם בלי להגדיר מופע חדש שלה בכל פעם. ז"א פשוט מחלקה STATIC שהיא PUBLIC ופשוט בבנאי STATIC ועוד. זה מאוד נוח למשל לארגן מחלקה אחת שכוללת את כל המתודות לעזר.

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

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


    [Personal Site] [Blog] [Facebook]signature

    יום רביעי 23 יולי 2014 12:11
    מנחה דיון