На самом примитивном уровне, синглтон не может иметь два разных смысла. Другое дело, что реализации могут сильно отличаться.

плюсую

Фримен, Сьерра: Паттерны проектирования

Ну абстрактной фабрикой я точно пользовался, когда лепил всякие классы по обработке сигналов, правда, это было до прочтения мной книжки, и прочтя её несколько лет спустя, я несколько повеселился.

Но честно говоря, мой комментарий был не про нужность/ненужность именно паттернов, а про конкретную попытку опустить ТСа в стиле «сиди и не выделывайся». Далеко не все программисты пишут «компоненты на ангуляре/вуе с парой полей для ввода и кнопкой», есть и поинтереснее задачки. И теорию читать полезно.

Так вот в том-то и дело - нужно уметь быстро не только 1-2 статьи усвоить, а 1-2 книги.

Сегодня книги от корки до корки не читают. Есть проблема - прочитал соотв. главу. Можешь еще одну главу прочитать, которая дает более широкий обзор. Но всё должно быть привязано к практике. Ну разве что ты пишешь диссертацию на тему...

Да и вообще посты и выступления Егора заслуживают внимания.

Только он немножко сильно упорот, и кругозор у него узковат. Когда его что-то спросили про ФП на одном из выступлений, он такую ахинею понёс…

Главные критерии для упорядочивания: «фундаментальность» касательно ООП

“A Theory of Objects” — Martín Abadi, Luca Cardelli

Что тут делает тег «ocaml»?

Тоже что и теги «c++» и «java».

Тот же вопрос, что делает функциональщина когда вопрос по ооп

OCaml (formerly Objective Caml) extends Caml with object-oriented features. Paradigm: Multi-paradigm: functional, imperative, object-oriented (wiki).

В 1.4. изложение с его использованием.

Это извращение. Ну, т.е. я знал про это, но адеватные люди на окамле функциональщину пишут.

Это извращение

С чего вдруг? В Ocaml очень хорошая (для статически-типизированного языка) объектная система. Не переусложнённая, элегантная и достаточно гибкая.

адеватные люди на окамле функциональщину пишут.

Адекватные люди используют те возможности языка, которые удобней для решения задачи.

Не согласен. Читают. Разумеется, если ты будешь мусолить одну книгу полгода, то никакого времени не хватит.

В топку книг добавил бы ещё «Объектно-ориентированное конструирование программных систем» Мейера.

Книги по паттернам новых знаний, кроме названий паттернов, могут не дать. Просто для того, чтобы взглянуть на паттерны под другим углом, после GOF посоветовал бы полистать POSA.

Вот интересное предложение. Почитал как-то месяц назад по диагонали. Есть ощущение, что автор и адепты открыли чакру ООП и кайфуют. Но если отбросить апломб - всё то же процедурное программирование, а ООП используется как «святая вода» - авось поможет. И, внезапно, иногда действительно помогает (от жажды).

На мой взгляд автор вполне здраво мыслит в основном, но иногда его заносит в радикальный ООПизм, что не всегда хорошо. Но в целом он-то прав — то что большинство понимает под ООП это просто какой-то «си с классами». Люди смешивают парадигмы, причём с уклоном в процедурщину. Это не всегда плохо, но фактически это не ООП.

Head First
Шикарная книга

Говно. Все книги этой серии.

Говно. Все книги этой серии.

Твой рот — говно.

Не гони.

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

В частности, я не понимаю как само ООП (не Алана Кея, а вот то, что пацики в кубиклах фигачат) помогает управлять сложностью, декомпозировать, поддерживать (эксплуатация ПО), фиксировать ясные и простые контракты. Просто всё, что я вижу - это можно сделать с любой парадигмой при наличии вменяемого программиста («делай нормально - будет нормально»).

Если почитать эти статьи, то можно составить представление о то как правильно готовить ООП:

https://www.yegor256.com/2014/09/10/anti-patterns-in-oop.html

https://www.yegor256.com/2016/02/03/design-patterns-and-anti-patterns.html

