Теология ООП (часть II)
В этой статье я собираюсь немного попугать вас одной историей о том, как по вине стереотипного объектного мышления в мою программу вкралась весьма неприятная ошибка; далее продемонстрирую пример того, как целый класс можно запросто заменить одной-единственной функцией; и конечно же, как всегда, будет много брюзжания и критики. дальше...
Комментарии:
Полностью согласен. Бездумное применение ООП только вредит.
Как парадигма ООП несомненно полезно, но можно думать в ОО-стиле и писать на не ОО-языке.
Заслуга ОО-языков должна заключаься лишь в автоматизации и повышении комфортности написания программ, но не в навязывании неестественного образа мышления.
Поддержка ОО-парадигмы в C++ или Object Pascal по-моему оставляет желать лучшего и фактически является лишь фасадом для функционального программирования.
По-настоящему ОО-среды позволяют забыть, о том, что за фасадом прячется всё то-же функциональное программирование и по сути реализуют самый важный в ООП принцип: инкапсуляцию.
Образцом языка, позволяющего полностью думать в терминах объектов является по-моему язык Objective C.
и все-таки несогласен... Нормально формализовать логику может только ООП... Передергивание с length тут не поможет... и, честно говоря, не вижу особых премуществ length(s) и s.length()... по крайней мере во втором случае точно известно, что объект умеет вычилслять свою длину, а в первом придется еще и параметр проверять, и исключение ловить в случае чего...
Цитата:
Поддержка ОО-парадигмы в C++ или Object Pascal по-моему оставляет желать лучшего и фактически является лишь фасадом для функционального программирования.
СОГЛАСЕН НА 100%... Дельфи 4-5-6-7 - ублюдок от ООП... :)
Ошибочка:
Впрочем, перейдем от предположений к *конерктным* примерам.
И ещё одна:
Реализация - это *сосвем* другая стихия
Статья хорошая, пойду, подумаю.
Согласен полностью. Мне приятно увидеть свои собственные неозвученные мысли, оформленные в виде статьи и написанные прекрасным языком.
Я скажу по двум пунктам
1. ООП не панацея
да, это верно. Точно так же как не стоит решать все задачи циклом for, не стоит решать их и объектами. Например, не стоит под каждый удп пакет заводить отдельный объект в юзерспейсе, потому что это прямой путь к тому чтобы сожрать всю память и весь цпу безотносительно к том сколько их у тебя есть
Однако есть очень много ситуаций когда ООП рулит и очень сильно (например, позволяет сократить время разработки с 2 недель до 8 часов)
2. Куча бреда про posix threads и реализацию их в линухе
2.1 то, что рейс в pthread_create приводит к рейсу в классе-враппере - проблема класса в раппера
2.2 в общем случае реализовать wait и detach с помощью семафоров нельзя
2.3. нету никакой особой "поддержки posix threads" в 2.6. И там и там task_struct создаётся через clone. Просто NPTL, в отличие от linuxthreads, использует немножко другой набор сисколлов с другими флагами.
Stingray:
> (например, позволяет сократить время разработки с 2 недель до 8 часов)
Разница в 10 раз, то есть и код будет в 10 раз меньше? Не поверю без конкретных примеров. Скорее наоборот, не-ОО программа может быть в 10 раз меньше своего ОО аналога, и такое в моей практике случалось не раз - один такой пример есть в статье про плохой код.
Насчет "бреда" - спасибо, очень этично, и кажется я сказал насчет pthread_create, что это была моя ошибка, надо быть внимательнее.
Цитата
-----------
По-настоящему ОО-среды позволяют забыть, о том, что за фасадом прячется всё то-же функциональное программирование и по сути реализуют самый важный в ООП принцип: инкапсуляцию.
-----------
а за фасадом класса прячутся абстрактные автоматы,
причем для них можно определить наследование
Мне кажется, что проблема с pthread вызвана не столько объектной парадигмой, сколько тем, что вы использовали несогласованные понятия объектов. У вас объектом считался *поток*, а в POSIX - *описатель* потока. И это, на мой взгляд, один из крупнейших источников проблем в ООД.
quote: "... Поддержка ОО-парадигмы в C++ или Object Pascal по-моему оставляет желать лучшего и фактически является лишь фасадом для функционального программирования...."
функциональное программирование в паскаль и с++? Подробнее с этого места, если не затруднит.
Спасибо за статью, надо подумать %)
Круто.
Статья дарит надежды, что не все в программерском мире сошли с ума.
Уважаемый, вы в корне не правы. Позволю себе заранее забежать в перёд, вы не ознакомились достаточно хорошо с парадигмой ООП и с алфавитом существующих решений - паттернов.
Теперь давайте же по порядку. Вы говорили про класс и его замену функциями алгебраического вида. В общем вы правы и действительно считается абсолютно бесполезным делать класс ради функциональности, если у вас нет состояния. Хотя иногда это бывает оправдано(рассмотрите паттерны Factory method, Abstract factory, Adapter. Не всегда в них бывает реализовано состояние, но их назначение делает их абсолютно незаменимыми в этом контексте). Вернёмся к состоянию. Частенько бывают ситуации, когда без состояния вы не можете обойтись, и единственным решением на уровне С - использовать контекст состояния со всеми функциями, выполняющими работу в контексте этого состояния. Это приводит к тому, что вы либо заведёте структуры, которые будете передавать дополнительным параметром в некоторые фунеции, либо к тому, что вы реализуете ресурс-менеджер, и будете оперировать над хэндлами, которые и реализуют роль состояния. Вы, как опытный СИ программист, наверняка знаете, что реализация этого на СИ, гораздо трудозатратней чем аналогичный подход в терминах классов С++. Что же касается list, как было вами упомянуто ранее, существуют способы разделения функциональности по проходу контейнеров от того, что должно делаться на каждой итерации(Iterator pattern). Вы заикнулись об эффективности, позволю себе напомнить вам один из практикующих принципов, который упоминается буквально везде: First make it working, next make it fast if it is still neccessary. Хоть вы и хорошо давно практиковали программирование на СИ, вы много раз сталкивались с ситуациями, когда вам необходимо было сохранять состояние для передачи куда либо, так что вы использовали ООП так или иначе и сами об этом не задумывались. Разве вам приходится манипулировать с устройствами хранения данных разного рода(SCSI, IDE, SATA, USB Flash, ZIP, CDROM, DVDROM) посредством непосредственного общения к Low-Level интерфейсу этих устройств? Наоборот - вы используете драйверы и подсистему ОС, которая предоставляет вам унифицированный интерфейс для работы над файлами. И после всего этого вы говорите что ООП провалилась? ООП это не ключевое слово class и даже не virtual. Это парадигма реализации всего того, что мы на сегодняшний день имеем. А имеем мы достаточно много. И простите, СИ реальзация очень многих частей linux очень убога, по сравнению с существующими коммерческими аналогами, в сравнении по параметрам usability.
Бесспорно, следует стремиться по-возможности реализовывать функциональность алгебраического вида, т.е. фунециональная связность(Совершенный код, С.Макконел) т.к. это самый лучший и самый простой вид связности по использованию и пониманию. Но вы не можете обойтись без состояния? Тогда вы не можете реализовать функциональный вид связности в терминах СИ, а решение этой проблемы на С++ будет гораздо локаничней и проще в поддержке чем на СИ. Что же касается наследования, простите, но вам скорее всего попадались дурные примеры наследования. Видимо вы и сами не особо хорошо этим владеете. Существует общая ООП/ООА рекоммендация - не делать класс наследником другого, если он не является по смыслу базовым или не работает в терминах интерфейса базового. Теперь мы пришли к идее программирования по контракту(в терминах интерфейсов). Бесспорно существует много кода, написаного на СИ, который реализует этот подход. Но при детальном рассмотрении, он по фунециональному наполнению очень мало отличается от аналогичного по выполняемым действиям С++ кода. Так что не будьте наивны и будьте консервативны, уже есть устоявшаяся и не потерпевшая поражения парадигма за более чем 30 лет - не ищите правоты и консерваторов процедурного стиля программирования. Пока что крах ООП не потерпел и врядли потерпит, по крайней мере, задачи, которые стремятся решить с помощью ООП, решаются весьма удачно, а именно - управление сложностью.
Вообще говоря, для познания ООП/ООА нужно крайне много времени. Есть много источников, с которыми следует ознакомиться. Так что уважаемый, вы бы не растлевали бы молодёжь своими едва ли верными высказываниями, без хоть мало-мальски серьёзного довода в пользу ваших слов. Вы только написали много текста и не более, а кто-то в это поверит и подумает что вы крут. Как вы сказали называется ваш опен-сорс проект? Никогда о нём не слышал, видимо всё таки ваша точка зрения не верна. Вот после такого рода заявлений действительно задумаешься о цензуре в интернете. Ладно ещё над Ксюшей Собчак посмеются, но когда искажают факты, это уж извольте... ООП языки лишь инструмент для ООП и ООА. Если вы его не поняли, то это ваша личная беда и не надо орать на весь рунет о том, что ООП это ересь. Кто-то потом это ляпнет совершенно уверенно на собеседовании и это собеседование может очень быстро закончиться.
Добрый день!
Мне очень по душе фраза: "Я не стреляю в Си++, потому что на нем можно писать хорошо, но это могут делать те программисты, которые пришли из мира Си".
По моему вопрос не в том хорошо ли ООП или нет - а в образовании - при достаточно глубоком познании как функционального программирования так и ООП (включая паттерны и их правильное использование), можно писать корректный и оптимальный код (сбалансированный) а иначе сами знаете что получается.
Мне кажется путаница появилась с возникновением сред IDE с технологией Rapid Application Development (RAD) типа Delphi, и тогда многие неучи возомнили себя крутыми программистами со знанием ООП и вообще :-)
Может я и не прав, но к этому я пришел из опыта и общения...
К сожалению, не знаю, просматриваете вы комментарии или нет. Отпишу. Вы правы. ООП порождает очень не эффективные программы. Вопрос только в том, как это доказать с точки зрения не терминов программирования, а с точки зрения математической теории.
Если заметили, то в мире чаще всего используются реляционные БД, а в офисах Excel. Где пресловутые объектно-ориентированные БД? Проблема в оптимизации?! Какая алгебра(булева для реляционных БД) положена в основу ООБД или ООП?
По моему было бы интересно проанализировать способ распределения памяти в программах ООП и традиционного подхода.
Очень интересен подход с unit тестами.
Если вы читаете свой блог, отпишитесь на мой ящик.
Вы изменили свое мнение?
Кажется Дональд Кнут сказал:
- Дайте мне данные и я напишу программу, но если вы дадите мне код без данных то я никогда не смогу написать программу.
Разве "черный ящик" в ООП это не тоже самое?
Напишите лучше на chumachin_m@mail.ru
Great blog, how about links exchanging? Please contact me asap, Thanks.
<< В начало