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