forum.boolean.name

forum.boolean.name (http://forum.boolean.name/index.php)

- Алгоритмика (http://forum.boolean.name/forumdisplay.php?f=21)

- - ООП (http://forum.boolean.name/showthread.php?t=17044)

Прочитал тут простыню на хабре. И даже согласен, а что вы думаете по этому поводу?

Лично меня ну очень утомил труЪ ООП подход, который сейчас в моде - "ООП ради ООП".
Часто чтоб сделать простое действие вижу пяток классов, которые призваны делать одно действие и один раз.
Такое впечатление, что ООП взращивает поколение Чарльзов Дикенсов, а не программистов.

Ответ: ООП

МНЕ НРАВИТСЯ ООП ПОДХОД К ПРОГРАММИРОВАНИЮ. Я ПОЛУЧАЮ ЭСТЕТИЧЕСКОЕ УДОВОЛЬСТВИЕ ОТ ГРАМОТНО ОРГАНИЗОВАННОГО ВЗАИМОДЕЙСТВИЯ КЛАССОВ. ВОЗМОЖНО, Я - ЧАРЛЬЗ ДИККЕНС.

Ответ: ООП

Цитата:

Сообщение от Harter (Сообщение 233173)

Есть опыт сравнения с другими подходами? (я не про блиц-стайл)
И да, я тут не гоню на юнити. Там ещё относительно всё в порядке.

Ответ: ООП

Цитата:

Сообщение от Randomize (Сообщение 233175)

Да не особо) Я на объектно-ориентированное как раз после директивного перешел, да еще и почти сразу в Unity, поэтому мне так уютно и хорошо. :)
Перед тем еще писал на "чистых" плюсах... чуть более утомительно, но все равно особого бугурта не испытывал.

А какие вообще есть годные альтернативы?

Ответ: ООП

Вложение 17194

раньше пилили всё ООП, но теперь юзаем ООП только как синтаксический сахар (методы и protected-private, нет наследования и виртуальных методов)

из-за отсутствия стандарта на ABI пришлось самому писать указатель на метод (через прокси функцию) и считать что поля располагаются в памяти в таком же порядке как и в коде, плюс выравнивание тоже ручками (помните что в ARM надо чтобы флоаты были на 4 выравнены, а в MIPS чтобы каждый тип выравнен на свой размер - short на 2 байта, int и float - на 4 байта, но мы MIPS не держим :crazy:), расковыривать руками vtable оказалось как-то лениво в итоге

ps. и да, никаких ексепшенов, никакого rtti, никакого stl, никаких realloc :crazy:

ps2. и да, почти всё стараемся писать в map-reduce-by-design стиле, те массив данных и функция которая обрабатывает 1 элемент из него, это очень хорошо ложится на многопоточность в итоге, хотя бы с помощью OpenMP

Ответ: ООП

У Страуструпа целый раздел посвящён, так сказать, философии программирования (никак не найду время изучить его более досконально).
Эпиграф к нему:

Цитата:

Сообщение от 24 Проектирование и программирование

Стремитесь, чтобы все было просто:
просто, как только возможно, но не проще того.
— А. Эйнштейн

Далее приведу фрагмент про классы:

Цитата:

Сообщение от 24.3.1. Что представляют собой классы

Начинающим обычно бывает трудно выявлять классы, но проблема эта
рассасывается со временем без долговременных последствий. Затем, однако, наступает
фаза, когда классы и классовые иерархии размножаются неконтролируемым
образом. Это, как раз, может вызвать долговременные проблемы, усложнив программу
и затруднив ее понимание и сопровождение. Не нужно каждую мелкую деталь
системы обязательно представлять классом, и не всякую взаимосвязь нужно
отражать в форме наследования классов. Цель проектирования — смоделировать
систему с соответствующим уровнем детализации и на соответствующем уровне
абстракции. Нахождение баланса между простотой и общностью — это не простое
дело.

В обзоре языка там же написано:

Цитата:

Сообщение от 2.8. Заключение

Не существует идеальных языков программирования. К счастью, язык и не
обязан быть идеальным, чтобы быть подходящим инструментом для создания больших
программных систем. На самом деле, язык программирования общего назначения
не может быть идеальным одновременно для всех решаемых с его помощью задач.
То, что идеально для одной задачи, в другой является скорее недостатком, ибо
достижение совершенства предполагает специализацию. Язык C++ разрабатывался
так, чтобы он служил хорошим инструментом для решения широкого круга задач,
и чтобы на нем можно было явно выразить широкий круг идей (идиом
программирования).
Не все можно выразить непосредственно, пользуясь встроенными средствами
языка. Но это и не нужно. Средства языка существуют для поддержки
разнообразных технологий и стилей программирования. Как следствие, в процессе изучения
языка нужно фокусироваться на освоении стилей программирования, для него
родных и естественных, а вовсе не на подробнейшем изучении мельчайших деталей
языковых конструкций.
В практическом программировании мало толку от знания «потайных мест»
языка или от применения максимально возможных средств. Отдельные средства языка
сами по себе не представляют большого интереса. Только во взаимодействии с
другими средствами и в контексте применяемой технологии они приобретают смысл
и интерес. Так что, читая последующие главы, помните, что истинной целью
изучения деталей языка является стремление научиться использовать их так, чтобы
поддерживать выбранный стиль программирования в контексте основательного плана
построения программной системы.

А вообще - принцип Бритвы Оккама рулит (и, кстати, Страуструп тоже его упоминает)

Ответ: ООП

Цитата:

Сообщение от Harter (Сообщение 233183)

А какие вообще есть годные альтернативы?

Это в википедии можно посмотреть. Я не агитирую никуда переходить/переползать.

Мне надоели Маяковские да Толстые. Это когда чтоб реализовать простую задачу из разряда:
1) прочитать файл
2) выбрать нужные данные
3) записать выбранные данные куда либо
Пишут 6-8 классов.

