LINUX.ORG.RU

Я до конца познал ООП только начав программировать на связке С++/Qt.
Чтение же книжек вряд ли поможет. Тут важен опыт построения схем классов и все такое. Я уже не говорю про полиморфизм. Пока он тебе в практике не понадобится - ты его до конца так и не оценишь.

anonymous
()

Гради Буч. «Объектно-ориентированный анализ и проектирование с примерами приложений на С++».

Желательно яву ещё посмотри, и другие языки, упомянутые в книге. Хотя бы для общего развитея, чтобы не присыхать к C++. Вообще не увлекайся рекламой, инженерное дело требует прагматизма и, зачастую, поиска компромиссов. Больше будешь знать — больше будет выбор инструментов.

nuffsaid
()
Ответ на: комментарий от nuffsaid

>Гради Буч. «Объектно-ориентированный анализ и проектирование с примерами приложений на С++».

Да, да. Прочитай Буча. Вынеси себе мозг.

Еще можно почитать GoF, и хотя там мало что про ООП/ООД — это очень полезная книга. Можно почитать Александреску, он там насилует C++ во все дырки. Можно почитать Коплиена «Мультипарадигменное проектирование на C++».

А еще лучше, обратить свой взор на Scheme, CommonLisp, ML и Haskell. Чтобы потом не было до слез обидно. Кстати в CL есть своя ООП система, достаточно серьезно отличающася от мейнстрим. ООП система есть в Ocaml'е (ML). Есть язык F# (ML для .NET со штатной нетовской ООП системой). Есть Scala, где к достаточно мейнстим ООП, который хорошо интегрируется с явскими библиотеками, прикручено некоторое количество матана. Есть Clojure (Lisp, но не который Common), слава Богу без ООП, но очень хорошо интегрируется с явой, на нем отлично пишутся DSL-обертки для явских ООП библиотек.

А вообще, нужно понять самое главное в ООП. В мейнтсрим ООП класс — это тройственная сущность: класс как тип, класс как интерфейс и класс как поведение. Из этой каши следует множество как сильных, так и слабых сторон ООП.

Второе, что нужно понять, это то что между ООП и ФП нет никакой пропасти, и противопоставлять эти парадигмы друг другу не следует.

Macil ★★★★★
()

Мне очень понравилась «Приёмы ООП.Паттерны проектирования». Хоть и паттерны, но ООП отлично объясняется с примерами применения, недостатков того или иного паттерна. способов применения. 2 раза прочитал.
Примеры на C и Smalltalk. Надо - закину куда или ссылку дам

impr
()
Ответ на: комментарий от anonymous

> до конца познал ООП

С++


Что-то здесь не так. Или это мне только кажется?

dmsh
()
Ответ на: комментарий от Boy_from_Jungle

Приемы ООП. Паттерны проектирования

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

http://dl.dropbox.com/u/10274956/Приёмы ООП.Паттерны проектирования.pdf

Ссылка такая, так как lorcode странно работал.

impr
()
Ответ на: комментарий от Boy_from_Jungle

> юзай [url]
Сообщение наверное мне адресовалось...
Использовал [url] - ссылка становилась зачёркнутой. Можешь в удалённых глянуть.

impr
()
Ответ на: комментарий от Macil

Можно почитать Коплиена «Мультипарадигменное проектирование на C++»

в обязательном порядке; после чего не вредным будет почитать про FAST и вообще DDD

jtootf ★★★★★
()

Лучшая книга по ООП - Blue Book, остальное все от лукавого: http://www.infanata.com/computers/prog/1146122665-smalltalk-yazyk-i-ego-reali...

Если увлекся ООП - бросай С++, реализация объектно-оринтированного подхода в нем очень слабая. ООП в С++ носит скорее вспомогательный характер, поэтому советую для обучания этой парадигмы использовать Smalltalk (идеальная реализация ООП-подхода), Ruby (идейный наследник смолтолка) ну или на худой конец ObjectC.

