Как научиться ООП?

[ArgMax]

Добрый день!
Меня интересует как научиться объектно-ориентированному проектированию, например, на С++. Дело в том, что я привык к структурному программированию и все попытки перейти на ООП были малоэффективными. К примеру, у меня в программах часто наблюдается такая особенность - есть один большой класс, реализующий основной алгоритм, и небольшое количество вспомогательных классов. Причём основной класс имеет большое количество переменных(в основном базовых типов) и функций, что больше походит на обычную программу в структурном стиле. При этом логика программы усложняется и поддержка тоже. Взаимодействие вспомогательных классов тоже часто усложнено и создает сильную связанность классов.
Сейчас изучаю книгу "Приёмы ООП" Э.Гамма, Р.Хелм, Р.Джонсон, Д.Влиссидес и книгу Скотта Мейерса "55 верных советов улучшить структуру и код ваших программ". Подскажите пожалуйста, какие книги лучше изучить и как приложить это на практике. Есть ли какие-нибудь небольшие задачки, которые помогут на практике понять суть методов проектирования?

[creative]

Если Вы писали на C в традициях этого языка (то есть группировали данные в структуры), то можно осмыслить переход к использованию самых простых возможностей ООП следующим образом:

подход на языке C:

* есть несколько функций, которые работают с определённым количеством переменных и все эти функции с данными (переменными) связаны одной целью (например, обработка конфигурационного файла)
* эти переменные можно выделить в одну структуру и использовать этот производный тип для передачи аргументов от функции к функции
* эти функции с производным типом будут находится в отдельном файле, чтобы явно выделить их назначение (скажем это будет файл parse_conf.c), внутренние функции будут объявлены в файле как static, внешние (интерфейс) без спецификатора static

подход на языке C++ (для начала использующий только самые простые возможности ООП):

* есть несколько функций, которые работают с определённым количеством переменных и все эти функции с данными (переменными) связаны одной целью (например, обработка конфигурационного файла)
* эти функции и переменные можно объеденить в один класс (пусть это будет class config), в классе будут закрытые функции и данные (в секции private), в классе будут открытые функции в качестве интерфейса (в секции public)
* поместим этот класс в отдельный файл для удобства

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

Рекомендую почитать раздел "обзор C++" книги Бьерна Страуструпа "язык программирования c++", там он хорошо объясняет, что ООП это не конкретные языки, а парадигма программирования. Там показаны примеры использования различных парадигм программирования и описывает это в относительной независимости от конкретного языка.

P.S. Не судите строго, если что пропустил, я попробовал обрисовать как можно проще один из возможных путей перехода в ООП.

[Roman Voznyuk]

А почему для указанных задач обязательно ООП?
Почему например не реализовать на шаблонах?
Вроде как ООП считалась панацеей 20 лет назад, а современная тенденция заключается в том чтобы проделывать большую часть работы во время компиляции.

[ArgMax]

А как в данном контексте можно применить шаблоны? Я не против любых эффективных парадигм.

[TGX]

попробуйте пописать для WEB'а =) Особенно попользоваться различными API и framework'ами. Нахватаетесь ООП, почерпнёте кучу знаний, ну и это современно...

[Roman Voznyuk]

ArgMax в сообщении #342442 писал(а):

А как в данном контексте можно применить шаблоны? Я не против любых эффективных парадигм.

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

[ArgMax]

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

TGX в сообщении #342462 писал(а):

попробуйте пописать для WEB'а =) Особенно попользоваться различными API и framework'ами. Нахватаетесь ООП, почерпнёте кучу знаний, ну и это современно...

Я больше пишу математические алгоритмы для ПК. Для сети только на PHP немного программил, но не используя ООП. Но если дело стоящее, то попробую и на С++.

Roman Voznyuk в сообщении #342466 писал(а):

ArgMax в сообщении #342442 писал(а):

А как в данном контексте можно применить шаблоны? Я не против любых эффективных парадигм.

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

Т.е. параметры шаблона - указатели на функции, которые в свою очередь могут быть шаблонными?
Честно говоря, предисловие у книжки Александреску очень заманчивое так, что почитаю.

[creative]

ArgMax в сообщении #342530 писал(а):

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

Способность определять заранее, что именно следует объеденить в классы, придёт с опытом если к этому стремится. Для начала я бы порекомендовал писать программы на C++ без использования своих классов (то есть не навязывая их самому себе), а используя стандартную библиотеку C++ и постепенно привыкая на примере классов библиотеки к логике по которой функции и данные объединяются в классы и что именно становится интерфейсом, а что реализацией. То есть своя программа написанная в процедурном стиле, но с использованием производных типов (классов) из библиотеки.
Потом можно взглянуть на текст своей программы и посмотреть как по такой же логике (понятой интуитивно при использовании готовых классов из библиотеки) можно сгруппировать уже существующие функции и данные в классы, отделить реализацию от интерфейса (по сути используя те простые возможности описанные в моём прошлом ответе).

[.Serj.]

Цитата:

Я больше пишу математические алгоритмы для ПК.

Вам стоит либо оставаться на процедурном подходе, либо использовать функциональный (Haskell, OCalm, etc.). ООП вам тут особо не поможет, ИМХО. Хотя, конечно, всё зависит от конкретной задачи.

[мат-ламер]

Я помню у какого-то из классиков (может быть Вирта) была книга с названием типа "Алгоритмы + структуры данных = программы". Если хочется перейти на ООП, то эту парадигму надо заменить на "Структура данных = программы". А куда делись алгоритмы? Они там внутри данных. Можно почитать книги Брюса Эккеля - Thinking in C++, Thinking in Java. Вроде должен быть русский перевод. Можно зарегиться на каком-нибудь сайте по программированию и подробно изложить там свои проблемы (с деталями). (А можно детали изложить и в этом посту).

[Roman Voznyuk]

ArgMax в сообщении #342530 писал(а):

Т.е. параметры шаблона - указатели на функции, которые в свою очередь могут быть шаблонными?

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

[ArgMax]

Благодарю всех за ответы.