Таки да. При этом активно используется наследование и инкапсуляция. Но нужно ли оно?
Мой максимальный лимит вложенности наследования это 3 вложенных наследника. И то я потом сократил до 1 наследника.
По моему сама концепция ООП уж очень утопична. Многим программистам прямо дух захватывает и они стараются написать "божественный" класс на все времена и случаи жизни. Этот класс растёт и цветёт, а потом приобретает себе ещё букет фабрик да менеджеров. По факту получается что текста много - профита мало.

Мне приходится достаточно тесно работать с чужим кодом и я вижу что народ ударился в "графоманию" очень не слабо. Сейчас я имею в виду PHP 5.3, но я думаю в остальных яп есть похожие моменты. Иной раз открыв чужую самописную CMS или иной веб сервис я не понимаю откуда у автора столько времени и сил. Ведь раз я ковыряюсь в его коде он точно простофиля несмотря на весь его ООП фанатизм. Было дело выкинул из одного агрегатора аж 30 файлов с классами. Там были классы а-ля

PHP код:


		
			
Class ArraySortHelper_IntKey Extends ArraySortHelper{
       public function sort(array $array){ /*. тут типа реализация, но она всего в 5-10 строк .*/ }
}

Юзались эти классы 1-2 раза собственно в приложении.

Ответ: ООП

Цитата:

Мне надоели Маяковские да Толстые. Это когда чтоб реализовать простую задачу из разряда:
1) прочитать файл
2) выбрать нужные данные
3) записать выбранные данные куда либо
Пишут 6-8 классов.

тут в чем прикол...
если пользователь либы пишет для этого 5-8 классов, то это пипец.
если автор либы пишет 5-8 классов, то видимо либа умеет читать не только с файла, а еще с памяти, с сети, с зип-архива, и напрямую с мозга пользователя. причем неважно сколько в либе классов, пользователь должен вызвать:

Код:

file->open("file.txt");

file->read(somevalue);

file->write(someelsevalue);

