На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! В разделе обсуждаются следующие темы:
1) Процесс разработки программного обеспечения.
2) Определение требований к программному обеспечению.
3) Составные части и процесс проектирования (см. Шаблоны проектирования).
4) Документирование программного продукта(проекта).
5) Руководство разработкой программного обеспечения.
6) Проектирование пользовательского интерфейса.
7) Контроль версий проекта (см. Управление версиями в Subversion, Стратегии использования svn).
Модераторы: ElcnU
  
> Правильное разделение классов
    Задача: реализовать решение СЛАУ несколькими методами (LU, простая итерация и т.д., не суть).
    Решил попробовать придерживаться ООП, в идеале концепции(соглашения?) SOLID.
    Для своей задачи сначала решил использовать один класс (не учитывая всякое GUI) Matrix. В нем бы и были реализованы все методы отдельными функциями и хранил бы он двумерный массив, над которым и происходила бы вся работа. Но правильно ли я понимаю, что сразу же нарушаю принцип единственной обязанности(из Solid)? Ведь если рассматривать мой класс, как некоторый универсальный класс, который описывает такой объект - как матрицу и возможные операциями над ней, то вешая на этот класс ещё и решение СЛАУ получаю:
    а)Смысловое противоречие(или плохую абстракцию) ведь матрицы это матрицы, то, что через них(с помощью них) можно решать слау - это частный случай и возможно стоит вынести это в отдельный дочерний(или не обязательно дочерний) класс.
    б)Как раз нарушение "единственной обязанности". Мало того, что класс описывает матрицу и операции над ними, так он ещё и слау решает.
    Вопрос первый:
    Разделить на два класса или оставить все в одном? Т.е. сделать класс матриц и некоторый класс Х. В первом будет все, что касается самих матриц и работы над ними, во втором будет надстройка над первым(не совсем вижу смысл делать отдельный класс, как полностью независимый) и в него будет входить решение самих СЛАУ.
    Вопрос второй:
    Мои выводы верны или я ошибаюсь, если второе, то было бы неплохо указать на ошибку в моей логике.
    P.s. если недостаточно информации, пишите - добавлю.
    P.p.s. Студент, поэтому некоторые вещи могут быть очевидными для многих, просьба учесть то, что я учусь, поэтому и прошу совета.
      Разделение безусловно необходимо. И ты сам понимаешь, почему:
      Как раз нарушение "единственной обязанности". Мало того, что класс описывает матрицу и операции над ними, так он ещё и слау решает.

      1. По смыслу, класс матрицы должен содержать только методы хранения данных, доступа к ним, плюс неразрывно связанные с матрицей операции - вычисление детерминанта, обращение... и т.п.
      2. И тогда напрашивается еще один класс - "решатель СЛАУ". А его методы могут просто принимать матрицу как параметр и производить необходимые вычисления. Методы, кстати, могут быть и статическими, если это будет удобнее.
      3. А вот никакой связи "предок - потомок" между этими классами не усматривается.
        Цитата MoonGuard @
        во втором будет надстройка над первым(не совсем вижу смысл делать отдельный класс, как полностью независимый) и в него будет входить решение самих СЛАУ.

        Надстройка = класс-наследник? Если да, то вы рекурсивно свели задачу к предыдущей, а именно имеете один класс, реализующий и операции над матрицами, и решение СЛАУ :)

        Коллега выше уже описал - бить на два класса и точка. Один класс описывает матрицу, второй - решатель СЛАУ.

        Однако отмечу, что если в задаче стоит необходимость решения СЛАУ разными способами, то решатель СЛАУ не должен иметь статических методов.
        При таком раскладе, в дополнение к классу матрицы, вырисовывается контракт (интерфейс): алгоритм решения СЛАУ. Его единственная задача - получив на вход матрицу, выдать ответ и не более того. И каждый метод решения задачи - отдельный класс, реализующий данный интерфейс. И решатель СЛАУ принимает в конструкторе ссылку на конкретную реализацию метода решения СЛАУ, а в метод "решить СЛАУ" - ссылку на входные данные (матрицу). И затем делегирует решение системы уравнений переданному в него объекту-алгоритму.

        Но так стоит делать, если это задача по изучению ООП, а не по методам вычислений :)
          Цитата deil @
          Коллега выше уже описал - бить на два класса и точка. Один класс описывает матрицу, второй - решатель СЛАУ.

          Однако отмечу, что если в задаче стоит необходимость решения СЛАУ разными способами, то решатель СЛАУ не должен иметь статических методов.

          Поддерживаю это мнение.
          0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
          0 пользователей:


          Рейтинг@Mail.ru
          [ Script execution time: 0,0537 ]   [ 16 queries used ]   [ Generated: 19.03.24, 02:11 GMT ]