אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע
בקטע הזה נדון בדפוסי אנטי-תבניות נפוצים שנצפים כחלק משרתי ה-proxy של ה-API שנפרסו בפלטפורמת Apigee Edge.
החדשות הטובות הן שאפשר לזהות בבירור כל אחת מהתבניות האלה ולתקן אותן באמצעות שיטות מומלצות מתאימות. כתוצאה מכך, ממשקי ה-API שנפרסו ב-Edge ישרתו את המטרה שלשמה הם נועדו ויהיו יעילים יותר.
סיכום של אנטי-דפוסים
בטבלה הבאה מפורטים דפוסי האנטי שמוזכרים בקטע הזה:
הורדת ספר דיגיטלי בנושא דפוסי אנטי
בנוסף לקישורים שלמעלה, אפשר גם להוריד את האנטי-תבניות בפורמט של ספר דיגיטלי:
מהו אנטי-תבנית?
בוויקיפדיה מוגדר אנטי-דפוס תוכנה כך:
בהנדסת תוכנה, אנטי-תבנית היא תבנית שאולי נפוץ להשתמש בה, אבל היא לא יעילה או שהיא פוגעת בפריון בפועל.
במילים פשוטות, אנטי-תבנית היא משהו שהתוכנה מאפשרת ל'משתמש' שלה לעשות, אבל הוא עלול להשפיע לרעה על הפונקציונליות, על השירות או על הביצועים.
לדוגמה, קחו את המונח "God Class/Object" (מחלקת אלוהים/אובייקט אלוהים) שנשמע כל יכול.
במינוח של תכנות מונחה-עצמים, מחלקת אלוהים היא מחלקה ששולטת ביותר מדי מחלקות באפליקציה מסוימת.
לדוגמה, נניח שיש אפליקציה עם עץ ההפניות הבא:
כפי שאפשר לראות בתמונה, מחלקת העל משתמשת ביותר מדי מחלקות ומפנה אליהן הפניות.
ה-framework שבו פותחה האפליקציה לא מונע את היצירה של מחלקה כזו, אבל יש לו הרבה חסרונות, והעיקריים שבהם הם:
- קשה לתחזוקה
- נקודת כשל בודדת כשהאפליקציה פועלת
לכן, מומלץ להימנע מיצירת כיתה כזו. זהו אנטי-דפוס.
קהל היעד
הקטע הזה מיועד בעיקר למפתחי Apigee Edge, כדי לעזור להם בתהליך של תכנון ופיתוח של שרתי proxy של API לשירותים שלהם. מומלץ להשתמש בו כמדריך עזר במהלך מחזור החיים של פיתוח ה-API ובמהלך פתרון בעיות.