Powiedzmy, że mam Composite skonfigurować w następujący sposób:W jaki sposób powinienem zbliżyć się do zawijania wzoru złożonego do wzorca Konstruktora?
public abstract class Element {
//position, size, etc.
//element methods
//setters/getters
}
public class SimpleElement1 extends Element {
//...
}
public class SimpleElement2 extends Element {
//...
}
public class CompositeElement extends Element {
protected List<Element> childrenElements;
//methods to add/remove/get children
}
Teraz, jak pójdę o owijając tę Composite się do Builder wzór, tak, że można uprościć kod klienta poprzez umożliwienie mu nie dbać (lub nie obchodziło) o zawiłościach łączenia dzieci z ich Composite?
Dzięki za szybką odpowiedź, ale hows kompozyt Animal tutaj? Może powinienem przeformułować pytanie: Posiadanie struktury podobnej do [this] (http://upload.wikimedia.org/wikipedia/commons/thumb/5/5a/Composite_UML_class_diagram_%28fixed%29.svg/800px-Composite_UML_class_diagram_%28fixed% 29.svg.png) w jaki sposób zawinąłbym go za pomocą wzorca budowania, aby kod klienta do tworzenia elementów złożonych był prostszy i/lub bardziej odpowiedni do jakiejś formy skryptowania? –
BodyPart jest składnikiem, a Monkey jest kompozytem. Ten przykład jest płaski, ale jeśli zrobiłbyś drzewo, jak palec na ręce na ramieniu, wtedy byłyby liście. – eabraham
Cóż, to było to, co miałem przed sobą w głowie i co ostatecznie sprawiło, że zadałem to pytanie. Chociaż to zadziałałoby, wydaje się, że jedynie komplikuje kod klienta (lub ogranicza jego elastyczność) i pojawia się pytanie, czy powinienem stworzyć kompozycję konstruktorów, aby wszystko było elastyczne, np. Konstruktor, który ma rękę na ramieniu. mniejsze części ciała, budowniczy, który wykona nogę, a potem budowniczy, który będzie polegał na budowniczych niższego poziomu, by stworzyć całe zwierzę? Sądzę więc, że spowodowałoby to tylko eksplozję zajęć, aby utrzymać całą elastyczność. –