Когда нужно использовать ООП?

← →
leklerk © (2012-05-28 18:52) [0]

Добрый день! Интересно было бы услышать мнения о том, когда нужно использовать ООП в delphi, какие-то примеры. Поделитесь своими соображениями и опытом!

← →
robt (2012-05-28 19:04) [1]

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

← →
Медвежонок Пятачок © (2012-05-28 20:29) [2]

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

← →
ProgRAMmer Dimonych © (2012-05-29 10:48) [3]

А не слишком ли расплывчатая формулировка вопроса? Ведь формы с их методами и свойствами - тоже ООП.

← →
Ega23 © (2012-05-29 10:52) [4]

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

← →
ProgRAMmer Dimonych © (2012-05-29 10:55) [5]

> [4] Ega23 © (29.05.12 10:52)

А не слишком ли расплывчатая формулировка вопроса? Ведь солдатская каска с её формой и термоустойчивостью - тоже посуда.

← →
Ega23 © (2012-05-29 10:58) [6]

> Ведь солдатская каска с её формой и термоустойчивостью - тоже посуда.

Для начала рекомендую каску в костёр поставить и посмотреть что будет.

← →
ProgRAMmer Dimonych © (2012-05-29 11:08) [7]

> [6] Ega23 © (29.05.12 10:58)

Так можно и с одноразовым пластиком (тарелки, стаканчики) поступить. Хотя да, про термоустойчивость это я [внимание!] погорячился :)

← →
Anatoly Podgoretsky © (2012-05-29 11:14) [8]

> Ega23 (29.05.2012 10:52:04) [4]

Да запросто, например когда готовишь шашлык посуда не нужна. Теперь в
предметной области property posuda: boolean ...

← →
AV © (2012-05-29 11:16) [9]

Когда писать придется много.
Помнится, читая примеры, не понимал, зачем это все они делают? Тут же две строки написать, если не ООП делать.
А когда писать приходится 10 000 строк, а потом делать что-то похожее, немного изменив начальное, тут и приходит ООП. Делаешь базовый класс, определяешь его самые общие св-ва/методы, потом только расширяешь.
А найдя ошибку логики/ заточив под новые требования, не переписываешь кучу программ/программок/утилит. А только _перекомпилируешь, поправив базу.

зы
да нет проблем, надо просто котелок использовать как головной убор :)

← →
ProgRAMmer Dimonych © (2012-05-29 11:18) [10]

> [9] AV © (29.05.12 11:16)

А ещё, если котелок варит, можно не прятать его под головным убором :)

← →
Ega23 © (2012-05-29 11:18) [11]

> Так можно и с одноразовым пластиком (тарелки, стаканчики)
> поступить. Хотя да, про термоустойчивость это я [внимание!
> ] погорячился :)

Не в термоустойчивости дело. Каска в этом плане вполне нормальная. просто она покрашена. Задолбаешься краску с неё обжигать, прежде чем что-то готовить :)

Но мы отвлеклись от темы. Можно приготовить пожрать, не используя всякие кастрюли, котелки и сковородки? Можно. Но с ними - удобнее и быстрее.
Вот ровно то же самое и с ООП.

← →
oldman © (2012-05-29 12:07) [12]

> Можно приготовить пожрать, не используя всякие кастрюли,
> котелки и сковородки? Можно. Но с ними - удобнее и быстрее.

А бутерброды?
Быстро, удобно, без кастрюли.

← →
Ega23 © (2012-05-29 13:06) [13]

> А бутерброды?
> Быстро, удобно, без кастрюли.

А ООП - это не панацея от всех бед. Равно как и кастрюли-сковородки. Где-то вообще не нужно ("бутерброды"), где-то унылый костыль ("шашлык"). Где-то epic win ("щи" и "утка по-пекински").

← →
Anatoly Podgoretsky © (2012-05-29 13:22) [14]

> Ega23 (29.05.2012 13:06:13) [13]

От щей и утки не отказужусь

← →
RWolf © (2012-05-29 13:25) [15]

«и того, и другого! и можно без хлеба»

← →
stas © (2012-05-29 15:21) [16]

leklerk © (28.05.12 18:52)
Если Вы понимаете ООП Вы таких вопросов задавать не будете, если нет, то какой смысл Вам объяснять.

← →
AV © (2012-05-29 16:14) [17]

> stas © (29.05.12 15:21) [16]

нет-нет.
Когда изучали ООП нам Федосин приводил примеры разные.
Вроде делаем объект1, объект2(объект1), объект3(объект1)
в объекте1 есть св-во Color.
Далее любому объекту говорим цвет = зеленый. Оп-па, и он зеленый.

И вот тут именно, надо сразу оговорится, что на простых примерах это не наглядно. Потому что всегда думал - сколько же ты понаписал тут..class virtual, override, а почему бы не вызвать закраску по региону нужным цветом - ну строка кода всего-то..
Ну и для объект2 и объект3 повторил. Все равно меньше, раза в 2, выходит писанины.
А потому что кода больше 2-3 000 строк не видел еще в глаза тогда :)

