Должен ли я использовать ООП, когда инкапсуляция по существу игнорируется?

Question

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

Я буду использовать мой Matrix класс в качестве простого примера. Matrix имеет следующие атрибуты:

• имя (тип String) (хранит название этой матрицы)
• размер (тип array) (хранит # строк и # столбцов этой матрицы)
• записи (тип array) (хранит записи этой матрицы)
• is_invertible (тип Boolean) (хранит, может ли эта матрица быть инвертирована)
• определитель (тип Int) (хранит определитель этой матрицы)
• транспонировать (тип array) (сохраняет транспонирование этой матрицы)

Создание новой матрицы с именем A будет сделано так:

$A = new Matrix("A");

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

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

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

1. Является ли ООП лучшим способом структурировать код, несмотря на то, что он по существу игнорирует инкапсуляцию?
2. Существует ли альтернатива ООП, которая обеспечивает высокий пользовательский доступ при сохранении "аромата" ОО (т. Е. Сохранение наборов, матриц и т. Д. В качестве объектов)
3. Можно ли вообще время от времени нарушать правило инкапсуляции, если проблема требует этого? Или это не в духе ООП?

Answer 1

1. То, что вы пытаетесь сделать, не обязательно выходит за рамки ООП. Дело в том, что у вас есть модель, отличная от той, которая обычно описывается в учебниках по программированию (где, например, значения матрицы всегда будут присутствовать и все функции могут быть простыми методами). (Возможно, именно поэтому вопрос был несправедливо опущен.) Ничто не мешает вам хранить такие значения, как "is_invertible", и реализовывать методы setter и getter. Это может иметь смысл, если вы пытаетесь изучить ООП. Но я думаю, что другие проблемы (см. Учебники по кодированию) могут быть проще в учебных целях. Я вижу, что удаленной целью было бы получить некоторые математические знания в качестве основы ООП. Но вся математическая вселенная намного богаче любой фиксированной архитектуры (результаты, подобные теореме Геделя, ставят теоретический предел). Вы можете преуспеть только в разработке структуры для очень узкого приложения, например, для решения определенных уравнений. Это то, что делают программы символической алгебры: вы можете посмотреть, как, например, реализованы SymPy или, возможно, части Maple и Mathematica. На мой взгляд, парадигма ООП может быть как очень полезной, так и слишком ограничительной / ненужной в зависимости от задачи (вы можете узнать больше о недостатках ООП в Википедии или где-либо еще). Кроме того, ваша проблема заключается в написании небольшого языка программирования - во многих из них у вас есть наборы, числа и т. Д. В качестве объектов.

2. Вы можете использовать только элементарный ООП или вообще не использовать ООП. Вы можете использовать функциональное программирование.

3. Вы должны Google / узнать больше об этом на этом или других сайтах. Можно ли иногда переходить дорогу, когда включен красный светофор?