https://www.yegor256.com/2014/12/01/orm-offensive-anti-pattern.html

https://www.yegor256.com/2014/06/09/objects-should-be-immutable.html

По-крайней мере здесь я с большой частью согласен.

Не гони.

А что я гоню? В этой серии книг полезной информации - две с половиной строки на страницу. Зато много смишнявых картиночек.

А сколько страниц по паттернам тебе нужно?

А сколько страниц по паттернам тебе нужно?

Да дело не в количестве страниц, а в том, что книга должна содержать информацию по теме, а не быть комиксом «по мотивам».

По паттернам отличная книга у них. А то что много рисунков и текст разным шрифтом - это такая форма подачи материала.

Почитайте это:

http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

http://harmful.cat-v.org/software/c /

http://harmful.cat-v.org/software/java

http://harmful.cat-v.org/software/node.js

почитай Барбару Лисков(CLU) и Тьюринга премия(ACM) ея.

книга не субъект и быть должной что-либо кому-либо не может - как и вообще что-либо мочь.

дык детям любых возрастов комиксы пользительны к ознакомлению - хоть через комикся детяти приобщатся (с искажениями и водой но лучше так чем никак) к технологиям нужным к распространению чем понуждать немогущих к ... утруждатся текстами которые настолько повергают детей(старшего зрелого возраста) в «плохое настроение» - О.Хаксли с о дивным и островом и после острова знал ужо.

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

1. Два понятия ООП: автономные объекты, сообщения, позднее связывание - из Smalltalk; и наследование, инкапсуляция, полиморфизм - из Модулы 2

2. ООП среди других парадигм. Реляционная парадигма. Полезность SQL сервера состоит в том, что он автоматизирует решение задач (компьютер делает работу за человека). Это свойство не парадигмы, но инструмента. Функциональная парадигма. Полезность чистого ФП - упрощается анализ программ за счёт отсутствия побочных эффектов. Подумать, чем полезна ООП? Что в этом случае компьютер делает за человека? Мой ответ - по сути, ничего не делает, а только лишь заставляет человека следовать определённым соглашениям. Может иметь смысл, для разделения работы - поставщик предоставляет класс, а пользователь его наследует. Однако этот подход устаревает.

3. ООП ортогонально статической типизации (Smalltalk, Python, Common Lisp). Работа с объектами в статической и динамической типизации. Преимущества статической типизации - меньшая неоднозначность текста программы (и ещё другие нагуглить), повышенная эффективность. Преимущества динамической - повышение выразительности и сокращение объёма исходника. Осознать, что виртуальный метод - это частный случай динамической типизации и что он страдает от всех её недостатков.

4. Шаблон проектирования Visitor - не закон природы, а лишь следствие из того, как реализовано ООП конкретно в C++ и Java. Понятие о множественной диспетчеризации.

5. ООП в стиле С++ не так уж сложно реализовать. Реализовать эрзац-ООП на Си с помощью макросов. Должны быть записи с тегом типа, таблицы виртуальных методов. Будет многословно, но по смыслу должно получиться то же, что в С++. Продвинутое упражнение - реализовать ООП со множественной диспетчеризацией, как в CLOS.

6. Отличие наследования от композиции. Рекомендуют применять композицию вместо наследования. Проблема хрупкого базового класса. Но у наследования есть преимущества, которые нельзя игнорировать. В наследовании - общее время жизни, одновременная инициализация, один кусок памяти. Пространство имён методов может не совпадать (при множественном наследовании в С++ можно указывать конкретного предка при вызове метода). Внедрение зависимостей ведь вроде тоже сюда относится?

7. Принцип Лисковой. Перекрытие потомком реализованного предком виртуального метода нарушает его. Добавление поля к классу нарушает его. А нарушение принципа Лисковой затрудняет анализ программы. Отсюда возникают интерфейсы как основной случай ООП. В современных языках (Rust, Golang) вовсе отказались от наследования или сделали его малозаметным (включение). Проблемы многословности в Rust, связанные с этим выбором.