← →
stas © (2012-05-29 16:57) [18]

Весь прикол ООП не в том что меньше писанины, а в том что, есть возможность объявить О:Объект1 и где-то в коде присвоить ему color, и без разницы О это будет Объект1 или Объект2,Объект3.
в коде это будет выглядеть так

procedure paintToRed (O:TObject1) begin O.color = clred; end; .... Var O1, O2 :TObject1; O3:Tobject3; .... O1:=TObject1.Create(); O2:=TObject2.Create(); O3.TObject3.Creatte() .... paintToRed(O1); paintToRed(O2); paintToRed(O3);

← →
stas © (2012-05-29 16:58) [19]

*O3:=TObject3.Create()

← →
Медвежонок Пятачок © (2012-05-29 17:03) [20]

вообще это прикол не ОПП, а всего лишь полиморфизма прикол.

← →
stas © (2012-05-29 17:14) [21]

Да но полиморфизм один из механизмов ООП, реализацию которого я лично встречал только в ООП

← →
MonoLife © (2012-05-29 17:32) [22]

> От щей и утки не отказужусь
... «и того, и другого! и можно без хлеба»

ща "давайте будем жрать!" придет и всё съест))

← →
stas © (2012-05-29 17:37) [23]

stas © (29.05.12 17:14) [21]
Хотя возможно перегрузка функций это в какой-то степени тоже полиморфизм.

← →
Медвежонок Пятачок © (2012-05-29 17:37) [24]

Да но полиморфизм ....

Ага.
Но ты-то сказал, что ВСЯ фишка ооп - это твой прикол с полиморфной обработкой объектов.

← →
stas © (2012-05-29 21:39) [25]

Медвежонок Пятачок © (29.05.12 17:37) [24]
Ну, да. А без полиморфизма мало толку от ООП.

← →
Ega23 © (2012-05-29 21:45) [26]

> А без полиморфизма мало толку от ООП.

Это ещё почему?

← →
Loginov Dmitry © (2012-05-29 21:50) [27]

Кто-нибудь обращал внимание, какое определение инкапсуляции (важнейшего правила ООП) дает Википедия?
http://clck.ru/W/19Vrx
И это у них очень давно. А ведь это первое, что выдают поисковые машины.
:(

← →
Ega23 © (2012-05-29 21:53) [28]

> Кто-нибудь обращал внимание, какое определение инкапсуляции
> (важнейшего правила ООП) дает Википедия?

А что там не так?

← →
Медвежонок Пятачок © (2012-05-29 21:54) [29]

Ну, да. А без полиморфизма мало толку от ООП.

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

← →
Loginov Dmitry © (2012-05-29 21:59) [30]

> Хотя возможно перегрузка функций это в какой-то степени
> тоже полиморфизм.

Полиморфизм - это когда методы с одним и тем же именем у разных наследников делают разные вещи.
А всякие фишки типа virtual / override и прочее - это уже дополнительные навороты (правда, поддерживаемые единообразным способом всеми языками).

← →
Медвежонок Пятачок © (2012-05-29 22:01) [31]

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

← →
Loginov Dmitry © (2012-05-29 22:01) [32]

> А что там не так?

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

← →
Loginov Dmitry © (2012-05-29 22:06) [33]

> Когда нужно использовать ООП?

ООП упрощает программирование в десятки / сотни / тысячи раз (в зависимости от сложности проекта).
Использовать его нужно при разработке более-менее сложных программных проектов.

← →
Медвежонок Пятачок © (2012-05-29 22:06) [34]

по моему все там понятно.
но написано с точки зрения не того, кто инкапсулирует, а с точки зрения того, кто пользуется инкапсулированным.

а суть проста - сокрытие реализации.

← →
Loginov Dmitry © (2012-05-29 22:10) [35]

> по моему все там понятно.

Для кого понятно?
Мы и так знаем, что такое инкапсуляция и не пойдем все это читать.
А что, если человек не знает и хочет понять? В англоязычной версии четко говорится, что есть 2 определения инкапсуляции, а в нашей версии оба определения слили в одно, мол сами разберетесь, люди добрые.

← →
oxffff © (2012-05-29 22:16) [36]

полиморфизм и его виды
http://en.wikipedia.org/wiki/Polymorphism_(computer_science)

← →
Медвежонок Пятачок © (2012-05-29 22:27) [37]

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

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

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

← →
Loginov Dmitry © (2012-05-29 22:34) [38]

> и чего конкретно здесь может быть непонятно для того, кто
> не знает что такое инкапсуляция?

Куча незнакомых терминов:
- программный компонент;
- интерфейс;
- члены ("публичные" конечно же);
- "жизненно важные для компонента данные";
- спецификация объекта;
- etc.

Так на кого рассчитано подобное определение?

← →
Медвежонок Пятачок © (2012-05-29 22:40) [39]

Для кого незнакомых?

Для незнакомого с программированием сферического коня ?

Ну таки да, куча.
А оно для него написано?
А может оно написано для того, кто процедурным уже владеет и хочет перейти на ООП?

Для этого какие термины в непонятной куче окажутся?

← →
Loginov Dmitry © (2012-05-29 22:50) [40]

> А может оно написано для того, кто процедурным уже владеет
> и хочет перейти на ООП?

Вряд ли процедурное программирование здесь чем-то поможет.
Какие именно термины являются понятным для человека, владеющего процедурным программированием?

← →
Медвежонок Пятачок © (2012-05-29 22:58) [41]

А какие непонятными?

Потому что понятные - все.

← →
Inovet © (2012-05-30 00:42) [42]

> [27] Loginov Dmitry © (29.05.12 21:50)
> инкапсуляции

ООП языки встречают ассемблер.
- Это что за тип?
- А есть ли на него данные?
- Инкапсулировать таких надо.

← →
Inovet © (2012-05-30 00:45) [43]

> [35] Loginov Dmitry © (29.05.12 22:10)
> В англоязычной версии четко говорится, что есть 2 определения
> инкапсуляции, а в нашей версии оба определения слили в одно,
> мол сами разберетесь, люди добрые.

Можно же поправить.

← →
Германн © (2012-05-30 00:49) [44]

Хм. И почему этот трёп до сих пор не в "Потрепаловке"?
:)