Не гоняйся за С++ и его универсальностью, которая скорее миф. Язык может многое, но на большинстве языков можно сделать проще и быстрее благодаря качественной реализации центральной парадигмы. Когда берешься за С++ главное ответить на вопрос «для решения какой специфической задачи требуются свистелки-перделки слабой реализации С++». На практике 99,9% задач решаемых на С++ достаточно просто решается на классическом Си.

Единственная идеальная реализация ООП - smalltalk и только он. Близко к нему подошел Ruby. Остальные - имеют более примитивную реализацию, по сравнению с первым. С++ имеет одну из самых слабых реализаций ООП (разве что пистон может тягаться по примитивизму ООП)

Meerkat
()

П. Франка - C++: учебный курс

anonymous
()
Ответ на: комментарий от peacelove

> 1 строка про книгу, 10 строк про то какой С++ говно. НиасилилС++ головного мозга?

Не трогай ценный экспонат, это ООП-фанатик. Языки оценивает по степени их близости к Smalltalk. Скажи ему, что мир может не укладываться в объектную модель — станет фиолетовым в крапинку.

BTW, фраза «99,9% задач решаемых на С++ достаточно просто решается на классическом Си» говорит нам, что перед нами товарищ, не видевший в глаза ни одного крупного C++ проекта. Телекоммуникации, бортовые системы, распределённые вычисления(в том числе с изрядным кол-м математики), распознавание образов и прочая и прочая. О да, мы сейчас это все на простеньком си перепишем и смоллтолком заполируем.

nuffsaid
()
Ответ на: комментарий от Meerkat

>> Единственная идеальная реализация ООП - smalltalk и только он. Близко к нему подошел Ruby. Остальные - имеют более примитивную реализацию, по сравнению с первым

Уж примитивней чем в ST еще поискать надо. ООП а-ля ST на Лиспе реализуется эдак в 40-50 строк.

cathode
()

>> Желательно в связке с С++

Страуструпа уже освоил?

cathode
()
Ответ на: комментарий от Meerkat

>Единственная идеальная реализация ООП - smalltalk и только он
Херня.

Близко к нему подошел Ruby.

Еще большая херня.

Остальные - имеют более примитивную реализацию, по сравнению с первым.

Феерическая херня.

Почему? Потому что CL+CLOS+MOP.
http://en.wikipedia.org/wiki/Common_Lisp
http://en.wikipedia.org/wiki/CLOS
http://lisp.org/mop/index.html

Но C++ - таки да, говнище, в котором ООП кривое и неюзабельное, тут согласен.

Love5an
()

C++ - выкинь, это какашка. Особенно в плане ООП, выше правильно сказали.

Love5an
()
Ответ на: комментарий от nuffsaid

>О да, мы сейчас это все на простеньком си перепишем и смоллтолком заполируем.
Ну это уж лучший вариант, чем C++, по крайней мере.
Все крупные проекты на C++(ну, большинство) представляют собой кучу глючного и кривого говна, подпертую со всех сторон не меньшей кучей костылей.

Love5an
()

Может книг по ООП посоветуете, а не по С++ и без обсуждения лисп и прочих смолтолков?

impr
()
Ответ на: комментарий от anonymous

> Я до конца познал ООП

Это ты, Гаутама? А что ты тут делаешь?

anonymous
()
Ответ на: комментарий от peacelove

> 10 строк про то какой С++ говно. НиасилилС++ головного мозга?

Про то, что C++ говно обычно пишут именно те, кто его осилил намного лучше чем те, кому C++ пока еще нравится.

anonymous
()

>Хочется прочитать про правильное проектирование прог в стиле ООП ... Желательно в связке с С++

Страустуба читал? У него последние главы три как раз рассказывают про проектирование. Весьма торкающее чтиво.

