Проблема Именование интерфейса

У меня есть интерфейс с именем PropertyFilter, который использовался для принятия Property и решил, принимает ли он это или нет. И мир был хорош.Проблема Именование интерфейса

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

Я думаю, что это очевидно, что это не фильтр, но как бы вы назвали это?

Для уточнения: так называемый фильтр в значительной степени метод с подписью

Property -> List<Property>

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

источник

2010-06-09 Jens Schauder

По-прежнему кажется фильтром для меня. «Фильтр [T]» обычно представляет собой некоторую функцию 'T -> Boolean', которая по-прежнему кажется. –

Почему вас интересует Property в PropertyFilter? Почему бы просто не иметь интерфейс фильтра? – mathk

@mathk Мы выбираем PropertyFilter над фильтром, потому что в нашей базе кода уже есть два фильтра и около gazillion в используемой нами библиотеке. Но вопрос в самом деле о части фильтра имени. –

PropertyChecker
PropertyValidator
PropertyDistillator
PropertyAccreditor ...

У Вас уже есть имя метода вы упоминаете? Это может помочь нам найти правильное имя для интерфейса.

источник

2010-06-21 09:52:25 guillaume31

метод в настоящее время называется 'expand' –

ОК, поэтому интерфейс несет смешанную ответственность за проверку и расширение свойств. Вы можете использовать более общее имя, например PropertyManager или PropertyHandler. Или вы можете разделить 2 обязанности в 2 отдельных классах, PropertyValidator и PropertyExpander с одним вызовом другого. Я полагаю, что решение зависит от того, как клиентский код использует интерфейс, и от того, знает ли клиентский код аспект валидации или аспект расширения (или оба). – guillaume31

Я не уверен, что делает ваша новая функция. Если он все еще возвращает логическое значение, тогда другое имя для функции, которая возвращает логическое значение, является «предикатом».

Если он принимает Заказчика и разлагает его (возможно, у вас есть одна функция, которая берет Клиента и возвращает имя, а другая, которая возвращает адрес), то я могу назвать их «аксессурами». Этот термин часто используется для описания функции-члена объекта, но я думаю, что он может применяться и здесь. не

источник

2010-06-09 07:19:42 archbishop

См. Мой обновленный вопрос, предикат не подходит, я не думаю, что аксессоры подходят ... –

Если Customer имеет Name и и Address, то он больше не является свойство, но сущность.

Свойство Customer может быть ссылкой к Customer сущности, в этом случае по-прежнему применяются семантическая конвенция для интерфейса.

источник

2010-06-09 07:28:37

-1

Я хотел бы добавить метод, названный validate в Property с подписью:

PropertyFilter -> Bool

Реализация по умолчанию validate просто проходит this (свойство) к фильтру и возвращает результат:

def validate (filter: PropertyFilter) = filter (this)

В качестве составного свойства Customer переопределяет validate, реализуя его с точки зрения его составных свойств:

override def validate (filter: PropertyFilter) = name.validate (filter) && address.validate (filter)

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

источник

2010-06-21 09:59:55

Проблема Именование интерфейса

ответ

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