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

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

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

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

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

тема почти флеймовая, но тем не менее:
пишешь на билдере, с использованием VCL? - тогда попробуй написать тоже самое на winapi. вот тебе и конкретный ответ.
А насчет книг - просто не те книги попадались

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

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

spike

Цитата:

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

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

spike
В том, что программы легче проектировать, кодировать и поддерживать. Т.е. при правильном проектировании программы при необходимости изменений приходится менять гораздо меньше кода, чем при процедурном программировании.
Из плюсов: возможность повторного ипользования кода (компонентность), сокрытие излишней детализированной информации от разработчика, наглядность кода (для человека более свойственно воспринимать обьекты со свойствами и методами, чем процедуры) итд.
Плюс ко всему существуют средства визуального проектирования и кодогенерации, которые во много раз ускоряют процесс создания программ, да и понимания тоже.

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

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


Цитата:

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

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

Думай, читай, смотри код. Пока не созрел. Вернее, IMHO, у тебя не было проекта который большой/сложный. Который нужно сопровождать. После такого проекта все что описано по ОО проектированию, анализу и тем более программированию становится ясным. Все становится на места и начинаешь понимать все книжки которые прочитал по ОО.

Как пример работы с базой данных.
Пусть есть у нас класс который ответственен за хранение инфы о предприятиях и людях.
нужно хранить инфу полное наименование, краткое наименование, Банковские реквизиты, адрес, телефон(ы) для предприятий. Фамилию имя отчество, адрес, телефон для физического лица.
Пускай у нас данные храняться в таблицах
Objects (краткое имя, ID) (для облегчения поиска)
Person (ID, фамилия, имя, отчество, адрес)
Org (ID, полное наименование, Банковские реквизиты, адрес)
Phones (ID, SubID, номер телефона)

Все объекты которые мы хотим хранить в БД должны писать себя в Objects в обязательном порядке, и в другие таблицы по необходимости.

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

Пускай у нас есть три класса.
иерархия
DBObject->Person
DBObject->Org

1. DBObject - базовый класс записывает себя в Objects
2. Person - записывает себя в Person, Phones
3. Org - записывает себя в Org, Phones

Тебе не нужно занть из скольких мест ты вычитываешь (и восколько вставляешь) данные.

Если ты хочешь ввести другой класс ты должен отнаследоваться от DBObject и тебе уже не важно как этот объект сохранит себя в Objects, ты занешь что сохранит в обязательном порядке. Тебе достаточно отладить DBObject один раз и он будет себя вести везде одинаково.

Если тебе нужно добавить другой телефон к физическому лицу, то тебе не прийдется (при работе без объектов) лопатить половину программы выискивая а где же уменя (или у этого идиота за которым мне приходится хвосты подчищать) есть доступ к БД. Потому что нужно проконтролировать все эти места, и не важно что доступ к двум телефонам у меня в одной лишь форме, сохраняюсь я в 10 местах и не факт что правильно. А так вызвал MyPeron.save и даже не занаю что для этого снеслось пол базы в одном месте и вставилось в другом.

Главные преимущества ооп - это три краеугольных камня ооп: инкапсуляция, наследование, полиморфизм.

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

Ой, да в принципе преимуществ до фига, просто те надо писать, думать, опять писать и сам созреешь

spike
ООП абсолютно не запрещает ничего структурного, всё тоже самое есть в нём. В этом смысле никакой разницы. Разница появляется когда у тебя есть похожие процедуры принимающая в качестве параметра MyRec типа Record (или Struct для C). Ты пишешь:

Код: MyProc1(MyRec,....

spike
понимание придет с опытом

spike
почитай Буча ( он и в электронном виде есть)

1

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

spike

Цитата:

то я использую стуктуры и функции и всё
и не вижу зачем мне классы

Ну стуктуры, это практически те же классы, с одной лишь маленькой разницей...
vserd

Цитата:

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

Да и с чужих толковых наработок, встроить что-то тогда легче.

Да Вы что????? Озверели что ли (извиняюсь)?
ООП необходим во всех программах желающих иметь интерфейс выше уровня Goto(X,Y).
С появлением в советской промышленности манипуляторов "колобок" (это такая здоровенная мышка с большим металлическим шариком), разработка программ стала ориентироваться на экранную область. Было написано дофига IDE и все они на ООП потому что Move(X,Y) это Hide(object) изменение координат и Show(object) значит рядом с данными о координатах надо хранить указатели на функции рисования, а на ООП это делается одним словом virtual. Так что вопросы надо было задавать 15 лет назад. А сегодня рынок другого уже не примет.

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

Но процедурное тоже имеет плюсы и немало.

UncoNNecteD

Цитата:

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

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

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

А вообще ООП - этохорошо-о-о

Цитата:

А вообще ООП - этохорошо-о-о

Халявнее, но не лучше.

UncoNNecteD

Цитата:

Халявнее, но не лучше.

Расшифруй мысль...

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

UncoNNecteD

Цитата:

Плюс к тому проффесионализм программистов падает, ростут требования к системам.

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

UncoNNecteD

Цитата:

написанные объекты (например компоненты) позволяют делать сложные приложения быстро

Это зависит от очень многих факторов.

Цитата:

проффесионализм программистов падает

Спорное заявление.
Смотря что понимать под проффесионализмом...

UncoNNecteD

Цитата:

Плюс к тому проффесионализм программистов падает

Проффесионализм не падает. Просто определяется по несколько другим критериям

dneprcomp

Цитата:

Проффесионализм не падает. Просто определяется по несколько другим критериям

А вот с этим согласен.

Цитата:

UncoNNecteD

Цитата:
написанные объекты (например компоненты) позволяют делать сложные приложения быстро
Это зависит от очень многих факторов.

Расшифруй мысль


Цитата:

Проффесионализм не падает. Просто определяется по несколько другим критериям

Какими? Знанием компонентов? Или умением быстро их найти?

UncoNNecteD

Цитата:

Знанием компонентов? Или умением быстро их найти?

А кто же их пишет?
Да и не все так просто с готовыми библиотеками, например доскональное понимание stl, boost и других сложных объектных библиотек уже достойно огромного уважения.
--
All
Что-то этот топик мягко перетекает по флеймовости в знаменитый "Самый перспективный язык"

Как я уже писал, я познакомился с ООП приблизительно 15 лет назад. Тогда я пробовал писать графический редактор у которого курсор в виде крестика двигался не мышью а клавишами стрелок. Тогда же мне пришла в голову гениальная мысль о таблицах с адресами процедур для графических рекордов и для драйверных рекордов. И тут я начал знакомиться с ООП... Я обалдел - всё о чём я тогда мечтал сбылось!!! Теперь можно проделывать всё что угодно! Потом я востанавливал с TPU файлов библиотеки TVision исходники (их ещё нигде небыло). Востановил до половины... Так к чему я веду.
- Никакой дополнительной оптимизации ООП программам не надо. Нужно только понимать где нужна реинтерабельность, а где объектный подход. Можно переписать любую ООП программу на структурную. Даже если не пытаться проделать это с OLE автоматизацией, будет понятно, что это куча гемароя и море констант.
Примером такой кучи является InterBase. IB попытались преодолеть ограниченность DLL для виртуальных методов, но их золотой век кончился с появлением интерфейсов. Ну и теперь, если сравнить MSSQL и IB, станет ясно, что IB ждёт участь BDE - их забудут, как недоразумение. Интересно, что переписав сервер с IB на MSSQL я не заметил никакой потери в скорости. Просто с самого начала был грамотный подход.
Реинтерабельность. Если кто не знает что это такое - так это независимость алгоритма от объектов и классов объектов с которыми алгоритм работает. Кстати именно в ООП это понятие очень важно - например в Java.
Напоследок "анегдот" - нафига мне оператор "case", я слышал, что всё можно написать оператором "if-then". А оператором "if-then" я умею пользоваться, поэтому объясните чем "case" лучше? А ещё я могу вместо "if-then" "while break" использовать.
Так не будем похожи на тех кто пытается сравнивать то что знает с тем чего он не знает. Лучше потратить время на освоение нового.

UncoNNecteD

Цитата:

Цитата: Проффесионализм не падает. Просто определяется по несколько другим критериям

Какими? Знанием компонентов? Или умением быстро их найти?

Знание библиотек и компонентов наиболее важный фактор. Встретился мне компонент TARHotKey(комбинации клавишь, обычно секретные, без визуальных компонентов) - ерунда конечно, но весьма полезный компонент сказали мне. Хотел я его переписать по грамотнее да вспомнил - кладёшь на пустую форму TActionList, создаёшь акцию, пишешь ручками в инспекторе объектов свойство ShortCut (например Left) и получаешь то, что делает TARHotKey. Глюк в том что люди по незнанию создают то чего давно уже не надо, а другие по этому же незнанию пользуются тем, что было написано, а потом не могут перелезть на более новые версии Delphi...

Цитата:

тема почти флеймовая

Да тема точто почти, что флемная.

Создателю топика. Почитай
Гради Буч
Объектно-ориентированный анализ и проектирование
с примерами приложений на С++
Имхо одна из лучших книг по ООП.