file->close();

если пользователь вызывает:

Код:

file = FILESYSTEM<LoaclFile>()::getSingeltonPtr()->create("file.txt")->getPointer<Shared>();

file->access<Shared>()->getData(0,0,42,somevalue,42,0,0,FILESYSTEM<LoaclFile>()::getSingeltonPtr()->getDefaultReadFactor());

file->access<Shared>()->getData(0,0,42,somevalue,42,0,0,FILESYSTEM<LoaclFile>()::getSingeltonPtr()->getDefaultWriteFactor());

file->close(FILESYSTEM<LoaclFile>()::getSingeltonPtr()->getFlushOnCloseFactor());

то автор либы конченный чудак.

Ответ: ООП

Что отвечать в опросе, если

Цитата:

Сообщение от Harter (Сообщение 233173)

?

Почему-то первый вариант ответа утверждает, что надо делать из классов всё, даже небо, даже иисуса, второй же - использовать классы в 1.5 местах, не более.
Возможно, автор опроса - Дядя Петя.

Ответ: ООП

Автор темы не знаком с таким направлением как Архитектуринг, что есть аналитический подход к задаче как с общей точки зрения так и с деталей базируясь возможностям проектирования на выбранном языке/ках.
Использую OOP, но не задрачиваюсь слишком тупо, т.к. бесит когда уже есть перебор абстрактных классов, и где разработка становиться просто адом.
Также не нравиться когда разработчики API считают что определённый кастинг одной сущности в другую - доступная процедура, когда логически и интуитивно сущности имеют реально не много общего с точки зрения пользователя.

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

Также если разрабатываю что-то, всегда задумываюсь о том, кто будет использовать интерфейс, пользователь (я или кто-то другой) или разработчик интерфейса. Когда разрабатываешь интерфейс, стараюсь не плодить классы, но и не писать сущности отвечающие за несколько операций, лучше инкапсулировать.
А вот пользователь должен видеть простой и удобный интерфейс, который прозрачно сам о себе говорит.
Лучший интерфейс - это когда пользователь знаком с общей концепцией и принципами, и затем используя Intellisense может программировать, практически не обращаясь в документацию.

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

Зла в ООП нету.
Я ежедневно пишу на процедурных, событейных и ООП языках, и ООП люблю.

Ответ: ООП

Цитата:

Также если разрабатываю что-то, всегда задумываюсь о том, кто будет использовать интерфейс, пользователь (я или кто-то другой) или разработчик интерфейса.

та же фигня, бро!

Ответ: ООП

Цитата:

Сообщение от HolyDel (Сообщение 233209)

если пользователь вызывает:

Код:

file = FILESYSTEM<LoaclFile>()::getSingeltonPtr()->create("file.txt")->getPointer<Shared>();

file->access<Shared>()->getData(0,0,42,somevalue,42,0,0,FILESYSTEM<LoaclFile>()::getSingeltonPtr()->getDefaultReadFactor());

file->access<Shared>()->getData(0,0,42,somevalue,42,0,0,FILESYSTEM<LoaclFile>()::getSingeltonPtr()->getDefaultWriteFactor());

file->close(FILESYSTEM<LoaclFile>()::getSingeltonPtr()->getFlushOnCloseFactor());

то автор либы конченный чудак.

В точку. Именно так оно обычно и выглядит.

Ответ: ООП

Цитата:

Сообщение от jimon (Сообщение 233192)

ps. и да, никаких ексепшенов, никакого rtti, никакого stl, никаких realloc :crazy:

со всем согласен, но realloc-то за что???

Цитата:

Сообщение от jimon (Сообщение 233192)

ps2. и да, почти всё стараемся писать в map-reduce-by-design стиле

одобряю, малацы!:super:

Ответ: ООП

Цитата:

Сообщение от ffinder (Сообщение 233274)

тема про недостатки ООП, как подхода, так что не будем углубляться в недостатки сиплюсов.

А и действительно! Сделал отдельную тему.