← →
Anatoly Podgoretsky © (2012-05-30 07:32) [45]

> какое определение инкапсуляции (важнейшего правила ООП)
> дает Википедия?

Да уж, просто страшно становится

← →
stas © (2012-05-30 09:07) [46]

Медвежонок Пятачок © (29.05.12 21:54) [29]
В смысле чушь? обоснуй.

← →
Медвежонок Пятачок © (2012-05-30 09:09) [47]

Я уже два раза тебе обосновал. Но если не доходит - то оно мне надо?

← →
stas © (2012-05-30 09:09) [48]

Медвежонок Пятачок © (29.05.12 22:01) [31]
Я не путаю, назови определение полиморфизма.

← →
Медвежонок Пятачок © (2012-05-30 09:10) [49]

Назови все медали комсомола.

← →
Медвежонок Пятачок © (2012-05-30 09:14) [50]

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

← →
stas © (2012-05-30 09:18) [51]

Медвежонок Пятачок © (30.05.12 09:14) [50]
я такого в принципе не писал.
Ну, а если ты видишь фишку ООП в другом, то какой смысл с тобой спорить.

← →
Медвежонок Пятачок © (2012-05-30 09:21) [52]

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

Про связь одноименных методов с полиморфизмом я уже не говорю. Это для тебя вообще непосильно.

← →
stas © (2012-05-30 09:24) [53]

> Ты настолько туп

Скорее всего твой интеллект заканчивается на этом...
И то что описано в ветке

> stas © (29.05.12 16:57) [18]

Никакого отношения к полиморфизму не имеет.

← →
Anatoly Podgoretsky © (2012-05-30 09:25) [54]

> Хм. И почему этот трёп до сих пор не в "Потрепаловке"?

Да просто промах, но вероятно оно и там не уживется, уже ругаться стали

← →
alexdn © (2012-05-30 09:36) [55]

> Ega23 © (29.05.12 10:52) [4]
> Добрый день! Интересно было бы услышать мнения о том, когда
> нужно пользоваться посудой для приготовления пищи, какие-
> то примеры. Поделитесь своими соображениями и опытом!
+1000 )
> Loginov Dmitry © (29.05.12 21:50) [27]
> Кто-нибудь обращал внимание, какое определение инкапсуляции
> (важнейшего правила ООП) дает Википедия?
жесть жестокая!

← →
Inovet © (2012-05-30 09:39) [56]

> [54] Anatoly Podgoretsky © (30.05.12 09:25)
> но вероятно оно и там не уживется, уже ругаться стали

Может перестанут.

← →
robt (2012-05-30 10:50) [57]

> А найдя ошибку логики/ заточив под новые требования, не
> переписываешь кучу программ/программок/утилит. А только
> _перекомпилируешь, поправив базу.

это относится к любой либе готового кода, ООП не причем

> stas © (29.05.12 16:57) [18]

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

> Полиморфизм - это когда методы с одним и тем же именем у
> разных наследников делают разные вещи.

это уже не полиморфизм, а метадибилизм если SetColor у одного будет менять цвет ,а у другого размеры :)

← →
stas © (2012-05-30 11:00) [58]

robt (30.05.12 10:50) [57]
Еще один...
Основания?

Это полиморфизм, а уж что туда заложит программист можно считать чем угодно.
Метод area у TCircle считает площадь по одному, TRrectangle по другому
а если кто-то туда заложит периметр, то это проблема программиста.

← →
Пользователь интернета (2012-05-30 11:02) [59]

А вот в языке 1С нет ООП. Совсем. Зато есть километры процедурья.

← →
stas © (2012-05-30 11:03) [60]

Пользователь интернета (30.05.12 11:02) [59]
А в C# только ООП

← →
Давайте будем жрать! (2012-05-30 11:06) [61]

> MonoLife © (29.05.12 17:32) [22]
Не. /me на больничном сидит и аппетита нету.

