Создание библиотеки лучших практик Java для гибкого создания классов (Factory Pattern, абстракция и интерфейсы) - PullRequest
Новая
       27

Создание библиотеки лучших практик Java для гибкого создания классов (Factory Pattern, абстракция и интерфейсы)

1 голос
/ 16 марта 2011

Представьте, что я разработчик программного обеспечения на Java для производителя автомобилей.Мне было поручено создать библиотеку, которая будет использоваться многочисленными внутренними приложениями.Для каждого типа модели автомобиля я создаю объект Java, представляющий эту модель.Я должен быть в состоянии отслеживать не только текущие модели, но и модели-прототипы.У прототипов моделей будет одно имя, которое, скорее всего, изменится, как только оно поступит в производство.Мне нужно иметь возможность использовать библиотеку для учета прототипов и гибкости при смене имени, когда они переводятся в производство.

У меня вопрос: какой подход лучше для этого?

Вот мои мысли ...

Я читал несколько книг для идей, как лучше всего справиться с этой ситуацией.Сразу же мой разум переходит к использованию заводского шаблона.У меня был бы класс CarModelFactory, который возвращал бы конкретный объект для каждой модели.Например: 

public class CarModelFactory() {

    public CarModel createCivicModel() {}
    public CarModel createAccordModel() {}
    public CarModel createPrototype1() {
        return new ModelX();
    }
    public CarModel createPrototype1() {
        return new ModelY();
    }

Это будет лучшим подходом?Я чувствую, что должен быть еще один уровень абстракции.Я вижу следующие проблемы:

1) Что если ModelX войдет в производство, я создам для него метод и добавлю что-то еще в метод createPrototype1, теперь программы, вызывающие этот метод, получают неправильный объект

2) Как мне обращаться с ModelX, меняя свое имя?

Я благодарю вас за потраченное время!

1 Ответ

2 голосов
/ 16 марта 2011

Заводская модель звучит хорошо, но я бы предложил метод createCarModel(String model), который ищет на карте соответствующий объект. Затем переименование модели автомобиля просто добавить / удалить на этой карте. Разумеется, с соответствующей синхронизацией, чтобы предотвратить переименование и получение.

Карта, скорее всего, будет Map<String, Class<? extends CarModel>>, а метод createCar создаст экземпляр класса с помощью конструктора без аргументов, который вам потребуется для всех Car с.

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

Кроме того, если вы переопределите ClassLoader, вы можете выгрузить старую модель и загрузить новую модель, что позволит поддерживать в чистоте фактический каталог, содержащий ваши файлы .class (никаких старых классов-прототипов, которые с тех пор были преобразованы в настоящие модели).

...