И поменьше слушай здешних «экспертов» со smalltalk и прочими идеалами. Это всё чистая теория, которая на практике нашла ничтожное применение по сравнению с С++. С++ далеко не лишён недостатков и мне самому многим не нравится, но это быстрый ООП, это язык проверенный временем на очень широком спектре задач, обладающий огромным багажом готовых библиотек. Так что если не хочешь витать в облаках и наивно мнить себя крутым идеалистом - бери С++.

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

anonymous
()
Ответ на: комментарий от anonymous

>Про то, что C++ говно обычно пишут именно те, кто его осилил намного лучше чем те, кому C++ пока еще нравится.

На протяжении дох^W многих лет наблюдаю лишь обратное.
На С++ говно льётся из организмов:
1. Школота-идиоты которые выучили синтаксис C#/Java
2. Сишных олдфагов.
3. Крайне неадекватные «типа богема», т.е. вот смолтокоёбы, лямбданутые и прочая шушара, которая проектов выше «автоматизация хуйни» никогда не поднимала.

Все адекватные используют нужный инструмент в нужном месте.

peacelove
()
Ответ на: комментарий от peacelove

Все адекватные используют нужный инструмент в нужном месте.

Очень верно. А неадекватные везде используют сипласплас.

dmsh
()

Только было хотел поинтересоваться, почему до сих пор никто не порекомендовал топикстартеру SICP? И вообще, где все сектанты с их мантрами об ООП как о маркетоидной выдумке, о распространенности C++/Java лишь как о результате быдловости масс, о провале Лиспа вследствие того же и т.п.?

Присмотрелся - а все уже здесь, как миленькие. Лучиков любви вам.

Kuka ★★
()
Ответ на: комментарий от Kuka

почему до сих пор никто не порекомендовал топикстартеру SICP?

Между прочим, там объясняется как ооп устроено изнутри, чего я не припомню ни в одной книжке с цветастой надписью «ООП» на обложке.

dmsh
()
Ответ на: комментарий от dmsh

> Между прочим, там объясняется как ооп устроено изнутри

Это, наверное, в обновленном SICP, который питоний? Он не Ъ.

Я имел в виду Ъ - классический SICP, про Scheme. В Scheme никаким ООП не пахнет даже отдаленно, схемовцы пытаются блюсти чистоту парадигмы, в отличие от лиспарей, наблоативших всевозможные CLOS и MOP.

Kuka ★★
()
Ответ на: комментарий от Kuka

Я не знаю ни про какой «обновленный» вариант. Это все изложено в первых двух-трех главах.

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

dmsh
()
Ответ на: комментарий от Meerkat

Единственная идеальная реализация ООП - smalltalk и только он.

Eiffel упустил.

iZEN ★★★★★
()
Ответ на: комментарий от Meerkat

>Когда берешься за С++ главное ответить на вопрос «для решения какой специфической задачи требуются свистелки-перделки слабой реализации С++». На практике 99,9% задач решаемых на С++ достаточно просто решается на классическом Си.

Годный вброс. Приведи мне нормальный аналог связки C++/Qt4 для безпроблемного кроссплатформенного программирования.

Siado ★★★★★
() автор топика

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

iZEN ★★★★★
()
Ответ на: комментарий от dmsh

> Я не знаю ни про какой «обновленный» вариант.

Весьма характерно для «одептов» - не зная броду, лезть в воду. Специально для таких, как вы, краткий экскурс в историю.

Structure and Interpretation of Computer Programs - в первую очередь цикл лекций, читаемый в MIT с 1984-го года. Тогда же этот курс был оформлен и выпущен в виде книги. В качестве языка для демонстрации принципов программирования использовалась Scheme. С недавних пор Scheme заменили на Python, с материалами обновленного курса можно ознакомиться здесь.

> Ты хоть открой книжку чтоли

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

