Здравствуйте, Rumata, Вы писали:
R>Сразу просьба: не кидайте тухлыми овощами. =)
R>Пару месяцев назад задался целью узнать, что такое ООП. Максимум, что получилось — вышел на omg. Но там тоже толком ничего нет. Может быть all сможет показать мне четкую формулировку, что же такое этот самый ООП =)
Обратимся к гигантам мысли, итак
В 1988 году Бьярн Страуструп, автор Си++ (Bell Lab) говрит следующее:
"Объектно-ориентированное программирование" - это средство, парадигма для
написания "хороших программ".
Тогда-же он объясняет термин "хорошая программа":
Допускает повторное использование для разработки других программ.
Расширяема, т.е. требует минимальных затрат на перепрограммирование при внесении дополнительных свойств или модификации существующих.
Надежна.
Мобильна, т.е. подразумевает минимальные затраты при переносе на другие платформы.
Дешева. Затраты на реализацию проектов бывают столь высоки, что порой от них приходится просто отказываться. Принципы ООП представляют лучший из известных ответов на вопрос "как писать хорошие программы?"
В 1989 году Bertrand Meyer, автор книги Object-Oriented Software Construction(Prentice-Hall) дает определение ООП:
"Объектно-ориентированный дизайн - это построение программных систем как
структурированных наборов реализаций абстрактных типов данных".
Основная мысль заключается в построении (разработке) программы из классов объектов, которыми она манипулирует, а не из функций, которые над ними (объектами) выполняются. Под классом подразумевается реализованный абстрактный тип данных, а под объектом — конкретные данные, т.е. экземпляр данного типа (класса). Что касается функций, то они определяются свои — над каждым типом данных, при этом сами данные (объекты) оказываются доступными только через эти функции, составляющие официальный интерфейс данного класса, другими словами, реализация типа полностью скрыта (инкапсуляция).
Здравствуйте, Sergey, Вы писали:
S>А как предполагается записывать эту самую математическую модель? Уж не на языке ли программирования каком-нибудь? Это я к тому, что программист эту математическую модель сам придумывает.
Ну почему же, я вот верю, что математика в конце концов опишет все =)
Дело в том, что я сначаала начал пользоваться реляционными бд (в т.ч. и нормальными формами), а потом прочитал теорию, почему нормальные форму лучше, чем ненормальные. С тех пор мне кажется, что за любым "rule of thumb", которое на практике облечает программисту жизнь лежит некоторое математическое обоснование =)
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Rumata, Вы писали:
WH>>Это означает что красивость кода тоже важна. R>>Э-э-э ну а я собственно говорю, что красивость хоть и приятна, но не так уж важна по большому счету.
AVK>Важна, еще как важна. Красота кода это оборотная сторона утилитарности. Код это не дом или автомобиль, в процессе своей жизни код непрерывно эволюционирует. И если он написан некрасиво то жизнь такого кода будет тяжелой и недолгой.
Ну здесь на самом деле можно долго спорить, т.к., например, что такое красота кода? Где-то недавно пробегала тема про что-то вроде $f = $f & func(); Кому-то это кажется красивым и удобным, кому-то — некрасивым и неудобным. Но в общем, я с Вами все-таки согласен — мне красивый код тоже нравится больше, чем некрасивый, хотя, если он работает — это не так уж важно. =)
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Rumata, Вы писали: R>>Вот только опять не понятно, являются ли приведенные там документы какими-либо стандартами. неужели за более чем 10 лет развития, под ООП не подвели никаких признаных стандартов вообще? S>В каком смысле стандартов? Стандартов математизации? А такие вообще есть? У нас хоть одна область математики оборудована каким-то стандартом? Или физика там? "Комитет ISO постановил пользоваться Гейзенберговским представлением квантовых операторов, так как оно наилучшим образом удовлетворяет потребности всех заинтересованных сторон". Все. Обновляем все учебники со Шредингеровским представлением. Ха-ха-ха. S>Нет, на эту область стандартов нет и не будет. Если достаточное количество народу будет задумываться что и почему они делают, а не как добиться конкретной фичи, то есть шанс сформировать более-менее общепринятую терминологию. Пока что ООП находится примерно в той же стадии исследования, что и экономика — каждый автор свободно использует термины в своем смысле, и зачастую не в одном.
Тут я ну никак не могу с Вами согласиться. Математика строит модели реальной жизни. Раз есть реальная жизнь, будет и модель. Ту же экономику потихоньку описывают с разной точностью. А программирование все-таки чуть более структурированная штука. Из-за того, хотя бы, что в конце концов программа должна работать на машине фон-Неймана, которая очень даже хорошо описана.
А пока, как я понял, даже с терминологией не договорились. =((
Здравствуйте, Аноним, Вы писали:
А>Стандартов нет, но если нужны теории — то изучайте дискретную математику и абстрактную алгебру, а именно: теорию графов, теорию конечных автоматов, мат. лог, алгебру логики, сложность алгоритмов, А>теорию структур, формальные языки, распознавание образов и т.д.
Изучаю. А вот курса ооп у нас вроде как не намечается. Похоже, что нам покажут c++, скажут, что в нем бывают объекты и на этом все закончится =)
Здравствуйте, Rumata, Вы писали:
R>Тут я ну никак не могу с Вами согласиться. Математика строит модели реальной жизни. Раз есть реальная жизнь, будет и модель. Ту же экономику потихоньку описывают с разной точностью.
А программирование тоже в конечном итоге описывает реальную жизнь, как это не парадоксально.
Здравствуйте, mihailik, Вы писали:
M>P.S. Хотя, на сегодняшний день, самым классическим и строгим стандартным языком ООП-программирования можно считать Java. Его всякая научная общественность в институтах массово изучает, и на его основе всякое ООП проходят. Имеются ввиду, конечно, западные институты. Наши пока в программировании не авторитет.
Я бы не был столь категоричен. В джаве очень много моментов не очень хорошо ложащихся в ОО-парадигму. Ну те же примитивные типы к примеру.
Здравствуйте, Rumata, Вы писали:
R>Ну здесь на самом деле можно долго спорить, т.к., например, что такое красота кода?
Лично я считаю красивым код, который легко понять, который не содержит в себе повторяющихся кусков и который решает задачу путями, близкими к оптимальным.
R>Где-то недавно пробегала тема про что-то вроде $f = $f & func(); Кому-то это кажется красивым и удобным, кому-то — некрасивым и неудобным. Но в общем, я с Вами все-таки согласен — мне красивый код тоже нравится больше, чем некрасивый, хотя, если он работает — это не так уж важно. =)
Все таки настаиваю на том что важно. Потмоу что зачастую проще бывает переписать код заново, нежели модифицировать старый.
Здравствуйте, AndrewVK, Вы писали:
AVK>Я бы не был столь категоричен. В джаве очень много моментов не очень хорошо ложащихся в ОО-парадигму. Ну те же примитивные типы к примеру.
Однако в ней есть оболочки для этих типов, никто не мешает использовать только их, вместо int использовать Integer и т.д.
R>... Кто-то решил, что их должно быть 3, т.к. это "следует из инкапсуляции". Но, т.к. понятие самой инкапсуляции, как я понимаю, само четко не сформулировано, следствия из него имхо строить довольно опасно.
Инкапсуляция — это доступность (или сокрытие) того, что имеет объект, для кого-либо, отличного от самого объекта.
Количество состояний доступности определяется тремя словами "никому", "одному" и "всем". Если ты сможешь найти еще слово, которое не выражается из этих трех, то тебе будет слава и почет.
R>А пока, как я понял, даже с терминологией не договорились.
Интересно, есть ли определение точки, множества и т.п. терминов, краеугольные для математики? Которые вроде всем известны и понятны, но тем не менее...
Здравствуйте, Vi2, Вы писали:
Vi2>Количество состояний доступности определяется тремя словами "никому", "одному" и "всем". Если ты сможешь найти еще слово, которое не выражается из этих трех, то тебе будет слава и почет.
Я знаю! "Двум"! Но это избыточно, так как помимо инкапсуляции у нас есть ещё и наследование. вот если инкапсуляция есть, а наследования нет....
Тогда ЛЮБОЙ экземпляр класса В может обращаться к скрытым(приватным) членам любого экземпляра класса А, но ни один из них не наследуется от другого и они не являються потомками одного и того же класса. Пока же мы пишем Get|Set методы. Я неговорю, что это надо, я говорю, что этого нет.
ИМХО не надо, в том смысле что если и надо то редко и не очень.
Здравствуйте, Dmitry123, Вы писали:
AVK>Я бы не был столь категоричен. В джаве очень много моментов не очень хорошо ложащихся в ОО-парадигму. Ну те же примитивные типы к примеру.
D>Однако в ней есть оболочки для этих типов, никто не мешает использовать только их, вместо int использовать Integer и т.д.
Ты сам то использовал? Мне до сих пор иногда в кошмарных снах снится кое какой код из EJB на эту тему.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Dmitry123, Вы писали:
AVK>>Я бы не был столь категоричен. В джаве очень много моментов не очень хорошо ложащихся в ОО-парадигму. Ну те же примитивные типы к примеру.
D>>Однако в ней есть оболочки для этих типов, никто не мешает использовать только их, вместо int использовать Integer и т.д.
AVK>Ты сам то использовал? Мне до сих пор иногда в кошмарных снах снится кое какой код из EJB на эту тему.
В Jave 1.5 будет boxing/unboxing . Правда, только для примитивных типов.
7. О чем невозможно говорить, о том следует молчать.
A>Ну да, представь себе приблизительно такую запись
A>class B;
A>friend B class A;
A>Тогда ЛЮБОЙ экземпляр класса В может обращаться к скрытым(приватным) членам любого экземпляра класса А, но ни один из них не наследуется от другого и они не являються потомками одного и того же класса. Пока же мы пишем Get|Set методы. Я неговорю, что это надо, я говорю, что этого нет.
A>ИМХО не надо, в том смысле что если и надо то редко и не очень.
Сколько ни вчитывался, никак не мог понять тезиса, против которого или за который ты высказываешься.
Тройственная (триединая) картина встречается достаточно часто, чтобы она стала каноном. Триединый бог, Отрицание отрицания и т.п. (Иногда даже — если в теории нет триединства, то считается, что теория ущербна. )
На практике, например, некая Фирма может заключать договор 1) ни с кем, 2) с определенным лицом, 3) с неопределенным лицом (публичный договор).
Здравствуйте, Vi2, Вы писали:
Vi2>На практике, например, некая Фирма может заключать договор 1) ни с кем, 2) с определенным лицом, 3) с неопределенным лицом (публичный договор).
4) С несколькими определёнными лицами.
Например множественное наследование это канон ООП или фича?
. Правда, только для примитивных типов.
)
