2014-12-06 4 views
1

Вот еще один вопрос о дизайне класса и дублировании кода.Дублирование кода или нет?

Это сценарий: У нас есть класс, имеющий свойство SupportedFlow. Это свойство доступно только для чтения и возвращает список объектов FlowInfo, каждый из которых представляет поток (отправка физического файла внешней системой) с несколькими атрибутами, такими как FlowType (объект, представляющий вид потока, например «поток клиента», или «поток досье»).

Некоторые другие классы в системе, которую мы строим, должны знать список «поддерживаемого типа потока», и они могут получить его, прочитав свойство SupportedFlow указанного выше объекта и применив простой запрос LINQ: SupportedFlow.Select (p = > p.FlowType) .ToList()

Некоторым другим классам может понадобиться аналогичный список, полученный путем применения фильтра в списке SupportedFlow с помощью метода LINQ to object extension Где, для istance список поддерживаемых потоков, соответствующих любым критериям (пример: поддерживаемые клиентами потоки).

Вот мой вопрос: в таком сценарии лучший выбор дизайна, добавление новых свойств к исходному объекту (например, SupportedFlowType или CustomerRelatedSupportedFlows), которые применяют правильный запрос LINQ к исходному свойству SupportedFlow или повторяют LINQ запрашивать каждый раз, когда это необходимо в других классах системы?

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

Спасибо, что ответили.

Приветствие

ответ

0

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

Однако есть третий вариант: поместите метод в класс util. Это упрощает первоначальный объект и предотвращает дублирование кода. Единственный недостаток заключается в том, что вам нужно «знать», что есть такой класс/метод util, если он вам нужен.

+1

Спасибо, что ответили. Таким образом, вы предлагаете создать класс Util, содержащий некоторые методы, такие как «GetSupportedFlowType» или «GetCustomerRelatedSupportedFlows», который принимает список объектов FlowInfo в качестве параметров и возвращает список, полученный путем применения запроса LINQ to object. Это звучит как хороший компромисс! –

+0

@EnricoMassone да, если вы не можете реализовать 1 единственную функцию, которая может делать все на основе переданного ей параметра. Я недостаточно знаком с linq или с исходным кодом, чтобы узнать, возможно ли это –

Смежные вопросы