← →
Ega23 © (2012-05-30 11:07) [62]

А у меня товарищ есть, на заводе токарем работает. У него на члене восемнадцать воробьёв помещается.

← →
sniknik © (2012-05-30 11:16) [63]

Ega23 © (30.05.12 11:07) [62]
а у 18-го лапка не соскальзывает? а то уж черезчур. :)))

← →
ProgRAMmer Dimonych © (2012-05-30 11:20) [64]

> [37] Медвежонок Пятачок © (29.05.12 22:27)
> и чего конкретно здесь может быть непонятно для того, кто
> не знает что такое инкапсуляция?
>
> Инкапсуля?ция — свойство языка программирования, позволяющее
> пользователю не задумываться о сложности реализации используемого
> программного компонента (то, что у него внутри), а взаимодействовать
> с ним посредством предоставляемого интерфейса (публичных
> членов — методов, данных etc.), а также объединить и защитить
> жизненно важные для компонента данные. При этом пользователю
> предоставляется только интерфейс — спецификация объекта.
>
> как минимум понятно, что есть объект, объект может быть
> непростым, но мне как его пользователю повезло, так как
> автор объекта скрыл от меня все сложности, оставив только
> понятные свойства и методы.

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

* Свойство ЯП? ЯП.
* Позволяет не задумываться о сложности реализации? Да ещё как, сишный зоопарк намного сложнее.
* Интерфейс для работы с ними предоставляется? А иначе бы и работать с ними нельзя было бы, без интерфейса-то.
* Объединить и защитить жизненно важные данные? Ну так ведь есть же, пока сам не полезешь по отрицательным смещениям, всё будет в порядке.
* Предоставляется ТОЛЬКО интерфейс? Ну да, по идее они имеют полное право изменить внутреннее представление String"а, а кто полагался на нынешее - сам себе злобный Буратино.

← →
Ega23 © (2012-05-30 11:20) [65]

> а у 18-го лапка не соскальзывает?

Даже не соскальзывает, а вообще свисает.

← →
Inovet © (2012-05-30 11:21) [66]

> [62] Ega23 © (30.05.12 11:07)
> восемнадцать воробьёв помещается

В попугаях меряться надо. А то у одного воробьи, у другого муравьи, у третьего зелёные (груши).

Это размышления о

> [58] stas © (30.05.12 11:00)
> а если кто-то туда заложит периметр, то это проблема программиста

← →
oxffff © (2012-05-30 11:33) [67]

> Когда нужно использовать ООП?

Когда УЗИ, МРТ и ЭКГ не помогают.

← →
Anatoly Podgoretsky © (2012-05-30 11:34) [68]

> ProgRAMmer Dimonych (30.05.2012 11:20:04) [64]

Инкапсуляция это просто когда код и данные вместе, в объекте, и ничего
более, остальное вольные интерпретации

← →
ProgRAMmer Dimonych © (2012-05-30 11:37) [69]

> [68] Anatoly Podgoretsky © (30.05.12 11:34)

Ну [64] как раз и было в поддержку того, что определение не айс. :)

← →
Inovet © (2012-05-30 11:48) [70]

> [68] Anatoly Podgoretsky © (30.05.12 11:34)
> Инкапсуляция это просто когда код и данные вместе, в объекте, и ничего более

Нет, это скрытие в первую очередь, а уже потом как, через что и в каком виде оно снаружи доступно.

← →
Slider007 © (2012-05-30 11:49) [71]

Когда на Делфи писал, тоже не особо понимал нафиг этот ООП нужен. Да особо и не стремился понять, и так хорошо было.

Когда немного перелез на C#, в котором надо очень сильно заморочиться, чтоб ОПП не использовать, тогда и пришло понимание. ООП это просто удобно в процессе написания программы. После компиляции, программа не будет лучше или хуже от того, что ты использовал или не использовал ООП, хотя кто-нибудь наверное захочет это оспорить :).

← →
Ega23 © (2012-05-30 11:50) [72]

Определение как определение, у нас тут не Первый закон Ньютона, где точность офигенно важна.
Буквоедам рекомендую определения нормальных форм в РСУБД почитать, в разных источниках.

← →
robt (2012-05-30 11:55) [73]

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

← →
Компромисс © (2012-05-30 11:56) [74]

Slider007 © (30.05.12 11:49) [71]

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

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

← →
Медвежонок Пятачок © (2012-05-30 12:17) [75]

После компиляции, программа не будет лучше или хуже

после компиляции она (ооп) таки скорее будет хуже.
пример - когда выложили исходники древней игрухи (вроде бы это была квака) - то все отложили много кирпичей гляда на код. тем не менее бинарник работал и работал (на тех процах) быстро. хотя там и был сплошной копипаст-метод и ни грамма гламура модных технологий.

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

← →
Kerk © (2012-05-30 12:18) [76]

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

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

---
Ну я все сказал. Пойду завтракать.

← →
Медвежонок Пятачок © (2012-05-30 12:21) [77]

полиморфизм - возможность однообразной обработки разнородных объектов.

