В чем преимущество ООП ?
 

В чем преимущество ООП ?
Сколько я книг не видел (наверное мало), нигде не встречал четкого ответа на этот вопрос. Везде просто доводилось до сведения, что ООП это лучше и все, а почему и в чем выгода ни как не могу понять.
Посему просьба:
объясните чем лучше
или
дайте ссылку на статью/книгу

При этом, необходимо чтобы там был пример, который должен показать эту выгоду.
Просто я никак не могу понять как классы применить для своих программ.
Пишу пока C++Builder, пока, потому что новее 6 версии билдера не будет, а переходить пока не знаю на что, но что это будет Си(С++, С#) думаю будет 99%.

Так вот хочется понять, выгоду на примерах, причем реальных, а не понятных?

ps: реальный пример: работа с БД, с обработкой файлов и т.д.

Самый реальный пример: кнопка. Если пишеш что-нибудь с интерфейсом, то кнопок наберётся много. Чтобы тридцать раз не программировать кнопку, можно её один раз запрограммировать в классе и потом вызывать этот класс.
А если пишеш просто какую-нибудь функцию, на пример поиск файла в директории, то с классами там ничего не выйграеш.
;)

spike
Вот тут уже есть очень хорошая дискуссия по интересующему тебя вопросу
http://www.wasm.ru/forum/index.php?a...ic=4762&page=0

P.S. Если ты пишешь на BCB с VCL, то уже во всю используешь ООП, часто сам того даже не замечая. Как элементарный пример: я не думаю что ты сильно замарачиваешься с работой со стандартными С-строками (char*). Уж куда ведь удобнее пользоваться AnsiString ;)

ооп как абстракция более понятен человеку.

spike:
Много чего полезного и правильного есть в ООП.
Ну, для новичка я бы объяснил так:
Класс (объект) - это совокупность методов и данных. Если ты пишешь на чистом C, то твой проект состоит из файлов. В файле у тебя есть функции и есть глобальные переменные. С точки зрения ООП, можно сказать, что каждый файл (.c) - это класс (точнее, это реализация класса). У такого файла-класса есть интерфейс (заголовочный файл .h).

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

Если хочешь, попробуй найти книжку Гради Буч: Объектно-ориентированный анализ и проектирование. В ней не только есть примеры программ, но и объясняются принципы правильного проектирования.

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

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

Абсолюно точно. Просто для человека представить окружающий нас мир очень просто. И иерархию классов выстроить просто.
Дерево ->
Хвойное дерево ->
Сосна.
Ель
Лиственное дерево
Береза
Ольха
И т.д. Причем у Сосна, Ель, Береза, Ольха есть общие и различные свойства и методы. Вместо того чтобы описывать все общие свойства и методы каждый раз заново, ты описываешь их в базовом классе Дерево и _забываешь как они реализованы_. Тебе уже это не важно. Дальше ты просто наращиваешь функционал дочернего класса для конкретного дерева. Когда ты пишешь функции, чаще всего надо понимать и иметь перед глазами весь код. Здесь же реализация от тебя спрятана (в хорошем смысле этого слова). Ты просто знаешь. что умеет этот объект и что его характеризует. Если провести аналогии с русским языком, свойства - это прилагательные, а методы - глаголы. Классы позволяют четко структурировать данные. Но, если у тебя прога в три пейддауна, классы сделают из них пять:). Нерентабельно. Однако если у тебя 1000 пейдждаунов, ты в своих функциях заблудишься, кто кого откуда вызывает. А в класса внутренняя реализация не важна. Не важно как хранятся данные. важен только способ получения данных и совершение действий над ними.
Когда ты пишешь процедуры, они рождаются экспромтом по мере необходимости. Потом, когда надо обощить несколько частных функций в одну, придется переправлять половину кода, везде, где они использовались. Классы так писать просто не получится. Ты всегда вначале продумываешь все структуру классов, их взаимоотношение и т.д., а потом только садишься кодировать (по-другому просто не получится:)). Классы заставляют продумать будущее приложение. Все недостатки и неувязки проекта сразу станут видны. Самое просто применение классов - визуальные объекты (формы, кнопки, тулбары). Но почему бы не сделать класс для жесткого диска - диск, партишен, директория, файл... для партишена делаем свойство label и метод format. причем не надо каждый раз задавать, какой диск ты хочешь форматнуть и какому хочешь сменить имя. Это ты задашь один раз при создании класса. И еще для смены label и получения значения метки тома ты бы писал 2 функции SetLabel(volume) и SetLabel(volume). И каждый раз вызывал бы поочереди эти свойства. В при использовании классов ты просто напишешь во внешней функции value = volume.Label или volume.Label = new_value. Внутренне, это кончено 2 функции. но это абсолютно не важно. В том и прелесть что отделяется понятие использования объекта от его внутреннего состава

Очередной вопрос из разряда "что лучше"
(типа: pentium - athlon, c++ - pascal, windows - linux и т.п.)

Правильнее было бы ГДЕ лучше использовать ООП, а где и старенький структурный сгодится.
Если переформулировать таким образом, то ответ будет таков -

1. Желаешь использовать свои наработки неоднократно либо предоставить свои труды на разграбление другим - твори в ООП

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

2. Создаешь нечто одноразовое и уникальное (например дипломный проект :) ) - предпочти что-либо менее трудозатратное.

Ибо использовать чужой код в ООП - одно удовольствие (в Builder-e мышью оттягивается), а вот писать свое... тут уж готовся к нетривиальному обьектному анализу и жуткому модульному тестированию