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

ארכיטקטורה פרקטלית

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

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

אבסטרקציה

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

 

 

מימושים

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

• ברמת המודול: שימוש בפולימורפיזם;
• ברמת האפליקציה: שימוש בטעינה דינאמית של מודולים (DLL);
• במערכת אנטרפרייז: שימוש בפרוקסי (Proxy) לפני השרתים שאיתם מתקשרים;
• במערכת מבוזרת: שימוש בפרוטוקול סגור.

בהמשך נפגוש דוגמאות נוספות למבנה הפרקטלי של הארכיטקטורה.