← →
Ega23 © (2012-05-30 12:25) [78]

> Инкапсуляция присуща не только ООП.

Во-во, триггер - классика жанра.

← →
Медвежонок Пятачок © (2012-05-30 12:28) [79]

ну вы оба капитаны.

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

не только триггер, но любая функция - это тоже инкапсуляция.

← →
Inovet © (2012-05-30 12:28) [80]

> [73] robt (30.05.12 11:55)
> с меня клетка с воробьями

Воробьи по 0,5 литра?

← →
Kerk © (2012-05-30 12:33) [81]

> Медвежонок Пятачок © (30.05.12 12:28) [79]
> ну вы оба капитаны.

Глядя на определение инкапсуляции в википедии, а так же на посты типа [68] от неглупых людей. Так нет, не капитаны.

Из-за написания вот этого вот в определении(!!!) инкапсуляции умер котенок:

* Пользователь может взаимодействовать с объектом только через этот интерфейс. Реализуется с помощью ключевого слова: public.

* Пользователь не может использовать закрытые данные и методы. Реализуется с помощью ключевых слов: private, protected, internal.

FACEPALM. Действительно стоит статью исправить.

← →
Ega23 © (2012-05-30 12:43) [82]

> Из-за написания вот этого вот в определении(!!!) инкапсуляции
> умер котенок:

Ну тут просто частный случай описан. Общий - застрелишься описывать. Вон, в Delphi единица инкапсуляции - юнит. В рамках одного и того же юнита могу видеть приват других классов.
Характерный пример в DB.pas
procedure TDataLink.DataEvent(Event: TDataEvent; Info: Longint); .... if DataSource.State <> dsSetKey then begin Active := DataSource.DataSet.FActiveRecord;
И пипец, приплыли. Я сейчас уже не вспомню (а вспоминать - лень), но где-то лет 6 назад здорово накололся в этом месте, когда db-control писал.

Ну а с теперешним набором возможностей Delphi (RTTI на private и protected свойства, strict private и т.п.) тут вообще вся эта ваша инкапсуляция размазывается в кашу.

← →
Kerk © (2012-05-30 12:47) [83]

> Ega23 © (30.05.12 12:43) [82]

Что значит застрелишься? Это я не секцию примеров процитировал, это определение понятия! Нафига там ключевые слова какие-то -- все эти publuc/private?

Кстати, вот в англоязычной статье и про модули вспомнили:
This mechanism is not unique to object-oriented programming. Implementations of abstract data types, e.g. modules, offer a similar form of encapsulation.

← →
Медвежонок Пятачок © (2012-05-30 14:09) [84]

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

Вы неточность определения рассматриваете абстрактно.
А там конкретно упоминается пользователь инкапсулированного объекта.

Вы же смотрите на определение и с позиций того кто инкапсулирует и с позиций того, для кого инкапсулируют.

Пользователь - тот действительно к приватам не имеет доступа. И юзает только паблик интерфейсы.

← →
Ega23 © (2012-05-30 14:11) [85]

> Пользователь - тот действительно к приватам не имеет доступа.

Через RTTI

← →
Медвежонок Пятачок © (2012-05-30 14:23) [86]

во первых там определение инкапсуляции вообще а не для конкретного языка с ртти.

во вторых выделенные керком пункты про паблик и приват не являются самостоятельными утверждениями, а являются пояснениями к строкам что выше:

позволяющее пользователю не задумываться о сложности реализации ......
а также объединить и защитить....

дальше идет "при этом" - и те куски к которым у вас претензии.

Вот если бы так и было написано, что инкапсуляция - это когда доступен только паблик, а до привата не добраться, - вот тогда и можно было бы делать лицорука.

← →
Kerk © (2012-05-30 14:29) [87]

Не вижу о чем тут спорить. Если опора на синтаксис конкретных языков в энциклопедическом определении общего понятия для тебя нормально, то пусть так, ок.

← →
Kerk © (2012-05-30 14:30) [88]

> Ega23 © (30.05.12 14:11) [85]
>
> > Пользователь - тот действительно к приватам не имеет доступа.
>
> Через RTTI

Ну к чему эта клоунада? Ты еще вспомни, что даже из другого процесса всю эту память можно перезаписать, а значит инкапсуляции не существует в принципе.

← →
Ega23 © (2012-05-30 14:34) [89]

> Ну к чему эта клоунада?

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

← →
Kerk © (2012-05-30 14:37) [90]

> Ega23 © (30.05.12 14:34) [89]

Запись в чужой процесс -- это тоже не хак, а штатная возможность операционной системы.

← →
robt (2012-05-30 15:12) [91]

это походу единственный форум, где вместо ответа на вопрос начинаются членомерство
а автор этот вопрос на пяти форумах запостил

← →
картман © (2012-05-30 15:17) [92]

> robt (30.05.12 15:12) [91]
>
> это походу единственный форум, где вместо ответа на вопрос
> начинаются членомерство

предлашаю перенести форум на chlenomaster.ru

← →
Anatoly Podgoretsky © (2012-05-30 15:17) [93]

