"Для чего нужно ООП?"
brox
> класса задач он является лучшим выбором? (только давайте не в этом
> трэде -- тут и так уже оффтопа много).
Я сам не сторонник ООП, несмотря на то, что ежедневно пользуюсь этим
на работе.
Просто если есть достаточно большой проект (скажем, миллион строк
кода), то вести такой проект без технологий ООП, мягко говоря,
затруднительно.
Да что тут говорить, возьми и попробуй сам :)
Taykalo Paul aka Kilew
Намного проще с ООП подходом.
Gleb Golubitsky
А чем, кроме ООП приходилось пользоваться?...
> Просто если есть достаточно большой проект (скажем, миллион строк кода), то вести такой проект без технологий ООП, мягко говоря, затруднительно.
> Да что тут говорить, возьми и попробуй сам :)
У меня был опыт работы с большим проектом (как раз больше миллиона
строк кода) с использованием ООП, компонентной модели, и прочих
"радостей". Это тихий ужас. Поддерживать _это_ было практически
нереально. Всюду скрытые зависимости, подводные камни и т.п.. Как всё
это работает до конца не знал никто.
А задумывалось всё очень радужно: компонентная модель, можно
разрабатывать, "втыкать/вытыкать" компоненты отдельно друг от друга.
Ура-ура-ура. Но на практике получился огромный комок текущих
абстракций, завязанных на потроха друг-друга, без какого-либо
управления сложностью и без возможности отрефакторить.
При том, что задача сама по себе прекрасно (IMHO) раскладывается на стек DSL.
Gleb Golubitsky
Что конкретно имеется в виду? Словосочетание достаточно абстрактное,
конкретизируйте, пожалуйста.
> Система плагинов, работа через интерфейсы.
Это задачу я уже упоминал. Тут ООП, пожалуй, оправдан. А ещё?
2009/3/27 Taykalo Paul aka Kilew <tt.k...@gmail.com>:
TT KILEW
>> Модульная система
>
> Что конкретно имеется в виду? Словосочетание достаточно абстрактное,
> конкретизируйте, пожалуйста.
>> Система плагинов, работа через интерфейсы.
>
> Это задачу я уже упоминал. Тут ООП, пожалуй, оправдан. А ещё?
>
Надо пойти почитать про "не ООП-подходы" ;) Потому что не могу
сказать, что оно "лучше чего-то". Ибо альтернативы в данный момент у
меня нету. Тут же вопрос тогда, какие альтернативы ООП-подходу?
Oleg Homenko
>> Я сам не сторонник ООП, несмотря на то, что ежедневно пользуюсь этим на работе.
>>
> А чем, кроме ООП приходилось пользоваться?...
>
>
Обычным, структурным программированием. Примерно так, как выглядят
исходники линукса :)
Но это были исключительно маленькие проекты (до 10 000 строк), которыми
занимался я один
xoposhiy
тоже вопрос не всегда разрешимый) себя показывает Java, а на каких
Haskel ещё хоть как-то возможно, то обсуждать, на каких задачах ООП
лучше всего остального -- вообще бред полный.
Самые базовые концепции ООП -- инкапсуляция деталей, иерархия типов и
соответствующий полиморфизм, я думаю, есть во всех языках хоть сколько-
то приспособленных к работе над большими проектами. Так что эти
концепции полезны бесспорно. А остальное -- детали и мелочи...
Dmitry Melamud
27 марта 2009 г. 12:05 пользователь Gleb Golubitsky
<rush.w...@gmail.com> написал:
> У меня был опыт работы с большим проектом (как раз больше миллиона
> строк кода) с использованием ООП, компонентной модели, и прочих
> "радостей". Это тихий ужас. Поддерживать _это_ было практически
> нереально. Всюду скрытые зависимости, подводные камни и т.п.. Как всё
> это работает до конца не знал никто.
>
> А задумывалось всё очень радужно: компонентная модель, можно
> разрабатывать, "втыкать/вытыкать" компоненты отдельно друг от друга.
> Ура-ура-ура. Но на практике получился огромный комок текущих
> абстракций, завязанных на потроха друг-друга, без какого-либо
> управления сложностью и без возможности отрефакторить.
Если уже появилась завязка на потроха друг друга, то ООП явно
применялось неправильно. В ООП все должно сводиться (в идеале) к
небольшому числу прозрачных интерфейсов, абстракций и шаблонов их
применения. Если это оказывается не так, нужно делать рефакторинг, еще
раз и еще раз, пока не получится.
> При том, что задача сама по себе прекрасно (IMHO) раскладывается на стек DSL.
(DSL в данном случае -- это domain-specific language?)
Если введение DSL или какого-нибудь еще подхода упростит код и сделает
его ближе к набору абстракций, которыми оперирует человек, то нужно
этот подход использовать. ООП для того и было придумано -- чтобы можно
было легко ввести в язык понятия целевой предметной области и писать
высокоуровневый код с использованием этих понятий, а низкоуровневые
детали реализации скрыть.
--
SY: Dmitry E. Melamud