Вопрос о шаблоне разработки

Итак, вы расширяете класс вместо реализации интерфейса. Если бы у вас были классы Bus, Car, Truck, Train, и все они реализовали IVehicle, для которых требовалась функция, возвращающая значение, доступное для сортировки / поиска, вы могли бы ссылаться на все из них как на тип IVehicle и вызывать этот метод для всех. .

Код ActionScript 3:

package com.transportation.methods {
  public interface IVehicle {
    function getSpeed():Number;
    function getOtherSortableOrSearchableValue():*;
  }
}

и

public class Car extends Sprite implements IVehicle

Вам необходимо определить getSpeed ​​() и getOtherSortableValue () в классе Car, и вы можете ссылаться на него как на автомобиль, так и на транспортное средство. Поскольку все виды транспорта в моем примере будут реализовывать IVehicle, пока вы ссылаетесь на них как на IVehicles, вы можете вызывать эти две функции.

Кажется, вы описываете, что Стив Йегге называет универсальным шаблоном проектирования.

Использование пар ключ-значение с графическим интерфейсом может работать в простых случаях, но сложно добиться, чтобы он выглядел хорошо. Если ваша иерархия объектов не является глубокой и не должна быть очень расширяемой, вы можете захотеть создать отдельную форму для каждого конкретного класса, так как это меньше работы и будет выглядеть лучше. Вы по-прежнему можете повторно использовать общие компоненты графического интерфейса, поэтому добавление нового конкретного класса должно быть довольно простым.

This seems to me like some sort of "centralized" Repository pattern. I don't think that's a good idea.

What you recommend you do is, instead of having one centralized way of generalized searching, you should have several specialized repositories: one for cars, one for boats, one for planes, etc.

Each of the repositories knows about the details of the respective objects. You can then factor out common operations between these specialized repositories, to a Repository base class or interface. When you don't care about the details, you use the base Repository interface. When you care about the details you use the specialized Repository.

Here's a simplistic example in Java (I'm leaving getters/setters out for shortness - don't make your fields public):

interface Vehicle { int id; int maxSpeed; }
class Car implements Vehicle { int doors; int id; int maxSpeed; }
class Boat implements Vehicle { int buoyancy; int id; int maxSpeed; }
class Plane implements Vehicle { int wingSpan; int id; int maxSpeed; }

interface VehicleRepository<T extends Vehicle> {
    T getFastest();
    T getSlowest();
    T getById(int id);
}

interface CarRepository inherits VehicleRepository<Car> {
    List<Car> getCarsWithTwoDoors();
}

interface BoatRepository inherits VehicleRepository<Boat> {
    Boat getMostBuoyantBoat();
}

interface PlaneRepository inherits VehicleRepository<Plane> {
    List<Plane> getPlanesByWingspan();
}

Похоже, это работа для шаблона "Посетитель". У вас есть коллекция абстрактных объектов, и вы не знаете, что это за каждый из них. Используя Visitor, вы можете перебирать все объекты и выполнять действие, специфичное для каждого из них. В книге «Шаблоны GOF» подробно описан шаблон «Посетитель», но я постараюсь привести здесь хороший пример Java.

public class Vehicle {
    public void accept( VehicleVisitor visitor ) {
        visitor.visit( this );
    }
}

public interface VehicleVisitor {
    public void visit( Vehicle vehicle );
    public void visit( Car car );
    public void visit( Bus bus );
    public void visit( Truck truck );
    // Augment this interface each time you add a new subclass.
}

public class Car extends Vehicle {
    public void accept( VehicleVisitor visitor ) {
        visitor.visit( this );
    }
}

public class Bus extends Vehicle {
    public void accept( VehicleVisitor visitor ) {
        visitor.visit( this );
    }
}

public class Truck extends Vehicle {
    public void accept( VehicleVisitor visitor ) {
        visitor.visit( this );
    }
}

public class VehicleSearch implements VehicleVisitor {
    protected String name;
    public List<Vehicle> foundList =
        new ArrayList<Vehicle>();
    public VehicleSearch( String name ) {
        this.name = name;
    }
    public void visit( Vehicle vehicle ) {
        return;
    }
    public void visit( Car car ) {
        if ( car.getModel().contains( name ) ) {
            foundList.add( car );
        }
    }
    public void visit( Bus bus ) {
        if ( bus.getManufacturerModel().contains( name ) ) {
            foundList.add( bus );
        }
    }
    public void visit( Truck truck ) {
        if ( truck.getLineModel().contains( name ) ) {
            foundList.add( truck );
        }
    }
}

public class Manager {
    protected List<Vehicle> vehicleList;
    public List<Vehicle> search( String name ) {
        VehicleSearch visitor =
            new VehicleSearch( name );
        for ( Vehicle vehicle : vehicleList ) {
            vehicle.accept( visitor );
        }
        return visitor.foundList;
    }
}

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

Однако один недостаток шаблона Visitor , заключается в том, что при добавлении нового класса посещаемого объекта необходимо изменить самого посетителя. В этом примере если вы добавляете в систему транспортное средство RocketShip, вам нужно будет добавить посетителю метод visit (RocketShip rocketShip) .

Вы можете смягчить эту проблему, создав шаблон VehicleVisitorTemplate со всеми переопределенными методами посещения . Ваши операции создают подкласс шаблонного класса, а затем вам нужно только переопределить необходимые методы. Когда вам нужно добавить новый класс и метод посещения, вы добавляете его в интерфейс и класс шаблона, и тогда все остальные операции не нужно обновлять без необходимости.

Ваши операции создают подкласс шаблонного класса, а затем вам нужно только переопределить необходимые методы. Когда вам нужно добавить новый класс и метод посещения, вы добавляете его к интерфейсу и классу шаблона, и тогда все ваши другие операции не нужно обновлять без необходимости.

Ваши операции создают подкласс шаблонного класса, а затем вам нужно только переопределить необходимые методы. Когда вам нужно добавить новый класс и метод посещения, вы добавляете его в интерфейс и класс шаблона, а затем все остальные операции не нужно обновлять, если это не необходимо.

Звучит как пример использования шаблона спецификации.

http://en.wikipedia.org/wiki/Specification_pattern

http://devlicio.us/blogs/ casey / archive / 2009/03/02 / ddd-the-спецификация-pattern.aspx

Удачи!

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

Я бы сделал это так, чтобы абстрактный класс имел абстрактный метод, который возвращает значение идентификатора (скажем, значение перечисления), которое указывает, к какому конкретному типу относится объект, и каждый конкретный класс переопределяет это значение, чтобы вернуть его значение идентификатора.

Или я бы попытался использовать средства RTTI C ++ или функция Python instanceof () .

Помогает ли это, или я отвечаю не на тот вопрос?

I don't see what language you're using, but why not have the abstract class implement the interface? That way, it won't matter how many concrete classes you have as long as they all inherit from the abstract class, which implements the interface.

Here's how the hierarchy would look if you are using Java:

public interface IVehicle {/*your code goes here*/}

public abstract class AbstractVehicle implements IVehicle{/*your code goes here*/}

public class Car extends AbstractVehicle{/*your code goes here*/}

These would all, of course, be defined in different files.