> robt (30.05.2012 15:12:31) [91]

Ну то, что автор спамер мы давно знаем.

← →
TUser © (2012-05-30 16:12) [94]

ООП надо использовать всегда, когда требуется делать одно и тоже действие с несколькими типами объектов, но по-разному. Например, есть у нас больной. Его можно ЛЕЧИТЬ. Но лечить его можно по-разному, это зависит от его БОЛЕЗНИ. Функционально мы бы написали так:

if Больной.БОЛЕЗНЬ = БОЛЕЗНЬ_1 then
Есть таблетку 1
Пить микстуру 2
else
if Больной.БОЛЕЗНЬ = БОЛЕЗНЬ_2 then
Капать капли 3
Есть таблетку 4
else
if Больной.БОЛЕЗНЬ = БОЛЕЗНЬ_3 then
Убить себя ап стену, это не лечится

Если болезней будет эдак много, то будет длинный говнокод. Теперь представим себе, что этот код может встречаться в разных местах и в разных ситуациях. И, допустим, травмпункт должен проверить поступившему БОЛЬНОМУ 100 переломов и прочее, а кардиолог - 100 своих болячек. Опыт показывает, что не то, что модифицировать, - написать такой код - настоящая проблема даже для неглупых людей.

Тогда неглупые люди делают ООП. Вводится тип БОЛЬНЫЕ. Который умеет Пить, Есть, Капать и Убиваться. И еще известно, что все они умеют это делать в правильном порядке, который назвыается, допустим, Лечить.

Далее в каком-нибудь отдельном месте выписываем эти рефепты для каждого больного типа-наследника.

После чего, лечить больных очень просто:
БОЛЬНОЙ.Лечить;

← →
Компромисс © (2012-05-30 16:17) [95]

TUser © (30.05.12 16:12) [94]

Тут классы не нужны, нужны интерфейсы :)

http://ru.wikipedia.org/wiki/Посетитель_(шаблон_проектирования)

← →
robt (2012-05-30 18:43) [96]

> TUser © (30.05.12 16:12) [94]

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

← →
Ку (2012-05-30 20:03) [97]

Говорили-говорили... и хоть бы кто-нибудь взял бы, да подправил определение в Википедии.

P.S. Я, впрочем, не лучше... )))

← →
Макс Черных (2012-05-30 21:39) [98]

> ООП это просто удобно в процессе написания программы.

Верная мысль. Это понимают многие, немногие понимают - почему. Судя по странному обсуждению выше.

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

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

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

> Говорили-говорили... и хоть бы кто-нибудь взял бы, да подправил
> определение в Википедии.

Так ведь нет единого мнения, у каждого на этот счет свое субъективное понимание. Проще уж совсем удалить)

> каким образом твой метод лечить будет работать?

Лечить он будет так же. А министру здравоохранения, ну или главврачу поликлиники, работать будет проще. Говори каждому - Лечись, и делов-то.

← →
robt (2012-05-30 22:35) [102]

> TUser © (30.05.12 22:17) [100]

ну так пишеш просто функцию "лечить" с входным параметром "пациент" типа запись и получаеш результат типа перечисления "излечен\умер\сталкалекой\вкоме"
и главврачу также просто работать ибо пациент.лечить=лечить(пациент)
масло масляное

> robt (30.05.12 22:35) [102]

Все можно написать без ООП, да и вообще на асме )) ООП оно не потому чтотолько так можно, а потому что так проще.

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

Это если не под микроконтроллеры пишешь :)

> Макс Черных (30.05.12 21:39) [98]

> Более того, сам человек как биологический вид есть нич то
> иное как ООП объект написанный программистом "Эволюция".
> Ну или Богом, кому что нравится.

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

← →
Макс Черных (2012-05-31 00:38) [106]

Ega23 © (30.05.12 22:37) [104]
> Это если не под микроконтроллеры пишешь :)

Как сказать. Обрати внисание на слова "когда есть возможность".
В свое время и ОС писали без ООП, а нынче с ростом производительности микроконтроллеров и немерянного увеличения их памяти происходит постепенный, но явный переход на использование языков высокого уровня и ООП и для них. Ну, кроме совсем уж "микромозгов", типа PIC и т.д.

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

Собственно, это ни что иное, как принцип "подобное в подобном". В данном случае - классическое кодирования первой производной некой функции. Более того, этот пример отлично демонстрирует тот факт, что сжатие данных придумали вовсе не программисты. :) Как и кодирование данных, впрочем.
Мне в свое время знающие люди грузили и приводили примеры, того, что очень многие вещи вовсю используются в природе, причем давным давно. Ну там: золотые сечения, графы, ООП, эффект масштаба, различные оптимизации (линейная и т.п.), алгоритмы предсказания событий на основе анализа предыдущих, резервирование как данных, так и узлов, "кэш" память разного уровня, оптимизация био-механических систем не достижимая даже при нынешнем уровне науки и т.д. и т.п.

