Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.21.233.41] |
|
Сообщ.
#1
,
|
|
|
Задача: реализовать решение СЛАУ несколькими методами (LU, простая итерация и т.д., не суть).
Решил попробовать придерживаться ООП, в идеале концепции(соглашения?) SOLID. Для своей задачи сначала решил использовать один класс (не учитывая всякое GUI) Matrix. В нем бы и были реализованы все методы отдельными функциями и хранил бы он двумерный массив, над которым и происходила бы вся работа. Но правильно ли я понимаю, что сразу же нарушаю принцип единственной обязанности(из Solid)? Ведь если рассматривать мой класс, как некоторый универсальный класс, который описывает такой объект - как матрицу и возможные операциями над ней, то вешая на этот класс ещё и решение СЛАУ получаю: а)Смысловое противоречие(или плохую абстракцию) ведь матрицы это матрицы, то, что через них(с помощью них) можно решать слау - это частный случай и возможно стоит вынести это в отдельный дочерний(или не обязательно дочерний) класс. б)Как раз нарушение "единственной обязанности". Мало того, что класс описывает матрицу и операции над ними, так он ещё и слау решает. Вопрос первый: Разделить на два класса или оставить все в одном? Т.е. сделать класс матриц и некоторый класс Х. В первом будет все, что касается самих матриц и работы над ними, во втором будет надстройка над первым(не совсем вижу смысл делать отдельный класс, как полностью независимый) и в него будет входить решение самих СЛАУ. Вопрос второй: Мои выводы верны или я ошибаюсь, если второе, то было бы неплохо указать на ошибку в моей логике. P.s. если недостаточно информации, пишите - добавлю. P.p.s. Студент, поэтому некоторые вещи могут быть очевидными для многих, просьба учесть то, что я учусь, поэтому и прошу совета. |
Сообщ.
#2
,
|
|
|
Разделение безусловно необходимо. И ты сам понимаешь, почему:
Как раз нарушение "единственной обязанности". Мало того, что класс описывает матрицу и операции над ними, так он ещё и слау решает. 1. По смыслу, класс матрицы должен содержать только методы хранения данных, доступа к ним, плюс неразрывно связанные с матрицей операции - вычисление детерминанта, обращение... и т.п. 2. И тогда напрашивается еще один класс - "решатель СЛАУ". А его методы могут просто принимать матрицу как параметр и производить необходимые вычисления. Методы, кстати, могут быть и статическими, если это будет удобнее. 3. А вот никакой связи "предок - потомок" между этими классами не усматривается. |
Сообщ.
#3
,
|
|
|
Цитата MoonGuard @ во втором будет надстройка над первым(не совсем вижу смысл делать отдельный класс, как полностью независимый) и в него будет входить решение самих СЛАУ. Надстройка = класс-наследник? Если да, то вы рекурсивно свели задачу к предыдущей, а именно имеете один класс, реализующий и операции над матрицами, и решение СЛАУ Коллега выше уже описал - бить на два класса и точка. Один класс описывает матрицу, второй - решатель СЛАУ. Однако отмечу, что если в задаче стоит необходимость решения СЛАУ разными способами, то решатель СЛАУ не должен иметь статических методов. При таком раскладе, в дополнение к классу матрицы, вырисовывается контракт (интерфейс): алгоритм решения СЛАУ. Его единственная задача - получив на вход матрицу, выдать ответ и не более того. И каждый метод решения задачи - отдельный класс, реализующий данный интерфейс. И решатель СЛАУ принимает в конструкторе ссылку на конкретную реализацию метода решения СЛАУ, а в метод "решить СЛАУ" - ссылку на входные данные (матрицу). И затем делегирует решение системы уравнений переданному в него объекту-алгоритму. Но так стоит делать, если это задача по изучению ООП, а не по методам вычислений |
Сообщ.
#4
,
|
|
|
Цитата deil @ Коллега выше уже описал - бить на два класса и точка. Один класс описывает матрицу, второй - решатель СЛАУ. Однако отмечу, что если в задаче стоит необходимость решения СЛАУ разными способами, то решатель СЛАУ не должен иметь статических методов. Поддерживаю это мнение. |