שלום חברים שבוע טוב
חלק ניכר מאנשי הDATA משתמשים בפייתון ביום יום
אם זה על מנת לבצע טרנספורמציות בתהליכי ה ETL (למי ששכח מצ"ב לינק), אם זה בכדי לבצע אוטומציות לפעולות אחרות בתהליך ליצירת DWH וארכיטקטורה אידיאלית לנתונים שמגיעים ממקורות שונים
היום אני רוצה להתחיל סדרה קצרצרה על עקרונות בסיס בתכנות ובצורה יותר פרקטית לפייתון
היום נדבר על עקרונות הSOLID.
SOLID זה בעצם ראשי תיבות באנגלית של :
תמונה
חמשת העקרונות האלו פורסמו לראשונה על ידי מהנדס התכנה האמריקאי רוברט סי. מרטין בתחילת שנות האלפיים, והמחשבה מאחורי העקרונות היא שכאשר הם מיושמים יחדיו בפיתוח של מערכת תכנה, סביר שהיא תהיה יותר קלה לתחזוק והרחבה לאורך הזמן.
אוקי נתחיל:
האות הראשונה היא S ומסמלת את העקרון הראשון שהוא Single Responsibility Principle | SRP
כל Module שאנחנו כותבים צריך להיות מיועד למטרה ספציפית אחת,
איך נוודא את זה ? כשנשאל האם יש יותר מסיבה אחת להשתנות ? והתשובה תהיה לא!
רגע רגע רגע !
אנחנו מכירים Classים אנחנו מכירים OOP
אבל מה המשמעות של Module בתכנות שלנו בפייתון?
אוקי אז בשביל לעשות את זה כמה שיותר פשוט – Module הכוונה Class או כל פונקצייה או מתודה שכתבנו.
סבבה זה ברור
אבל מה בכלל זה אומר "סיבה אחת להשתנות" ?
טוב בואו נבין את זה ונחזור רגע לבסיס 😊
אנחנו יודעים שכל מחלקה או מתודה שאנחנו כותבים תקבע מה ייקרה באפליקציה או בתוכנה שלנו ואיך זה יקרה.
המטרה שלנו היא לעשות הפרדה בצורת כתיבה שלנו ולהפריד בין מחלקות ומתודות שכתבנו שתפקידן לדאוג ל: מה לבין אלו שתפקידן לנהל את האיך.
תמונה
sekhar srinivas
ככה יהיה לנו מאוד קל להבין מה עושה על Module ויהיה לנו אפילו קל עוד יותר לעדכן לשנות או לבדוק את הקוד שלנו תוך כדי הפיתוח.
בואו נבין רגע
הבסיס של העקרון הזה בנוי על כך שכשייש לי כלי אחד שנותן פתרון להמון סיטואציות במצב שחלק קטן בו שלא בהכרח קשור בצורה ישירה לשאר הפונקציונאליות של הכלי, עדיין לצערינו כל הכלי בדרך כלל מושבת
לדוגמה תדמיינו אולר עם כל כך הרבה אפשרויות שימוש
מעבר לעובדה שכנראה כל אחד מהפתרונות שנוא מציע לא יהיו אידיאליים לפתרון (לא תלכו להוריד עץ עם המסור שלו ולא תנסו לעשות באמת שיוף לציפורניים) ובנוסף אם עכשיו נתקע משו באחד הכלי זה משפיע על התפקוד של כל היתר.
תמונה
טוב בשביל לוודא הבנה ויכולת לישום בהמשך של העיקרון הראשון Single Responsibility Principle | SRP
בואו ניקח דרישה וננסה לענות עליה בצורה אידיאלית
אנו צריכים לבנות פתרון של הרשמה של משתמשים
- כאשר הנתונים והמידע של המשתמשים יישמר בDB בSQL
- אם יש שגיאה אנו רוצים לכתוב אותה כמובן לLOG שגיאות בDB.
- ואנו רוצים לשלוח אימייל למשתמש החדש שמודיע על הצלחת תהליך ההרשמה שלו.
אוקי אלו דברים שכולנו מכירים מהיום יום בכל אתר או שירות שאנו נרשמים אליו
טוב אז בואו נתחיל בלכתוב Class בשם UserRegistration עם 3 מתודות כמובן לכל אחת מהצרכים שלנו
תמונה
sekhar srinivas
אם נכתוב את המחלקה ככה זה יעבוד או לא ?
למען האמת היא תעבוד מעולה אך לא על פי העקרון שלמדנו עכשיו
בעצם הפתרון הזה מבצע 3 משימות שונות ולכן לא עומד בתנאי של SRP.
הפתרון הנכון הוא לכתוב 3 Classים שונים שיבצעו כל אחת מהן משימה אחת ברורה.
כמובן בקבצים שונים
תמונה
טוב
אני מוכרח לציין שיש המון אנשים שחושבים שאם נרכז הכל במקום אחד דווקה יהיה לנו יותר קל לתחזק או להבין את הקוד, אבל צריך להבין איזה דבר "מה אם..."
מה אם עכשיו יבקשו לשנות את הפרקטיקה או יוסיפו דרישות לדרישות הקיימות ?
במידה והכל כתוב ללא הפרדה הסיכוי שבשינוי קטן ולא מורכב ניצור באגים ונתחיל להסתבך עם כל המתודות והקוד שלנו עצמינו
תמיד צריך לחשוב על הדרישות ומה קורה במידה והן משתנות.
בואו נסכם את היתרונות ב Single Responsibility Principle | SRP
- תחזוקה פשוטה יותר.
- בדיקות אפקטיביות יותר.
- גמישות בשינויים ותוספות שתמיד יגיעו.
- **פיתוח מקבילי ** של צוות מפתחים תמיד יהיה אפקטיבי יותר בצורה הזו.