[ООП] Как использовать на практике?

пиши код.

знать бы с какого конца за это ООП браться

Читать GoF, потом design patterns, потом изучать примеры, потом писать что то практическое

знать бы с какого конца за это ООП браться

С составления объектной модели предметной области.

Берешь текстовые описания предметной области, делаешь из них словарик. Существительные - кандидаты на то, чтобы стать классами. Глаголы - кандидаты на то, чтобы стать методами.

Дальше UML диаграммами изображаешь разные аспекты своей модели. Понимаешь, что твои абстракции не очень хороши. Меняешь их, снова рисуешь диаграммы. И так несколько итераций.

Прочитай вот эту книжку - http://www.ozon.ru/context/detail/id/87972/ (Ъ: Гради Буч - Объектно - ориентированный анализ и проектирование). Написана довольно тяжело и мутно, однако суть в ней раскрыта.

Не слушай их. Просто пиши код. Постарайся смоделировать простую жизненную систему(в упрощенном виде) в виде программы.

Читать GoF

GoF - это хорошо, но понимания ООП она не даст.

Во... только собирался написать что ща УМЛ будут шить.... и таки да... никогда не понимал зачем это говно совать в программирование.

простую жизненную систему(в упрощенном виде)

Угу. Не прыгай, взлетай! Это если жизненно, в упрощенном виде. В итоге - жизненный такой фейл. С надгробиями, например.

и таки да... никогда не понимал зачем это говно совать в программирование.

Видимо, это из-за того, что ты никого не слушал, и зажмурившись нырнул в кодинг. Это «говно» позволяет сэкономить огромный объем работы, поскольку дает возможность быстро, без написания многих тысяч строк кода, понять, как будет функционировать твоя система; на раннем этапе выявить и скорректировать изъяны.

Это «говно» позволяет сэкономить огромный объем работы, поскольку дает возможность быстро..... бла-бла-бла

А ТС написал следующее:

Я изучил общие положения ООП(наследование, инкапсуляция, полиморфизм), но так и не понял как использовать его на практике. Может быть, кто-нибудь посоветует статьи, книги, код open-source проектов?

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

Видимо, это из-за того, что ты никого не слушал, и зажмурившись нырнул в кодинг. Это «говно» позволяет сэкономить огромный объем работы, поскольку дает возможность быстро, без написания многих тысяч строк кода, понять, как будет функционировать твоя система; на раннем этапе выявить и скорректировать изъяны.

Это цитата из Энциклопедии Расхожих Заблуждений?

ООП — всего лишь удобная обёртка над обычной процедурщиной.

С процедурщиной все предельно ясно, но как использовать ООП - нет. В этом проблема. Я могу писать в процедурном стиле, но как это выразить на ООП - не знаю.

Я изучил общие положения ООП

А зачем Вы это сделали? У Вас есть какие то задачи, которые нужно решать? Так просто берите и решайте их, теперь с ООП.

А если Вы просто так его изучили... зря потратили время. «Я прочитал как держать молоток и какие бывают гвозди, не подскажите книги и статьи о том как забивают гвозди и где можно посмотреть на забитые гвозди?»;-)

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

Почитайте про fstream и iostream например. Классика жанра...

Не бывает OOP-приложений :)

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

Вот и всё. ООП — это в первую очередь инструмент борьбы со сложностью путём её разрезания на удобные куски. Ты можешь писать в рамках ООП даже на языках, которые не поддерживают соответствующий синтаксический сахар. В этом плане Сишное object_do_something(pointer) ничем не отличается от Си++шного pointer->do_something().

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

Даа, вы тут щас насоветуете ТСу.

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

Мсье, вы бредите.

Берешь философию Java. Читаешь первые две если не изменяет память главы. После чего пытаешься переложить это на свой язык.

Кстати, на каком языке пытаешься писать?

ТС совсем не об этом спрашивал.

ТС спрашивал о том, как применять ООП на практике.

И ему нечего экономить, т.к. он вообще не разрабатывает огромных проектов.

Для тебя несколько тысяч строк - это «огромный проект»?

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

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

Ага, ок. Приложение, разработанное с использованием ООП.

Почитай «Соврменное проектирование на С++» Андрея Александреску. Сразу станет ясно что, где и как. Еще можно о паттернах почитать с примерами.

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

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

программа - это не инженерная конструкция, которую спроектировал - и дальше она не меняется

писать код надо, а ООП само вылезет

ООП — это просто правила игры «весь код поделен на логические зоны

+ некие фичи для удобного порождения новых зон на основе старых, в т.ч. целыми семействами + единообразная работа с зонами принадлежащими к одному семейству;-)