Фокус в том, что человек, как продукт эволюции, сам создал системы которые эволюционируют. Теория сложных систем рулит. А ООП - лишь продукт эволюции средств програмирования. Эволюционируют компьютеры, телевизоры, машины и все остальное. И опять таки, фокус в том, что они эволюционируют как бы сами по себе. Люди выступают тут как "батарейки" - как некая "энергия" процесса.
Кто вот мог 5 лет назад представить нынешнее бешенное внедрение планшетов? Да никто.
Рано или поздно, как бы не дошло до того, что появится нечто рукотворное способное эволюционировать без участия людей. Тогда уже не до ООП будет, а возможно все будут озабочены шейными позвонками, т.е. сохраненим оных в целости и сохранности. :)

> Loginov Dmitry © (29.05.12 21:50) [27]
Инкапсуля́ция — свойство языка программирования, позволяющее пользователю не задумываться о сложности реализации используемого программного компонента
слёзы градом)) - http://ru.wikipedia.org/wiki/%C8%ED%EA%E0%EF%F1%F3%EB%FF%F6%E8%FF_%28%EF%F0%EE%E3%F0%E0%EC%EC%E8%F0%EE%E2%E0%ED%E8%E5%29
как бы это сфотографировать и куда -нибудь выложить для поржать)..

> Макс Черных (31.05.12 00:38) [106]
>
> Ega23 © (30.05.12 22:37) [104]
> > Это если не под микроконтроллеры пишешь :)
>
> Как сказать. Обрати внисание на слова "когда есть возможность".
>
> В свое время и ОС писали без ООП, а нынче с ростом производительности
> микроконтроллеров и немерянного увеличения их памяти происходит
> постепенный, но явный переход на использование языков высокого
> уровня и ООП и для них. Ну, кроме совсем уж "микромозгов",
> типа PIC и т.д.
>
>
Пока такой тенденции не заметил.

> Макс Черных (30.05.12 21:39) [98]
> ООП подход гораздо ближе к естественному ходу мысли

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

> TUser (30.05.2012 22:36:43) [103]

Ты так пишешь, как будто в асм нет ООП

> alexdn (31.05.2012 02:03:47) [107]

Это абстракция

Макс Черных (30.05.12 21:39) [98]
Юрий Зотов © (31.05.12 05:16) [109]

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

← →
robt (2012-05-31 11:12) [113]

> Все можно написать без ООП, да и вообще на асме )) ООП оно
> не потому чтотолько так можно, а потому что так проще.

да почему проще то ??? все тоже самое...
если есть готовая либа повторно используемого кода (VCL,MFC), то пофигу как она написана, с ООП или набором функций, она в любом случае одинаково удобней чем писать самому с нуля
также если писать эту либу самому, с нуля,то это одинаково геморно как для ООП ,так и для набора функций

robt (31.05.12 11:12) [113]
Вы рассматриваете ООП только как контейнер для хранения пакета методов.

> Тогда неглупые люди делают ООП. Вводится тип БОЛЬНЫЕ. Который
> умеет Пить, Есть, Капать и Убиваться. И еще известно, что
> все они умеют это делать в правильном порядке, который назвыается,
> допустим, Лечить.
>
> Далее в каком-нибудь отдельном месте выписываем эти рефепты
> для каждого больного типа-наследника.
>
> После чего, лечить больных очень просто:
> БОЛЬНОЙ.Лечить;

Сдаётся мне, что сущность БОЛЕЗНЬ была бы намного полезнее. Потому что тогда БОЛЬНОЙ.Лечить() - это просто цикл по свойству-массиву БОЛЕЗНЬ.Лечение[], безо всяких if"ов и case"ов.

> ProgRAMmer Dimonych (31.05.2012 11:42:55) [115]

Пациент.Болезнь.Лечить, может даже Болезнь(I) и ДеньгиЕсть?

На примере болезней становится заметно, чем ООП принципиально отличается от процедурного подхода: сколько людей - столько и мнений :)

Я бы, например, использовал иерархию болезней, у каждой болезни был метод лечить(больной), врач умел бы ставить диагноз (врач.получитьДиагноз(больной):Collection<Болезнь>), а потом бы уже сам больной решал, хочет ли он пробежать по этой коллекции и вызвать метод болезнь.лечить(маскимальныеДеньгиНаЛечениеБолезни) в зависимости от болезнь.получитьВероятностьСмерти и болезнь.получитьВероятностьВыздоровления(маскимальныеДеньгиНаЛечениеБолезни). Про иерархию врачей и иерархию больных и так понятно... В общем, чтобы внести простейшие изменения в программу третьим лицам пришлось бы неделю потратить на изучение иерархий и взаимодейсивя объектов :)

← →
robt (2012-05-31 12:42) [119]

> Вы рассматриваете ООП только как контейнер для хранения
> пакета методов.

а это так и есть и везде описано :) я его расматриваю как дурь, которую черезчур обожествляют и засирают и так пустой мозг батонокидателей

robt (31.05.12 12:42) [119]

Если нет иерархии объектов, то согласен. Но обычно она есть...

Ужасть, как всё усложнили, и это в ответ-то на [0]