8. Варианты использования ООП без инкапсуляции (CL, а также Scala c public по умолчанию). Противоречие между инкапсуляцией и рефлексией (в Golang только public поля записи можно сериализовать в Json). RTTI. Взлом инкапсуляции через определение идентичного класса и опасное приведение типа.

9. Snit как пример ООП без объектов. Автоматическое делегирование методов средствами метапрограммирования. Средства объектного моделирования (Rational Rose, ныне что-то про неё позабыли, а я успешно прошёл мимо). Осознание, что делать частное поле и потом к нему две функции - это наказание, и плох тот язык, который его не автоматизирует для частных случаев.

10. Насколько я знаю, современные руководства по проектированию говорят о нежелательности глубоких иерархий. В реальности многие крупные проекты содержат глубокие иерархии. В теории, теория и практика согласуются, но на практике они зачастую сильно отличаются.

11. Наследование реализации и таблицы виртуальных методов как способ оптимизации программ. Но ООП находится на более высоком уровне абстракции. Таким образом, в С++ наследование представляет из себя смешение уровней абстракции, это не хорошо и не плохо, но нужно это понимать.

12. Множественное наследование. Я не эксперт по ООП, но вроде как в С++ оно реализовано наиболее общим способом, мне нравится. Ограниченные способы множественного наследования - примеси. Разобраться в терминологии, что называется mixin и trait в разных языках - терминология противоречивая. Составить табличку, в неё должны входить, как минимум PHP, Scala и Haskell (тайпклассы - это интерфейсы). Знать, что в Java ввели множественное наследование спустя ~20 лет, а до этого говорили, что оно не нужно.

13. Проблема алмаза (diamond inheritance, наследование по нескольким путям). Изучить историю борьбы с ним в Scala. Его закапывают, а оно выползает в новом месте. Вероятно, что-то не так с самой идеей.

14. Сортировка методов при множественном наследовании (забыл термин). Применяется в Scala. Вообще говоря, лишняя сущность, произвольное соглашение, созданное только, чтобы искусственным путём разрешить неоднозначность. И тут должно снова закрасться подозрение, что в ООП изначально не всё было гладко.

15. Осознание, что шаблоны классов, дженерики и прочее - это механизм, отдельный от ООП. Сделать вывод о том, что ООП - не такой уж общий механизм.

16. Проблема неродственности TemplateClass<T> для разных T. Ковариантность и контравариантность. По-моему, в С# сделано наиболее толково.

Этот текст будет находиться здесь: http://вики-ч115.программирование-по-русски.рф/Ч115/ООП - я уже внёс правки, на ЛОРЕ истёк срок редактирования.

практичность

https://www.poodr.com/ рекомендуют

теория объектов, ценности, принципы и механизмы, объектные и компонентные модели и метамодели

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

ООП это не только и не столько «наследование, инкапсуляция, полиморфизм». наоборот, эти три кита ООП — принципы не ООП, а принципы реализации объектной модели в С++ и ранее в Simula-67, Beta. далее происходит метонимия, подмена «абстрактная фигня, реализующая принцип» на «конкретная фигня ну всем известное portmaneu этого принципа». а это несколько не так.

есть ценности, нечто важное, что мы хотим выделить как особенное. сохранить и приумножить. есть принципы, которые суть механизм этого использования, сохранения и приумножения. и есть реализации принципов, конкретные факты, методы, паттерны и прочее.

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

из обзорных, например эпичненькая «Handbook of object technology», Saba Zamir.

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

изначально объекты развивались по 2 веткам — акторы и «активные объекты» (SmallTalk-72, self, Active Oberon в AOS) и пассивные структуры данных. почему-то более попсовой стала вторая ветка.

АДТ в изначальных работах Хоара, Даль У., Дейкстра Э., Хоор К. «Структурное программирование». Серия: Математическое обеспечение ЭВМ. – Пер. с англ. – М.: Мир, 1975 — это фактически классы и объекты.

далее в плане системы типов классного ООП. следует почитать Луку Карделли «теория типов» про формализацию семантики, и Б. Мейера «Объектно-ориентированное конструирование» — про системную корректность, классовую корректность, ковариантность, контрвариантность. идея была построить корректную в рантайме систему типов, соответсвующих классам. такие вот базовые принципы.

далее Мейер берёт псеводкод и из математизации свойств такого исчисления ради обеспечения ценностей повторной используемости выводит язык Eiffel. Карделли проделывает тоже самое сравнительно с функциональным программированием и его семантикой, корректности типов. другие авторы, например Laurent Deniau ниже — применительно к Си. Ингалс-практик и Кей-теоретик-визионер — исходя из модели биологической клетки и рефлексов Анохина, software circuits (далее эту идею подхватывает Бред Кокс в Objective C).

получается формальное «исчисление объектов» и конкретные варианты реализации этой модели, в различных вариантах. одни экспериментируют со смоллтоком — FLAVOR, LOOPS, COMMON LOOPS, Objective C, NeXT, SOM, ooRexx и т.п. здесь есть J.Hamilton «Programming with DirectToSOM C++» про реализацию SOM компонентной модели с метаклассами в компиляторе VisualAge, и транслятор типа Cfront из С++ в Си, только сразу в SOM (который на plain C+asm). описана идея про транзитивное замыкание, first class objects и корректность системы типов (метакласс, класс, объект, экземпляр). фактически всё реализовано в рантайме, экземпляр, класс, метакласс — реализованы одинаково. выделены 10 принципов для обеспечения Release-to-Release Binary Compatibility, (там же и в Release-to-Release Binary Compatibility and the Correctness of Separate Compilation; Reflections on Metaclass programming in SOM by Ira R. Forman, et al): какой должен быть в общем виде ООП ABI , чтобы не сломалось при трансформациях и рефакторинге. и какого вида трансформациях (например, переместили метод по иерархии наследования, добавили новый, и т.п. )

в каком-то смысле это тоже напоминает теорию: выделили аксиомы, теоремы, составили транзитивное замыкание, изменения, метод реализации объектной модели, который не ломает системную и классовую корректность при определённых изменениях, задачи, которые должна обеспечивать объектная модель.

это компактное конструирование объектной модели (метамодели), с заданными свойствами из общих принципов системной корректности и классовой корректности системы типов-классов(+объектов,+метаклассов)

классическое попсовое «инкапсуляция, наследование, полиморфизм» — это тоже конструирование какой-то объектной модели «ООП как в Simula», исходя неявно из ХЗ каких именно принципов и свойств-ценностей. ad hoc, так получилось. сюда же вложенные классы и пространтства имён в Beta,newspeak; анонимные вложенные классы в Java.

у Вирта, кстати, про Modula-2 и далее в оберонах немного не эти ж самые принципы и немного другая объектная модель. не «инкапсуляция, наследование, полиморфизм», а «сокрытие данных, расширяемые записи, stepwise refinement». можно сказать что это просто другие слова лет за 5-10 до попсовой объектной модели в Си с классами Страустрапа, а можно сказать что он подразумевал другое — полиморфизм модулей в модуле/оберонах, пакетов в аде, систем и пакетов как в лиспе, сигнатур модуля в ML и окамле. в окамле, кстати, разделены типы модуля, сигнатура, и морфизмы типов, функторы. и на этом строится объектно-компонентная модель — см. пруфлинк в Mirage unikernel и функторы времени компиляции для сборки драйвера из DSL описания протокола.

Laurent Deniau в OOPC и далее в COS (там же или COS на гитхабе) в соотвествующих PDF это формулирует явно: можно ли построить объектную модель исходя не из попсовых 3 и не из неявных «мультиметоды и родовые функции, метаклассы, множественная диспетчеризация, CLOS, MOP, рефлексия, интроспекция, интерцессия поверх MOP» в CL либо «классы, метаклассы, посылка сообщений, маршрутизация сообщений» в SmallTalk либо «наследование объектов (клонирование), а не классов» в Io, JavaScript прототипное ООП, более другие принципы, далее «ортогонализировать»?

можно, говорит он в cos-draft-dls09.pdf, cos-draft-oopsla09.pdf: взять 2 принципа message multi-dispatch и message multi-forwarding, и получить некое ООП шире чем попсовое. которе ближе к aspect-oriented, service-oriented.

он опять таки говорит про ценности и принципы, уже потом про механизмы реализации этих принципов в объектной модели: принципы простоты (привет, MOP), расширяемости (привет, C++ Fragile Base Class problem), повторной используемости, эффективности и переносимости.

и уже потом на этом всё строит.

в COS он пытается строить ООП как в CLOS, и возможный метаобъектный протокол поверх на plain C, и проще. в OOPC — берёт попсовый «инкапсуляция, наследование, полиморфизм» и строит его опять таки на plain C.

можно читать и проникнуться: pdfы, исходники с реализацией такой объектной модели, примеры.

далее можно разбираться с ooc и vala.

язык ooc, и примеры в обучалке. а также погуглить на гитхабе проекты на этом языке, взять какую-нибудь игрушку на SDL, OpenGL и посмотреть внимательно на исходники.

это не тот OOC99 что в OOPC выше, простая С объектная модель.

это ООП си с шаблонами и почти гомоиконностью. легкочитаемый как Go.транслируется в ANSI C99, есть множество батареек, пакетный менеджер и прочее.

сам компилятор написан на себе самом, на PEG парсерах rock, есть мануал

довольно много всего интересного на нём понаписано, см. проекты на гитхабе на ooc

далее, можно взять Vala и объектную модель GObject, Glib из GTK. здесь у OCTAGRAM'а , который пилит открытую кроссплатформную реализацию SOM под названием somFree есть текст про сравнение объектных и компонентно-объектных моделей, в том числе и GObject. у него ещё какие-то планы странные были, про world domination. на Objective C и своей компонентной модели. врочем, если взять какой-нибудь GNUStep, Cocotron и Blackbone, и что-то допилить по вкусу, то может быть и взлетит. но это сколько ж допиливать надо???

GObject пытается в рантайме объединить и попсовый ООП С++, и нечто в духе CLOS и SmallTalk. в той табличке пытается стать наименьшим общим кратным, наибольшим общем знаменателем объектных моделей.

если запилить Helloworld на Vala и оттранслировать его как vala --ccode в няшную сишечку, то всё будет довольно понятно и наглядно, пока не встретятся runtime костыли для приведения типов, assёрты для этого самого — проверок типов с наследованием и приведения типа, для обеспечения классовой и системной корректности.

в районе newspeak и gradual typing была какая-то работа. даже диссер вроде бы. про реализацию предикатов isA с учётом наследования предок, потомок через dispatch trees, и прочее. в языке Nim (бывший Nimrod), который тоже транслируется в си, кстати, тоже чего-то там написано про таблицы диспетчеризации, тайптеги, и формирование таких таблиц во время компиляции.

собственно, J. Hamilton про DirectToSOM в VisualAge C++ — это и пример того, как это могло бы выглядеть в самом простом виде, чтобы компилятор кодогенерировал такие обвёртки в какой-то IDL. OCTAGRAM вроде бы допилил этот генератор обёрток в нечто более функциональное.

ещё где-то было сравнение быстродействия SOM и C++. нечто вроде теста который Kron73 про фибоначи и акермана объектами делал, про накладные расходы на вызов метода, в той или иной компонентной объектной системе.

я так думаю, что когда сделали SOM, DirectToSOM C++ и обычный С++, такие тесты запустили, посчитали-прослезились. хотя SOM сам по себе имхо полезен как метамодель, которую можно бесконечно расширять метаклассами.

вот решить что из этого должно быть в системной модели (которая на SOM с метаклассами), а что — в native C++ --- это и есть сложная инженерная оптимизация, компонентный анализ.

