-Поиск по дневнику

Поиск сообщений в eugene20237

 -Подписка по e-mail

 


Концептуальные проблемы ООП

+ в цитатник

Cообщение скрыто для удобства комментирования.
Прочитать сообщение


Аноним   обратиться по имени Пятница, 10 Мая 2013 г. 14:09 (ссылка)
А в чем собственно проблема? Есть состояние, от него зависит поведение. Чтоб это уместилось в голове, надо аккуратно пользоваться инкапсуляцией и правильно называть методы. Это не совсем проблема ООП, тоже самое можно сказать про процедуры, или даже про функции, где вычисления сильно и не понятно зависят от значения аргументов. Возможно просто не правильно выбрана семантика внутреннего состояния.
Ответить С цитатой В цитатник    |    Не показывать комментарий
eugene20237   обратиться по имени Пятница, 10 Мая 2013 г. 15:10 (ссылка)
В первом случае очень легко сказать как работает метод "аdd". Т.е. как он изменит данные. Во втором случае представить себе работу метода "add" очень сложно и невозможно предугадать как он изменит данные. Теперь масштабируем проблему и представляем что таких параметров в классе много. Далее пробуем себе представить его поведение и описать словами "что он делает?". Потом добавляем в класс новую функциональность и понимаем что это уже опасно, потому что неизвестно как должен вести себя объект в текущем состоянии. Ну а дальше ошибки. На мой взгляд это проблема.
Ответить С цитатой В цитатник
Перейти к дневнику

Суббота, 11 Мая 2013 г. 08:50ссылка
Аноним
Согласен. Это проблема и она называется сложность, ООП тут не причем. Во первых надо сначала решить, что будет делать класс, а потом уже его создавать. Но если класс уже есть, то придется потратить время и разобраться, как он работает. Название класса и методов должно в этом помогать. Когда станет понятно, что класс делает, это знание надо отобразить в модульном тесте. Если для этого нужно немного порефакторить класс, это отлично, так как это улучшит архитектуру. Так-же нет ничего плохого в разносе функциональности по разным классам, если это упростит понимание.
Есть мнение, что если нет тестов, то система не работает. Это мнение как раз появилось из-за описанной тобой проблемы.
Перейти к дневнику

Суббота, 11 Мая 2013 г. 17:38ссылка
Я хочу понять как в принципе можно (и можно ли) отрефакторить такой класс. Например, как в последнем примере: где управлющее свойство используется и на чтение и на запись. Думаю, что можно было выделить новый класс и вынести в него один из методов, в котором либо читается, либо записывается управляющее поле. Но это долго. А быстрого решения я так и не нашёл, где, например, можно было бы не создавать такого свойства, которое в одном месте устанавливается, а в другом используется.
 

Добавить комментарий:
Текст комментария: смайлики

Проверка орфографии: (найти ошибки)

Прикрепить картинку:

 Переводить URL в ссылку
 Подписаться на комментарии
 Подписать картинку