من أجل التبسيط ، سأستخدم التعليقات التوضيحية lombok'a:
ValueBuilder بعد القليل من البحث على
، نحصل على هذا المنشئ - يفصل بناء كائن معقد عن عرضه التقديمي بحيث يمكن الحصول على طرق عرض مختلفة نتيجة لعملية التصميم نفسها. هل هو فقط للأشياء المعقدة؟
لنلق نظرة على مثال بسيط:
@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);
...
هناك بالتأكيد خيارات:
- يمكن تسليم الكائنات التي تحتوي على عدد قليل من الحقول من أنواع مختلفة باستخدام العديد من المنشئين. لكن هذا لا يحل مشكلة الفصل أعلاه.
- استخدام أدوات التثبيت أمر شخصي ، فهو يفسد الكود.
ماذا عن المنشئ؟
@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. من الممكن ارتكاب خطأ عندما يغير شخص ما الرمز.
النتيجة
بناءً على تجربتي ، أميل إلى استخدام بناة. التكلفة ليست عالية ، لكن الناتج عبارة عن رمز يسعد قراءته.
وبالطبع ، اكتب اختبارات لتجنب النقطة السلبية الثانية لاستخدام المنشئات.
ملاحظة: هذه هي مقالتي الأولى ، وسأكون ممتنًا للنقد والتعليقات البناءة.