1 Building Abstractions with Procedures
  1.1 The Elements of Programming
     1.1.1 Expressions
     1.1.2 Naming and the Environment
     1.1.3 Evaluating Combinations
     1.1.4 Compound Procedures
     1.1.5 The Substitution Model for Procedure Application
     1.1.6 Conditional Expressions and Predicates
     1.1.7 Example: Square Roots by Newton's Method
     1.1.8 Procedures as Black-Box Abstractions
  1.2 Procedures and the Processes They Generate
     1.2.1 Linear Recursion and Iteration
     1.2.2 Tree Recursion
     1.2.3 Orders of Growth
     1.2.4 Exponentiation
     1.2.5 Greatest Common Divisors
     1.2.6 Example: Testing for Primality
  1.3 Formulating Abstractions with Higher-Order Procedures
     1.3.1 Procedures as Arguments
     1.3.2 Constructing Procedures Using Lambda
     1.3.3 Procedures as General Methods
     1.3.4 Procedures as Returned Values
2 Building Abstractions with Data
  2.1 Introduction to Data Abstraction
     2.1.1 Example: Arithmetic Operations for Rational Numbers
     2.1.2 Abstraction Barriers
     2.1.3 What Is Meant by Data?
     2.1.4 Extended Exercise: Interval Arithmetic
  2.2 Hierarchical Data and the Closure Property
     2.2.1 Representing Sequences
     2.2.2 Hierarchical Structures
     2.2.3 Sequences as Conventional Interfaces
     2.2.4 Example: A Picture Language
  2.3 Symbolic Data
     2.3.1 Quotation
     2.3.2 Example: Symbolic Differentiation
     2.3.3 Example: Representing Sets
     2.3.4 Example: Huffman Encoding Trees
  2.4 Multiple Representations for Abstract Data
     2.4.1 Representations for Complex Numbers
     2.4.2 Tagged data
     2.4.3 Data-Directed Programming and Additivity
  2.5 Systems with Generic Operations
     2.5.1 Generic Arithmetic Operations
     2.5.2 Combining Data of Different Types
     2.5.3 Example: Symbolic Algebra
3 Modularity, Objects, and State
  3.1 Assignment and Local State
     3.1.1 Local State Variables
     3.1.2 The Benefits of Introducing Assignment
     3.1.3 The Costs of Introducing Assignment
  3.2 The Environment Model of Evaluation
     3.2.1 The Rules for Evaluation
     3.2.2 Applying Simple Procedures
     3.2.3 Frames as the Repository of Local State
     3.2.4 Internal Definitions
  3.3 Modeling with Mutable Data
     3.3.1 Mutable List Structure
     3.3.2 Representing Queues
     3.3.3 Representing Tables
     3.3.4 A Simulator for Digital Circuits
     3.3.5 Propagation of Constraints
  3.4 Concurrency: Time Is of the Essence
     3.4.1 The Nature of Time in Concurrent Systems
     3.4.2 Mechanisms for Controlling Concurrency
  3.5 Streams
     3.5.1 Streams Are Delayed Lists
     3.5.2 Infinite Streams
     3.5.3 Exploiting the Stream Paradigm
     3.5.4 Streams and Delayed Evaluation
     3.5.5 Modularity of Functional Programs and Modularity of Objects

Я специально привел полное оглавление первых трех глав, чтобы показать, сколь феерично вы обделались. В классическом SICP нет ни слова ни о самом ООП, ни, тем более, о «его внутреннем устройстве». Потому что Scheme не является объектно-ориентированным языком.

Поздравляю вас, гражданин, севши в лужу :)

> совсем вслепую вбрасываешь

«Чья бы му-му», как говорится.

Kuka ★★
()
Ответ на: комментарий от Kuka

В классическом SICP нет ни слова ни о самом ООП, ни, тем более, о «его внутреннем устройстве».

Я бы предпочел обсуждать эту тему с тем, кто продвинулся чуть дальше оглавления. Ну или как минимум прочитал его внимательно, а не пропустил через 'grep OOP'.

dmsh
()
Ответ на: комментарий от dmsh

Я с самого начала подозревал, что сами-то вы книжку не читали.

