избежать параллельного наследования иерархий

Question

У меня есть две параллельные цепочки наследования:

Vehicle <- Car 
     <- Truck <- etc. 

VehicleXMLFormatter <- CarXMLFormatter 
        <- TruckXMLFormatter <- etc. 

Мой опыт показывает, что параллельные иерархии наследования может стать поддержание головной боли, как они растут.

i.e. НЕ добавляет toXML(), toSoap(), toYAML() методов моим основным классам.

Как избежать параллельной иерархии наследования без нарушения концепции разделения проблем?

Answer 1

Я думаю использовать шаблон посетителя.

public class Car : Vehicle 
{ 
    public void Accept(IVehicleFormatter v) 
    { 
     v.Visit (this); 
    } 
} 

public class Truck : Vehicle 
{ 
    public void Accept(IVehicleFormatter v) 
    { 
     v.Visit (this); 
    } 
} 

public interface IVehicleFormatter 
{ 
    public void Visit(Car c); 
    public void Visit(Truck t); 
} 

public class VehicleXmlFormatter : IVehicleFormatter 
{ 
} 

public class VehicleSoapFormatter : IVehicleFormatter 
{ 
} 

При этом вы избегаете дополнительного дерева наследования и сохраняете логику форматирования отдельно от классов Vehicle. Если вы создаете новый автомобиль, вам придется добавить еще один способ к интерфейсу Formatter (и реализовать этот новый метод во всех реализациях интерфейса форматирования).
Но я думаю, что это лучше, чем создание нового класса Vehicle, и для каждого вашего IVehicleFormatter, который у вас есть, создайте новый класс, который может обрабатывать этот новый вид транспортного средства.

Answer 2

Почему бы не сделать IXMLFormatter интерфейсом с методами toXML(), toSoap(), YAML() и сделать все это для транспортного средства, автомобиля и грузовика? Что не так с этим подходом?

Answer 3

Вы можете попытаться избежать наследования для своих форматировщиков. Просто сделайте VehicleXmlFormatter, который может иметь дело с Car s, Truck s, ... Повторное использование должно быть легко достигнуто путем измельчения обязанностей между методами и определения хорошей стратегии отправки. Избегайте перегрузки магии; быть как можно более конкретными в методах именования в вашем форматировании (например, formatTruck(Truck ...) вместо format(Truck ...)).

Используйте только посетителя, если вам нужна двойная отправка: если у вас есть объекты типа Vehicle, и вы хотите отформатировать их в XML, не зная конкретного конкретного типа. Сам посетитель не решает базовую проблему достижения повторного использования в вашем форматировании и может ввести дополнительную сложность, которая вам может не понадобиться. Вышеупомянутые правила для повторного использования методами (измельчение и отправка) применимы и к вашей реализации Visitor.

Answer 4

Другим подходом является принятие модели push, а не модели pull. Как правило, вам нужны различные форматтеры, потому что вы нарушаете инкапсуляцию, и есть что-то вроде:

class TruckXMLFormatter implements VehicleXMLFormatter { 
    public void format (XMLStream xml, Vehicle vehicle) { 
     Truck truck = (Truck)vehicle; 

     xml.beginElement("truck", NS). 
      attribute("name", truck.getName()). 
      attribute("cost", truck.getCost()). 
      endElement(); 
... 

где вы вытягивать данные из определенного типа в форматер.

Вместо создания формата агностик мойку данных и инвертировать поток таким образом, конкретный тип выталкивает данные в раковине

class Truck implements Vehicle { 
    public DataSink inspect (DataSink out) { 
     if (out.begin("truck", this)) { 
      // begin returns boolean to let the sink ignore this object 
      // allowing for cyclic graphs. 
      out.property("name", name). 
       property("cost", cost). 
       end(this); 
     } 

     return out; 
    } 
... 

Это означает, что вы все еще получили инкапсулированные данные, и вы просто кормления помеченные данные в раковину. После этого XML-приемник может игнорировать определенные части данных, возможно, переупорядочить некоторые из них и написать XML. Он мог бы даже делегировать другую стратегию раковины внутри страны. Но раковина не обязательно должна заботиться о типе транспортного средства, а только о том, как представлять данные в некотором формате. Использование интернированных глобальных идентификаторов, а не встроенных строк помогает снизить стоимость вычислений (имеет значение только при написании ASN.1 или других жестких форматов).

Answer 5

Вы можете использовать Bridge_pattern

шаблон Bridge отвязать абстракцию от ее реализации так, что два могут изменяться независимо друг от друга.

Два ортогональных иерархии класса (абстракция иерархии и Реализации иерархии) связаны с использованием композиции (а не наследования) .Это композиция помогает как иерархиям изменять независимо друг от друга.

Внедрение никогда не упоминается Абстракция. Абстракция содержит Реализация интерфейс в качестве участника (через композицию).

Возвращаясь к вашему примеру:

Vehicle является Абстракция

Car и Truck являются RefinedAbstraction

Formatter является Implementor

XMLFormatter, POJOFormatter являются ConcreteImplementor

Псевдо код:

Formatter formatter = new XMLFormatter(); 
Vehicle vehicle = new Car(formatter); 
vehicle.applyFormat(); 

formatter = new XMLFormatter(); 
vehicle = new Truck(formatter); 
vehicle.applyFormat(); 

formatter = new POJOFormatter(); 
vehicle = new Truck(formatter); 
vehicle.applyFormat(); 

связанная почта:

When do you use the Bridge Pattern? How is it different from Adapter pattern?

Answer 6

Я хочу добавить дженерики к ответу Фредерикса.

public class Car extends Vehicle 
{ 
    public void Accept(VehicleFormatter v) 
    { 
     v.Visit (this); 
    } 
} 

public class Truck extends Vehicle 
{ 
    public void Accept(VehicleFormatter v) 
    { 
     v.Visit (this); 
    } 
} 

public interface VehicleFormatter<T extends Vehicle> 
{ 
    public void Visit(T v); 
} 

public class CarXmlFormatter implements VehicleFormatter<Car> 
{ 
    //TODO: implementation 
} 

public class TruckXmlFormatter implements VehicleFormatter<Truck> 
{ 
    //TODO: implementation 
}