The Open Close Principle

אחד הדברים הראשונים שהחלטתי ללמוד, מעבר לframework שאיתו עבדתי היה design patterns.
הסיבה העיקרית הייתה שאני חושב שזה משהו שאקח איתי להמשך, לא משנה איפה אני אעבוד או עם איזה framework אני אשתמש.
אחד העקרונות החשובים ביותר שיש לנו, כאשר אנחנו רוצים להבין design patterns או למה הם כתובים בצורה שבה הם כתובים, זה The open closed principle.
אבל זה גם היה אחד הדברים שהיה לי הכי קשה להבין, אז בואו ננסה להבין את זה ביחד

מהו open closed principle?

ההגדרה הרשמית של העקרון היא:

מחלקות (Classes) אמורות להיות פתוחות (open) להרחבה, אבל סגורות (close) לשינוי

אבל מה זה בכלל אומר?

עם מבט אל העתיד

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

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

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

דוגמה

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

אז איך עושים את זה?

על כל זה ועוד, בפוסט הבא שלי על decorator design pattern

וכמו תמיד, כל הערה, הארה או שאלה שיש לכם תתקבל בברכה.

השאר תגובה

Scroll to Top