как бы то ни было, сейчас SOM таки сдохла. остались отголоски в Open Object Rexx — модель смоллтолка с метаклассами и частично из SOM там присутствует. попробовать потыкать её из ooRexx как бы не проще чем сам смоллток, и реализацию метаклассов там.

в newspeak пытаются делать модульный смоллток, функционально пречистый, с отдельными пространствами имён (даже говорят про active worlds, фабрики объектов/сервисов/компонентов, DSL поверх и какой-то gradual typing).

обычное ООП греховное: кишки реализации объектной модели, особенно в самом ея пошлом, попсовом смысле (инкапсуляция, наследование, полиморфизм) и хрупкости базового класса везде торчат наружу. получается очередная CORBA и SOM.

функциональщина же наоборот, пречистая. непонятно, как её сочетать с реальным миром, побочными эффектами, глобальными состояниями или локальными контекстами (объектами).

и тут бац, монады. как формализация и локализация побочных эффектов.

//капча с велосипедами, лол. строго говоря, все эти рассуждения про системную и классовую корректность системы типов, этот TAPL Б. Пирса и «теория объектов» Луки Карделли, и прочее объектно-ориентированное, но уже непопсовое, а компонентное системно-корректное конструирование --- это как раз про это. монады и монады-трансформеры как альтернативное ООП исчисление, тайпклассы про это же, коэффекты и комонады опять же

в общем, почему ООП провалилось?

нет, оно просто так пахнет.

сейчас каждый может изобразить себе любую ООП объектную модель, «исчисление объектов», теорию объектов на выбор. взять какую-нибудь скалку и жабу, и получить функционально-JVM-объектное. или f# и функционально-дотнетово-объектное. или Ocaml и функционально-объектное через функторы модуля, сигнатуру модуля, типы модуля (см. unikernel MirageOS и реализацию драйверов из DSL во время компиляции, как пример такой композиции, функционально-объектной системы гибкой, настраиваемой)

или попытаться раскрутить метамодель механизмов реализации объектной модели и метамодели, через монады и коэффекты.

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

освободиться от попсовой копро-объектной копро-модели довольно просто. нужно сконструировать свою простую, прозрачную, с ясными ценностями, принципами, и механизмами реализации.

без всех этих недостатков попсового ООП в стиле С++. все отдельные запчасти для этого уже есть, см. ссылки выше.

Посоветуйте лучший, по вашему мнению, учебный материал по паттернам проектирования

Непейвода Н.Н., Скопин И.Н. «Основания программирования»

книга вещь, она не про попсовое и наносное, паттерны-хреняторны, оопе-канапе.

она про основы: различные парадигмы, системы программирования, инструментарий. собственно, то что Непейвода называет «системой программирования» есть некоторая компактная система знаний, понимая и зная которую, умея её применять --- можно самораскрутиться поверх на любом языке программирования, в любой парадигме.

это вот к компонентным системам и паттернам таких компонентов-объектов тоже относится

ещё вот про паттерны, дай бог памяти. где-то была презентация программера из Касперского про «реализацию классических паттернов банды четырёх на Хаскеле».

один паттерн — две строки, редко три. сокращение бойлерплейта и быдлокода в разы, на порядки.

потому что объекты по сути монады и коэффекты. а паттерны проектирования это монады-трансформеры.

Философия Java
ЯП C++ // Б.Страуструп

Вообще не про ООП

ООП с ANSI-C

Что это?

Типы в ЯП // Б.Пирс

ООП это не типы

В общем, УГ подборка у тебя. А книг тебе накидали, плюсану Буча с его ООП на крестах, там даже картинки есть, можно только их посмотреть и всё понять.

А потом лет 10 написания ООП кода и возможно к тебе придёт понимание ООП.

Паттерны можешь почитать, для общего развития, но в целом они давно спрятаны в фреймворках и большая часть из них заменена IoC.

P.S. Поехавших выше анонимусов не слушай, лучше даже не читай, чтобы не заразиться.

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