Вы хоть понимаете, что там подразумевается под «объектом» в третьей главе? А то увидели знакомое слово, и возбудились на него. В SICP вообще очень оригинальная терминология: так, например, «функции» (в современной терминологии) названы «процедурами», даже те, что первого порядка. Если бы вы действительно прочитали книжку, то не делали бы таких смешных ляпов.

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

Kuka ★★
()
Ответ на: комментарий от dave

> Можешь объяснить, причем здесь, вообще, питон?

Питон тут вообще побочная ветка. Это я устраивал экскурс в историю для лисп-боя, который, похоже, не знает, откуда ноги растут у SICP, а все туда же.

Kuka ★★
()
Ответ на: комментарий от peacelove

> 1 строка про книгу, 10 строк про то какой С++ говно. НиасилилС++ головного мозга?

А зачем про «Синюю Книгу» много строк? Она большинством признана стандартом де-фактво для изучения ООП. Ее надо читать. На С++ писал пять лет, так, что знаю это говно на собственном опыте. Встречный вопрос - неасилил смоллтолк?

Не трогай ценный экспонат, это ООП-фанатик. Языки оценивает по степени их близости к Smalltalk. Скажи ему, что мир может не укладываться в объектную модель — станет фиолетовым в крапинку.

В ООП-фанатизме ничего плохого, как в lisp-фанатизме, фп-фанатизме и т.п. Через ООП можно решить большее количество задач.

BTW, фраза «99,9% задач решаемых на С++ достаточно просто решается на классическом Си» говорит нам, что перед нами товарищ, не видевший в глаза ни одного крупного C++ проекта. Телекоммуникации, бортовые системы, распределённые вычисления(в том числе с изрядным кол-м математики), распознавание образов и прочая и прочая. О да, мы сейчас это все на простеньком си перепишем и смоллтолком заполируем.

Видел большие проекты и работал над ними (в рамках нефтянки). Пока реализация была на цэпыспыс - была кривой и кособокой. Особенности языка. Про распределенные вычисления - так тогда давай лучше Fortran. C++ для математики не лучший язык все же, да и не его сильнейшая сторона мат.пременение. Большинство языков программирования позволяют проводить распределенные вычисления, и что? Аргумент С++-фапера, который дальше С++ не ушел.

Уж примитивней чем в ST еще поискать надо. ООП а-ля ST на Лиспе реализуется эдак в 40-50 строк.

Речь идет о качестве реализации, а не о сложности. Как правило самые гениальные вещи - наиболее простые. Рассматривать языки семейства smalltalk без «пространства имен»/образа (т.е. реализованной ООП-среды) некорректно.

И поменьше слушай здешних «экспертов» со smalltalk и прочими идеалами. Это всё чистая теория, которая на практике нашла ничтожное применение по сравнению с С++. С++ далеко не лишён недостатков и мне самому многим не нравится, но это быстрый ООП, это язык проверенный временем на очень широком спектре задач, обладающий огромным багажом готовых библиотек. Так что если не хочешь витать в облаках и наивно мнить себя крутым идеалистом - бери С++.

С++ - язык популярный = > дофига быдла пишут на нем, т.к. модно. По настоящему хорошие инструменты чаще всего малопопулярны ввиду своей сложности. Примеры - лисп, хаскель, форт.

Годный вброс. Приведи мне нормальный аналог связки C++/Qt4 для безпроблемного кроссплатформенного программирования.

Ruby/Qt, Perl/Qt, Paskal/Qt, C/Qt, Lisp/Qt, Shame/Qt, <любой кросплатформенный компилятор/интерпритатор языка>/Qt.

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

Мммм, ООП учили? Или на заборе как слово видели? Почитайте Blue Book

Meerkat
()
Ответ на: комментарий от Kuka

> В SICP вообще очень оригинальная терминология: так, например, «функции» (в современной терминологии) названы «процедурами»

ничего странного, просто тем самым авторы хотели подчеркнуть, что это не функции в математическом понимании + в видеоверсии вроде что-то говорилось о причинах такой терминологии

korvin_ ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.