بناة أم بناة؟ نحن نتحدث بصوت عال

مرحبا! أريد التكهن حول مدى استصواب استخدام البناة للأشياء البسيطة.



من أجل التبسيط ، سأستخدم التعليقات التوضيحية lombok'a:



ValueBuilder بعد القليل من البحث على

Google



، نحصل على هذا المنشئ - يفصل بناء كائن معقد عن عرضه التقديمي بحيث يمكن الحصول على طرق عرض مختلفة نتيجة لعملية التصميم نفسها. هل هو فقط للأشياء المعقدة؟



لنلق نظرة على مثال بسيط:



@Value
public class Info {
    @Nullable String uuid;
    @Nullable String email;
    @Nullable String phone;
}


فئة بسيطة للغاية. في الواقع ، نحصل على كائن غير قابل للتغيير يتم تهيئته من خلال المنشئ.



ولكن ، كما نرى ، جميع الحقول لاغية ، ولن يبدو إنشاء مثل هذه الكائنات جيدًا:



        final Info info1 = new Info(null, "email@email.com", "79998888888");
        final Info info2 = new Info("3d107928-d225-11ea-87d0-0242ac130003", null, null);
        final Info info3 = new Info("3d107928-d225-11ea-87d0-0242ac130003 ", "email@email.com", null);
...


هناك بالتأكيد خيارات:



  1. يمكن تسليم الكائنات التي تحتوي على عدد قليل من الحقول من أنواع مختلفة باستخدام العديد من المنشئين. لكن هذا لا يحل مشكلة الفصل أعلاه.
  2. استخدام أدوات التثبيت أمر شخصي ، فهو يفسد الكود.




ماذا عن المنشئ؟



@Value
@Builder
public class Info {
    @Nullable String uuid;
    @Nullable String email;
    @Nullable String phone;
}


نحصل على بنية أنيقة للغاية لكائن بسيط :



        final Info info1 = Info.builder()
                .uuid("3d107928-d225-11ea-87d0-0242ac130003")
                .phone("79998888888")
                .build();
        final Info2 info2 = Info.builder()
                .email("email@email.com")
                .phone("79998888888")
                .build();
...
}


ومع ذلك ، لاستخدام jackson في المشروع ، من الضروري إضافة فصلنا بحيث يتم إلغاء التسلسل بنجاح:



@Value
@Builder(builderClassName = "InfoBuilder")
@JsonDeserialize(builder = Info.InfoBuilder.class)
public class Info {
    @Nullable String uuid;
    @Nullable String email;
    @Nullable String phone;

    @JsonPOJOBuilder(withPrefix = "")
    public static class InfoBuilder {

    }
}


نحصل على إيجابيات وسلبيات كلا الطريقتين:



الباني:



+

1. يصبح الرمز أكثر إيجازًا.

3. القيمة الفارغة في معلمات المُنشئ ليست واضحة.

2. فرصة أقل لإرباك المعلمات من نفس النوع.

-

1. نصنع كائنًا إضافيًا سوف يزيله GC ككل بأمان ، ولكن لا يجب أن تنساه.

2. إذا لزم الأمر ، استخدم جاكسون - كومة من الصف.



المنشئ:



+

1. الحد الأدنى من تراكم الصفوف لدينا ، لا ماء.

2. إنشاء كائنات لا لزوم لها.

-

1. في كثير من الأحيان سوف تصل قيمة null إلى مُنشئ مثل هذا الكائن.

2. من الممكن ارتكاب خطأ عندما يغير شخص ما الرمز.



النتيجة



بناءً على تجربتي ، أميل إلى استخدام بناة. التكلفة ليست عالية ، لكن الناتج عبارة عن رمز يسعد قراءته.



وبالطبع ، اكتب اختبارات لتجنب النقطة السلبية الثانية لاستخدام المنشئات.



ملاحظة: هذه هي مقالتي الأولى ، وسأكون ممتنًا للنقد والتعليقات البناءة.



All Articles