דפוסים יצירתיים מתוארים לראשונה בלהקה המפורסמת של ארבעה הספר מציג כל דפוס בפרק ייעודי ומלווה מבנה קפדני עבור כל אחד מהם: כוונה, מוטיבציה, יישומיות, מבנה, משתתפים, שיתוף פעולה, השלכות, יישום, קוד דוגמה, שימושים ידועים ודפוסים קשורים. עיצוב פטנטים לדוגמה, הנה תמונה של דפוסים : בניין 
 
 
 
 
 
 ניסיון : להפריד את הבנייה של אובייקט מורכב מהייצוג שלה כך שהתהליך הבנייה זהה יכול ליצור ייצוגים שונים. יישומיות : השתמש ב- Builder Pattern כאשר 
 
 
 the algorithm for creating a complex object should be independent of the Parts that make up the object and how they're assembled. תהליך הבנייה חייב לאפשר ייצוגים שונים עבור האובייקט שנבנה. : Intent להפריד את הבנייה של אובייקט מורכב מהייצוג שלה כך שהתהליך הבנייה זהה יכול ליצור ייצוגים שונים. : Applicability השתמש ב- Builder Pattern כאשר 
 
 
 האלגוריתם ליצירת אובייקט מורכב צריך להיות עצמאי מהחלקים שמרכיבים את האובייקט וכיצד הם מותאמים. תהליך הבנייה חייב לאפשר ייצוגים שונים עבור האובייקט שנבנה. GoF (Gang of Four) היה יסוד בתחום התכנות ממוקדות אובייקטים והשפיע על העיצוב של שפות תכנות, כולל שפות נפוצות כגון Java. כשאני חוזר לתפקיד הנדסי, אני נתקל בקוד Java שנכתב לאחרונה שיש לו הרבה פוטנציאל לשיפור בנוגע לשימור. זה עובד, אבל אני מדמיין מהנדסים צריכים לעדכן אותו, כולל העתיד של המחבר המקורי ואני, ואני בטוח שאני יכול לעזור להם. השבוע, השתמשתי בקוד מחדש באמצעות דפוסים יצירתיים כדי לשפר את שימורו. יצרן עם מספר פרמטרים של אותו סוג. בואו לדמיין בונה עם פרמטרים רבים של String: public License (
    String id, String licenseeName,
    String licenseId, String environment,
    LocalDateTime generatedAt
)
 בעת התקשר ליצרן זה, יש סיכוי שהתקשר עשוי לשנות באופן לא רצוי פקודות פרמטרים: var license = new License("My license", "XXX-123", "Customer", "User-acceptance tests", new LocalDateTime());
 שלום, שיניתי את שם בעל הרישיון ואת מזהה הרישיון IDE שלך עשוי לעזור כאן, אבל יש דרכים אחרות. סוג Wrappers תומכי OOP טהור יגידו בשמחה שאף פעם לא צריך להשתמש בשורש ישירות במקום, אחד צריך לכסות כל פרמטרים בסוג מיוחד, • Java : א.ג record public record Id(String id) { ... }
public record LicenseeName(String licenseeName) { ... }
public record LicenseeId(String licenseId) { ... }
public record Environment(String environment) { ... }
public record GeneratedAt(LocalDateTime generatedAt) { ... }
 אנחנו לא יכולים לעשות טעות: var id = new Id("My license");
var licenseeName = new LicenseeName("Customer");
var licenseId = new LicenseeId("XXX-123");
var environment = new Environment("User-acceptance tests");
var generatedAt = new LocalDateTime();