А аФФтору, просто, предлагаю написать простейший многооконный текстовый редактор без использования объектов на borland pascal 5.0 и с использованием оных на borland pascal 5.5. И сразу основы ооп будут понятны.

robt (31.05.12 12:42) [119]
Ну, а я рассматриваю как [18] и не вижу как [18] можно решить без ООП.
можно конечно но громоздко.

Внес правки в статью, по-моему лучше стало

http://ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%BA%D0%B0%D0%BF%D1%81%D1%83%D0%BB%D1%8F%D1%86%D0%B8%D1%8F_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)

Как-то однажды знаменитый учитель Кх Ан вышел на прогулку с учеником Антоном. Надеясь разговорить учителя, Антон спросил: "Учитель, слыхал я, что объекты - очень хорошая штука - правда ли это?" Кх Ан посмотрел на ученика с жалостью в глазах и ответил: "Глупый ученик! Объекты - всего лишь замыкания для бедных."

Пристыженный Антон простился с учителем и вернулся в свою комнату, горя желанием как можно скорее изучить замыкания. Он внимательно прочитал все статьи из серии "Lambda: The Ultimate", и родственные им статьи, и написал небольшой интерпретатор Scheme с объектно-ориентированной системой, основанной на замыканиях. Он многому научился, и с нетерпением ждал случая сообщить учителю о своих успехах.

Во время следующей прогулки с Кх Аном, Антон, пытаясь произвести хорошее впечатление, сказал: "Учитель, я прилежно изучил этот вопрос, и понимаю теперь, что объекты - воистину замыкания для бедных." Кх Ан в ответ ударил Антона палкой и воскликнул: "Когда же ты чему-то научишься? Замыкания - это объекты для бедных!" В эту секунду Антон обрел просветление.

← →
robt (2012-05-31 13:59) [125]

> stas © (31.05.12 13:15) [122]

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

> Если нет иерархии объектов, то согласен. Но обычно она есть.

ичо меняеца если она есть

robt (31.05.12 13:59) [125]
Это в продолжении [17] при условии что они наследники объекта1

← →
robt (2012-05-31 14:27) [127]

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

> [117] Компромисс © (31.05.12 12:06)
> На примере болезней становится заметно, чем ООП принципиально
> отличается от процедурного подхода

Процедурный кабинет не зря в стационарах делают и в поликлинниках вроде бы тоже.

> в техже винапишных функциях есть параметры записи переменного
> размера в зависимости от версии,что можно интерпретировать
> как наследование

а винапишная функция имеет код типа
if(version==N){
...
} else if (version==M){
...
}

?

> [129] Компромисс © (31.05.12 14:40)

Зато если положить туда не длину, а адрес процедуры - вот это будет самый что ни на есть виртуальный метод. С наследованием и структурами.

← →
robt (2012-05-31 15:01) [131]

> Компромисс © (31.05.12 14:40) [129]

не по другому,"версию" определяет размер структуры записаный первым,а по смещению работаеца с полями

ProgRAMmer Dimonych © (31.05.12 14:49) [130]

> Зато если положить туда не длину, а адрес процедуры - вот
> это будет самый что ни на есть виртуальный метод. С наследованием
> и структурами.

Только вот не должен клиент передавать адрес процедуры, не его это дело. Максимум, что можно передать - это указатель на тип параметра. А адрес процедуры должен быть где-то в другом месте, например в вирутальной таблице. В итоге получим кустарный объект.

← →
Макс Черных (2012-06-01 01:49) [133]

> но объектно мы все-таки не мыслим, во всяком случае, на
> абстрактном уровне, без конкретных реализаций.

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

Человек соображает именно абстрактно. А вот разделяет эти абстрактности, естественно, по признакам, в т.ч. и по реализации. Более того, человек (да и не только) может эти признаки обобщать и проецировать на подобия (наследование объектов).

Кто хочет погрузиться более, можно погуглить

про existential types, Abstract Data Type(ADT)

http://fprog.ru/2010/issue4/roman-dushkin-existentials/
http://en.wikipedia.org/wiki/Abstract_data_type
http://www.haskell.org/haskellwiki/Existential_types

> [132] Компромисс © (31.05.12 15:02)

Это если совсем по-трушному делать. Для небольших задач в качестве компромисса между процедурным и ООП - самое оно. Но вообще я больше с точки зрения того, чтобы на ассемблере такое реализовывать, подходил к вопросу. Ибо на ЯВУ делать свой ООП-велосипед - нафиг.

Макс Черных (01.06.12 01:49) [133]

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

Обратитесь в нобелевский комитет, Вы неопровержимо доказали наличие абстракстного мышления у практически всех животных :)

> Человек соображает именно абстрактно. А вот разделяет эти
> абстрактности, естественно, по признакам, в т.ч. и по реализации.
> Более того, человек (да и не только) может эти признаки
> обобщать и проецировать на подобия (наследование объектов).
>

Человек скорее мыслит "процедурно": что делать и кто виноват? :)
Кстати, "выпить и закусить" из той же области. Никаких абстракций, только конкретика

Когда нужно использовать ООП? Найти похожие ветки