"Для чего нужно ООП?"

5 views
Skip to first unread message

brox

unread,
Mar 27, 2009, 5:52:03 AM3/27/09
to Sapka
> Эх... Ладно, поехали. Расскажите мне, для чего нужен ООП? Для какого
> класса задач он является лучшим выбором? (только давайте не в этом
> трэде -- тут и так уже оффтопа много).

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

Taykalo Paul aka Kilew

unread,
Mar 27, 2009, 6:05:31 AM3/27/09
to Sapka
Модульная система / Система плагинов, работа через интерфейсы.
Намного проще с ООП подходом.

Gleb Golubitsky

unread,
Mar 27, 2009, 6:05:39 AM3/27/09
to sapka-...@googlegroups.com
>Я сам не сторонник ООП, несмотря на то, что ежедневно пользуюсь этим на работе.

А чем, кроме ООП приходилось пользоваться?...


> Просто если есть достаточно большой проект (скажем, миллион строк кода), то вести такой проект без технологий ООП, мягко говоря, затруднительно.
> Да что тут говорить, возьми и попробуй сам :)

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

А задумывалось всё очень радужно: компонентная модель, можно
разрабатывать, "втыкать/вытыкать" компоненты отдельно друг от друга.
Ура-ура-ура. Но на практике получился огромный комок текущих
абстракций, завязанных на потроха друг-друга, без какого-либо
управления сложностью и без возможности отрефакторить.

При том, что задача сама по себе прекрасно (IMHO) раскладывается на стек DSL.

Gleb Golubitsky

unread,
Mar 27, 2009, 6:09:27 AM3/27/09
to sapka-...@googlegroups.com
> Модульная система

Что конкретно имеется в виду? Словосочетание достаточно абстрактное,
конкретизируйте, пожалуйста.

> Система плагинов, работа через интерфейсы.

Это задачу я уже упоминал. Тут ООП, пожалуй, оправдан. А ещё?

2009/3/27 Taykalo Paul aka Kilew <tt.k...@gmail.com>:

TT KILEW

unread,
Mar 27, 2009, 6:17:46 AM3/27/09
to sapka-...@googlegroups.com
2009/3/27 Gleb Golubitsky <rush.w...@gmail.com>:

>> Модульная система
>
> Что конкретно имеется в виду? Словосочетание достаточно абстрактное,
> конкретизируйте, пожалуйста.
Это шло как синоним к "системе плагинов". ;)

>> Система плагинов, работа через интерфейсы.
>
> Это задачу я уже упоминал. Тут ООП, пожалуй, оправдан. А ещё?
>

Надо пойти почитать про "не ООП-подходы" ;) Потому что не могу
сказать, что оно "лучше чего-то". Ибо альтернативы в данный момент у
меня нету. Тут же вопрос тогда, какие альтернативы ООП-подходу?

Oleg Homenko

unread,
Mar 27, 2009, 6:27:29 AM3/27/09
to sapka-...@googlegroups.com
Gleb Golubitsky пишет:

>> Я сам не сторонник ООП, несмотря на то, что ежедневно пользуюсь этим на работе.
>>
> А чем, кроме ООП приходилось пользоваться?...
>
>

Обычным, структурным программированием. Примерно так, как выглядят
исходники линукса :)
Но это были исключительно маленькие проекты (до 10 000 строк), которыми
занимался я один

xoposhiy

unread,
Mar 27, 2009, 8:01:14 AM3/27/09
to Sapka
Если обсуждать, на каких задачах лучше (что значит лучше, кстати, --
тоже вопрос не всегда разрешимый) себя показывает Java, а на каких
Haskel ещё хоть как-то возможно, то обсуждать, на каких задачах ООП
лучше всего остального -- вообще бред полный.

Самые базовые концепции ООП -- инкапсуляция деталей, иерархия типов и
соответствующий полиморфизм, я думаю, есть во всех языках хоть сколько-
то приспособленных к работе над большими проектами. Так что эти
концепции полезны бесспорно. А остальное -- детали и мелочи...

Dmitry Melamud

unread,
Mar 27, 2009, 9:14:50 AM3/27/09
to sapka-...@googlegroups.com
Hi!

27 марта 2009 г. 12:05 пользователь Gleb Golubitsky
<rush.w...@gmail.com> написал:

> У меня был опыт работы с большим проектом (как раз больше миллиона
> строк кода) с использованием ООП, компонентной модели, и прочих
> "радостей". Это тихий ужас. Поддерживать _это_ было практически
> нереально. Всюду скрытые зависимости, подводные камни и т.п.. Как всё
> это работает до конца не знал никто.
>
> А задумывалось всё очень радужно: компонентная модель, можно
> разрабатывать, "втыкать/вытыкать" компоненты отдельно друг от друга.
> Ура-ура-ура. Но на практике получился огромный комок текущих
> абстракций, завязанных на потроха друг-друга, без какого-либо
> управления сложностью и без возможности отрефакторить.

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

> При том, что задача сама по себе прекрасно (IMHO) раскладывается на стек DSL.

(DSL в данном случае -- это domain-specific language?)

Если введение DSL или какого-нибудь еще подхода упростит код и сделает
его ближе к набору абстракций, которыми оперирует человек, то нужно
этот подход использовать. ООП для того и было придумано -- чтобы можно
было легко ввести в язык понятия целевой предметной области и писать
высокоуровневый код с использованием этих понятий, а низкоуровневые
детали реализации скрыть.

--
SY: Dmitry E. Melamud

Reply all
Reply to author
Forward
0 new messages