Можно и так сказать.

ТС-у: Гради Буч и UML наверное нужны и полезны, если работаешь в конторе/команде где эти вещь приняты, а так... сильным это ненужно, а слабым не поможет. Занимайтесь практикой ,а не лезьте в теоретическую глухомань;-)

А я при чем? Цитата не моя.

Это не про ООП, а про набор костылей для C++.

Почитай «Соврменное проектирование на С++» Андрея Александреску. Сразу станет ясно что, где и как.

жир течет с моего монитора

Ты в общем-то всё правильно описал, но к структурному программированию это отношения не имеет никакого.

раньше я торчал в Development'е на ЛОРе, и практически не заходил в другие разделы. нынче каждый второй пост (прежде всего - комментарии к нему) здесь делает меня разочаровываться в человечестве

что касается вопроса: в том же GoF каждый паттерн предваряется постановкой задачи. бери эту задачу, решай её привычным для тебя образом (процедурным, функциональным, логическим - с чего ты там нчинал), затем смотри на предложенное ОО-решение и сравнивай. сильные и слабые стороны решения там (почти везде) описаны

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

Спасибо, Кэп. Эта беда в любом случае возникнет. Ни одна парадигма не поможет её решить.

Почитай «Соврменное проектирование на С++» Андрея Александреску. Сразу станет ясно что, где и как. Еще можно о паттернах почитать с примерами.

«магия черная белая гороскоп заговоры скачать бесплатно без смс»

Можно пробовать клепать примеры из 99 problems/ Euler project / spoj на каком-нибудь из яп, способствующих ооп-стилю: Io, ruby, python, etc...

С++/Python

Суть - в выделении объектов и в сопоставлении операций.

Суть в том, чтобы:
1. вычленить, увидеть сущности
2. понять, какие над ними возможны действия
3. представить программу в терминах этих сущностей и взаимодействий между ними

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

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

Ты листал книжки а ля «Си++ для чайников», где примеры ООП показывают на основе классификации животного мира и прочей ереси? И вот с такими познаниями люди потом идут решать реальные задачи.

«Рыбки» — это интересно. Это даже хорошо. Но прежде чем переходить к «рыбкам», человек должен уяснить, что даже когда он делает FILE * f = fopen(...); fread(f,...) , то он уже работает с объектном стиле. Если такого понимания нет, то никакие «рыбки» не помогут.

Велкам то ве клаб. Задачи какие?

На python3 с помощью pygobject3 хочу написать GUI морду к другому модулю моей программы, выполненному в виде консольного приложения.

Постарайся смоделировать простую жизненную систему(в упрощенном виде) в виде программы.

К примеру, игра «Жизнь» отлично подходит.

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

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

Ну во первых можно склепать «другой модуль» (он на С++?) в виде библиотеки для питона и не мучатся с парсингом и формированием аргументов для запуска.

Во вторых, я с pygobject3 не сталкивался, но в гуях уж обычно ООП в полный рост стоит, каждая фитюлька на окне есть отдельный объект, с атрибутами, методами, их можно собирать в более крупные объекты и т.д. Какие проблемы то?

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

ООП-приложение сначала надо тщательно спроектировать, прежде чем писать.

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

Это лишь говорит о низком качестве анализа предметной области. Одним из критериев хорошей архитектуры является то, что небольшие изменения в требованиях приводят к небольшим же изменениям в коде. Достигается это свойство (в том числе) путем обеспечения high cohesion & low coupling, на этапе анализа и проектирования.

писать код надо, а ООП само вылезет

При таком подходе вылезет пирамида из костылей и подпорок, а не ООП.

Вообще надо отметить, что ТС довольно удачно вбросил. Тема срача заезжена в Development тысячу раз, но этого менее острой не становится.

Ты листал

учился

с такими познаниями люди потом идут решать реальные задачи

в моём багаже 6 лет успешной коммерческой разработки - программистом, архитектором и руководителем группы программистов. мне не очень интересно твоё мнение о реальных задачах

Это лишь говорит о низком качестве анализа предметной области. Одним из критериев хорошей архитектуры является то, что небольшие изменения в требованиях приводят к небольшим же изменениям в коде. Достигается это свойство (в том числе) путем обеспечения high cohesion & low coupling, на этапе анализа и проектирования.

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

в моём багаже 6 лет успешной коммерческой разработки - программистом, архитектором и руководителем группы программистов. мне не очень интересно твоё мнение о реальных задачах

Ути-пути, обиделся. Я вообще--то не про тебя говорил, а про отвратное качество учебной литературы. Но если ты на свой счёт воспринял, тем хуже для тебя.