Имеет ли смысл создавать хранилище, которое принимает критерий поиска по умолчанию в качестве аргумента конструктора?

Question

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

Туристическое агентство имеет два подразделения, которые имеют собственный веб-сайт и ориентированы на разные группы клиентов. Бэкэнд, однако, одинаков для обоих сайтов. Они оба обращаются к одним и тем же таблицам БД. В некоторых таблицах просто есть столбцы, которые определяют, для какого деления предназначены записи.

Давайте представим, что я хочу создать TripRepository, который сможет возвращать объекты Trip. Считаете ли вы, что имеет смысл создать репозиторий, который принимает Отдел в качестве аргумента конструктора? Так что все результаты будут только для этого отдела?

Другими словами, в псевдокоде:

class TripRepository
{
    method constructor( Devision );

    // this will then only return Trips for the Devision passed to the constructor
    method findAllTrips( /* some other criteria */ );
}

Конечно, я мог бы иметь его в качестве необязательного аргумента конструктора, и даже иметь установщик для переключения Devisions, если это необходимо ... но в целом есть ли что-то возражающее в этом?

Или я должен просто всегда проходить критерий Devision для всех методов поиска?

Answer 1

Если ваш метод findAllTrips (...) не имеет совершенно другой логики, основанной на "Devision" (не должно быть Деление, кстати?), Нет причин создавать отдельные экземпляры. И даже если вы по какой-то причине сделаете это, я полагаю, вам придется поместить экземпляры объектов в какую-то другую коллекцию, где они будут доступны с использованием ... Devision в качестве ключа (то есть параметра).

Так что лично я думаю, что это не было бы хорошим дизайнерским решением: оно не выглядит интуитивно понятным, и тот, кто встретит это в вашем коде в будущем, вероятно, задастся вопросом, каков был настоящий мотив пойти по этому пути.