var license = new License(id, licenseId, licenseName, environment, generatedAt); //1
 
 
 שגיאה תקופתית בעוד גישה זו בהחלט משפרת את היכולת לשמור על זה, האריזה מגדילה את גודל הזיכרון.הגדלת המדויקת תלויה ביישום JDK, אבל עבור סוג יחיד, זה בערך 5 פעמים גדול יותר. קוטלין עושה את זה ברוח על ידי מתן : האריזה היא בדיקת זמן קומפיל, אך קוד האייט מצביע על הסוג האריזה עם המגבלה הבאה: שיעורי ערך Inline 
 
 לכיתת inline חייבת להיות תכונה אחת המוקדמת ב-constructor העיקרי. לכיתת inline חייבת להיות תכונה אחת המוקדמת ב-constructor העיקרי. שם הפרמטרים Java מציעה רק שיחות שיטה עם פרמטרים מיקום, אבל שפות אחרות, , Python, Kotlin, ו Rust, גם מציעים פרמטרים בשם. א.ג הנה יצרן Kotlin המשקף את הכיתה לעיל: class License (
    val id: String, val licenseeName: String,
    val licenseId: String, val environment: String,
    val generatedAt: LocalDateTime
)
 אתה יכול להתקשר לבניין על ידי שם הפרמטרים, ובכך להפחית את הסיכון של טעות: val license = License(
    id = "My license", licenseeName = "Customer",
    licenseId = "XXX-123", environment = "User-acceptance tests",
    generatedAt = LocalDateTime()
)
 The דפוסים בניין The דפוס הוא גישה אפשרית נוספת, גם אם היא אינה חלק ממקרי השימוש המתוארים ב- GoF. בניין אז הנה הקוד: public class License {

    private final String id;
    private final String licenseeName;
    private final String licenseId;
    private final String environment;
    private final LocalDateTime generatedAt;

    private License (                              //1
        String id, String licenseeName,
        String licenseId, String environment,
        LocalDateTime generatedAt
    ) { ... }
    
    public static LicenseBuilder builder() {       //2
        return new LicenseBuilder();
    }

    public static class LicenseBuilder {

        private String id;                         //3
        private String licenseeName;               //3
        private String licenseId;                  //3
        private String environment;                //3
        private LocalDateTime generatedAt;         //3

        private LicenseBuilder() {}                //1
        
        public LicenseBuilder withId(String id) {  //4
            this.id = id;                          //5
            return this;                           //4
        }
        
        // Other `withXXX` methods
        
        public License build() {                   //6
            return new License(
                id, licenseeName,
                licenseId, environment,
                generatedAt
            );
        }
    }
}
 
 
 
 
 
 
 
 הגנה על אובייקטים ישירים יצירת בניין חדש שדות Builder לעקוב אחר שדות האובייקט כל שיטה מחזירה את האובייקט של היצרן עצמו הוסף את התכונה החזרת האובייקט המלא כעת ניתן לקרוא לבניין ככה: val license = License.builder()
                     .withId("My license")
                     .withLicenseName("Customer")
                     .withLicenseId("XXX-123")
                     .withEnvironment("User-acceptance tests")
                     .withGeneratedAt(new LocalDateTime())
 יצירת קוד היצרן היא כאב (אלא אם אתה משתמש AI), אבל זה מאפשר קריאות טובה יותר.בנוסף, ניתן להוסיף אימות עבור כל שיטת שיחה, כדי להבטיח את האובייקט בבניית הוא תקף. . מבנה פנים סיכום 
 
 
 
 
 
 
 
 
 
 Approach 
 Pros 
 Cons 
 
 
 
 
 Type wrappers 
 Object-Oriented Programming 
 - More verbose- Can be memory-heavy depending on the language 
 
 
 
 
 Named parameters 
 Easy 
 Not available in Java 
 
 
 
 
 Builder pattern 
 Verbose 
 - Allows creating complex objects- Allows validating סוגים של Wrappers תכנות ממוקדות אובייקט - יותר verbose- יכול להיות זיכרון כבד תלוי בשפה שם הפרמטרים קל לא זמין ב-Java בניין Pattern שקר - מאפשר יצירת אובייקטים מורכבים- מאפשר אימות יצרנים זורקים יוצאים מן הכלל באותו הקוד, מצאתי את הקוד הבא: public Stuff(UuidService uuidService, FallbackUuidService fallbackUuidService) {

    try {
        uuid = uuidService.getUuid();
    } catch(CannotGetUuidException e) {
        try {
            uuid = fallbackUuidService.getUuid();
        } catch(CannotGetUuidException e1) {
            uuid = "UUID can be fetched";
        }
    }
}
 עם קצת ניסיון, אתה יכול להבחין מה לא בסדר בסעיף לעיל. כל קוד שמסתמך על UUID חייב להתמודד עם ערכים שאינם UUUID אפשרי. אחד חייב להיכשל במהירות. תיקון מהיר ייראה כך: uuid public Stuff(UuidService uuidService, FallbackUuidService fallbackUuidService) {

    try {
        uuid = uuidService.getUuid();
    } catch(CannotGetUuidException e) {
        try {
            uuid = fallbackUuidService.getUuid();
        } catch(CannotGetUuidException e1) {
            throw new RuntimeException(e1);
        }
    }
}
 עכשיו, כל לאובייקט יש UUID תקף, עם זאת, זריקת יוצאים מן הכלל בתוך יצרנים יש בעיות פוטנציאליות: Stuff 
 
 
 
 אובדן משאבים: אם היצרן מספק משאבים (לדוגמה, קבצים, מפתחות) ומטיל יוצא מן הכלל, ייתכן שהמשאבים האלה לא יפורסמו. מורשת: אם יצרן סופר-קלאס זורק יוצא מן הכלל, יצרן הסופר-קלאס לא יפעל. חריגים שנבדקו: אי אפשר להשתמש בחריגים שנבדקו בבניינים, רק בחריגים בזמן ביצוע. מסיבות אלה, אני חושב שיש יוצאים מן הכלל אין להם מקום בבניינים ואני נמנע מהם. דפוס המתואר בסעיף הראשון, אבל כפי שצוין, זה הרבה קוד; אני לא חושב שזה הכרחי. . בניין שיטת המפעל 
 
 
 
 
 
 ניסיון הגדרת ממשק ליצירת אובייקט, אך תן לקטגוריות להחליט באיזו כיתה להזדהות. יישום השתמש בשיטת המפעל כאשר: 
 
 
 
 כיתה לא יכולה לחזות את הכיתה של האובייקטים שהיא צריכה ליצור. קבוצה רוצה שהעמדות שלה יסבירו את האובייקטים שהיא יוצרת. הכיתות מעבירות אחריות לאחד ממספר תת-כיתות העוזר, ואתה רוצה לאתר את הידע של איזו תת-כיתת העוזר היא העוזרת. Intent הגדרת ממשק ליצירת אובייקט, אך תן לקטגוריות להחליט באיזו כיתה להזדהות. Applicability השתמש בשיטת המפעל כאשר: 
 
 
 
 כיתה לא יכולה לחזות את הכיתה של האובייקטים שהיא צריכה ליצור. קבוצה רוצה שהעמדות שלה יסבירו את האובייקטים שהיא יוצרת. הכיתות מעבירות אחריות לאחד ממספר תת-כיתות העוזר, ואתה רוצה לאתר את הידע של איזו תת-כיתת העוזר היא העוזרת. שים לב שבמקרה זה, אנו משתמשים בו מסיבה אחרת. public class Stuff {

    private final UUID uuid;
    
    private Stuff(UUID uuid) {                               //1
        this.uuid = uuid;
    }

    public static Stuff create(UuidService uuidService, FallbackUuidService fallbackUuidService) throws CannotGetUuidException {
    
        try {
            return new Stuff(uuidService.getUuid());
        } catch(CannotGetUuidException e) {
            return new Stuff(fallbackUuidService.getUuid()); //2
        }
    }
}
 
 
 
 הימנעות מפגיעה חיצונית אם הוא נכשל, הוא זורק CannotGetUuidException חדש אחד קורא למעלה ככה: var stuff = Stuff.create(uuidService, fallbackUuidService);  //1
 
 
 צריך לקחת CannotGetUuidException בשלב זה, אנו בטוחים שהאובייקט יתחיל לחלוטין אם השיחה תצליח. מסקנה בפוסט זה, תיארתי שני שימושים של דפוסים יצירתיים של GoF, אשר אינם רשומים בספר: שיפור תחזוקה ולהבטיח אובייקטים הם מקוריים לחלוטין. To go further: 
 
 
 
 עיצוב GoF Patterns צלילה לתוך דפוס הבניין דפוס הבניין הוא מכונה במצב סופי! פורסם במקור ב A Java Geek ב-31 באוגוסט, 2025 ג'ייק Java

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

האודיו הזה מופק בשפת המקור של הסיפור!

יותר מדי זמן; לקרוא

Make resilience your competitive advantage

יצירת אובייקטים: הבעיות שעשיתי ואת הדפוסים שעזרו לי

About Author

הערות

תלו תגים

מאמר זה הוצג ב

Related Stories

10 Reasons Why Publishing on HackerNoon Will Skyrocket Your Reach and Impact

The TechBeat: To Focus or Not Focus: How to Find the Right Product-Market Fit (3/8/2024)

The TechBeat: Python's Testing Playbook: Building Bulletproof Code (1/16/2024)

ברכות עונות מ-HackerNoon: Boost Stories עם תרגומים, דיבור לטקסט ועוד

10 Reasons Why Publishing on HackerNoon Will Skyrocket Your Reach and Impact

The TechBeat: To Focus or Not Focus: How to Find the Right Product-Market Fit (3/8/2024)

The TechBeat: Python's Testing Playbook: Building Bulletproof Code (1/16/2024)

ברכות עונות מ-HackerNoon: Boost Stories עם תרגומים, דיבור לטקסט ועוד

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps