Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];

Вниз

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

 
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]


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

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

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

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

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


 
Loginov Dmitry ©   (2012-05-30 22:11) [99]


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


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


 
TUser ©   (2012-05-30 22:17) [100]


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

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


 
Inovet ©   (2012-05-30 22:20) [101]

> [99] Loginov Dmitry ©   (30.05.12 22:11)
> Проще уж совсем удалить)

Проще совсем не писать ничего никуда.


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


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

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


 
TUser ©   (2012-05-30 22:36) [103]


> robt   (30.05.12 22:35) [102]

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


 
Ega23 ©   (2012-05-30 22:37) [104]


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


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


 
картман ©   (2012-05-30 23:29) [105]


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


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

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


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

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

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


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

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

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


 
alexdn ©   (2012-05-31 02:03) [107]

> Loginov Dmitry ©   (29.05.12 21:50) [27]
Инкапсуля&#769;ция — свойство языка программирования, позволяющее пользователю не задумываться о сложности реализации используемого программного компонента
слёзы градом)) - 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
как бы это сфотографировать и куда -нибудь выложить для поржать)..


 
Германн ©   (2012-05-31 02:45) [108]


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


 
Юрий Зотов ©   (2012-05-31 05:16) [109]


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

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


 
Anatoly Podgoretsky ©   (2012-05-31 06:40) [110]

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

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


 
Anatoly Podgoretsky ©   (2012-05-31 06:44) [111]

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

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


 
Компромисс ©   (2012-05-31 10:06) [112]

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

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


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


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

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


 
stas ©   (2012-05-31 11:40) [114]

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


 
ProgRAMmer Dimonych ©   (2012-05-31 11:42) [115]

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

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


 
Anatoly Podgoretsky ©   (2012-05-31 11:57) [116]

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

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


 
Компромисс ©   (2012-05-31 12:06) [117]

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

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


 
ProgRAMmer Dimonych ©   (2012-05-31 12:41) [118]

> [117] Компромисс ©   (31.05.12 12:06)

Документировать надо


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


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

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


 
Компромисс ©   (2012-05-31 12:54) [120]

robt   (31.05.12 12:42) [119]

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



Страницы: 1 2 3 4 вся ветка

Форум: "Прочее";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.71 MB
Время: 0.116 c
2-1348424060
buddypetrovich
2012-09-23 22:14
2013.03.22
serversocket1 vs clientsocket1


15-1335792488
Knight
2012-04-30 17:28
2013.03.22
Триггер в FireBird


15-1330983917
osoed
2012-03-06 01:45
2013.03.22
Из DLL Visual Studio в DLL Delphi7


2-1333473036
Usver
2012-04-03 21:10
2013.03.22
Перевод с C++ на Delphi


2-1334405334
lord827
2012-04-14 16:08
2013.03.22
межпоточная защита данных





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский