Нарушает ли паттерн Скала открытый/закрытый принцип?

Question

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

Pro:Odersky1 а такжеOdersky2

Против:Без

Комментарии довольно хороши в каждом случае. Так что, соответствует ли шаблону что -то, что я должен быть взволнован или чем -то, что я должен избегать использования? На самом деле, я полагаю, что ответ «зависит от того, когда вы его используете», но каковы некоторые позитивные варианты использования для него и какие негативные?

Answer 1

Джефф, я думаю, что у вас есть правильная интуиция: это зависит.

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

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

Каноническим примером для подхода OO является программирование GUI. Элементы графического интерфейса должны поддерживать очень небольшую функциональность (рисование на экране - это минимум), но новые элементы графического интерфейса добавляются все время (кнопки, таблицы, диаграммы, ползунки и т. Д.). Канонический пример подхода сопоставления шаблонов - компилятор. Языки программирования обычно имеют относительно фиксированный синтаксис, поэтому элементы синтаксического дерева будут изменяться редко (если вообще когда -либо), но новые операции на синтаксических деревьях постоянно добавляются (более быстрые оптимизация, более тщательный анализ типа и т. Д.).

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

Answer 2

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

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

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

Что касается того, где его следует использовать, это полностью по вкусу. Если он сделает ваш код более кратким и поддерживаемым, используйте его! В противном случае не так. Для большинства объектно-ориентированных программ сопоставление шаблонов не нужно. Однако, как только вы начнете интегрировать более функциональные идиомы (Option, List, и т. Д.) Я думаю, что вы обнаружите, что сопоставление схем значительно уменьшит синтаксические накладные расходы, а также повышает безопасность, предлагаемую системой типа. В целом, каждый раз, когда вы хотите извлечь данные при одновременном тестировании некоторого условия (например, извлечение значения из Some), сопоставление рисунков, вероятно, будет полезно.

Answer 3

Сопоставление рисунков определенно хорошо, если вы выполняете функциональное программирование. В случае OO, есть некоторые случаи, когда это хорошо. В самом примере Седрика это зависит от того, как вы просматриваете print() Метод концептуально. Это поведение каждого Term объект? Или это что -то за пределами этого? Я бы сказал, что это снаружи, и имеет смысл выполнять сопоставление рисунков. С другой стороны, если у вас есть Employee Класс с различными подклассами, это плохой выбор дизайна для сопоставления рисунков на атрибуте (скажем, имя) в базовом классе.

Также Matching Pattern Satching предлагает элегантный способ распаковки членов класса.