Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.216.94.152] |
|
Страницы: (21) 1 [2] 3 4 ... 20 21 ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
P.S. В статье как раз вот такая игра на смыслах понятий и происходит. Если намеренно, то автор троль, если нет, то просто нуб в ООП.
Добавлено Хочешь, чтобы я процитировал классиков? А вот хрен, и сам сможешь. ООП является технологией, расширяющей рамки структурного подхода и избавленной от его недостатка невозможности его реализовать в полной мере на практике. Ни один язык структурного программирования не может предоставить программисту полный спектр нужных для этого грамматических конструкций, чему причиной является то, что для этого в общем случае потребуется бесконечно много типов грамматических конструкций. ООП эту проблему решает. К примеру, на C, ты ограничен разбиением программы на единицы трансляции, взаимодействующие между собой через публичные имена, те в свою очередь на функции, взаимодействие между которыми осуществляется через параметры, и... и на этом всё. Сокрытие реализаций осуществляется на первом уровне через статические имена, на втором – тоже статические и локальные. Всё. Иерархия всего из двух уровней. Если исходная задача такова, что двух уровней её разбиения на подзадачи хватит, то структурный подход в C прекрасно справится с её представлением. Увы, 2 уровня уже давно не хватает, поэтому начинаются костыли в лице логического выделения уровней иерархии подзадач без отображения на структуру кода. В ООП понятие класса искаропки позволяет иметь бесконечное количество уровней. Другими словами, уже C с классами позволял отображать структуру исходной сложной задачи на иерархию подзадач явным образом и без костылей. |
Сообщ.
#17
,
|
|
|
Цитата Qraizer @ Ни один язык структурного программирования не может предоставить программисту полный спектр нужных для этого грамматических конструкций, чему причиной является то, что для этого в общем случае потребуется бесконечно много типов грамматических конструкций. ООП эту проблему решает. В лиспах это делается довольно легко и непринуждённо. Цитата Qraizer @ К примеру, на C А, ты про эти языки… |
Сообщ.
#18
,
|
|
|
Цитата Qraizer @ Хочешь, чтобы я процитировал классиков? Вроде как про определение(общепринятое и желательно формальное) ООП речь шла, а не про мнения. |
Сообщ.
#19
,
|
|
|
Раз уж холивары, то:
Цитата In the article Is Software Engineering an Oxymoron?, Kay writes: "Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late binding in all aspects." While this doesn't necessarily constrain the definition of OO in his mind, it is a key statement of philosophy. C++, of course, does early binding everywhere it can--up to the point of performing StaticDispatch as a default (you have to ask for DynamicDispatch with the "virtual" keyword when you want it. [and even that, as in many other languages like Java, is only single dynamic dispatch. If you want "late binding everywhere," you need a much more powerful dispatch system, e.g. CommonLispObjectSystem's generics]). — http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented =) Добавлено А это так, развлечения ради: http://lucacardelli.name/Papers/PrimObjImpSIPL.A4.pdf http://lucacardelli.name/Papers/PrimObj1stOrder.A4.pdf =) |
Сообщ.
#20
,
|
|
|
Сообщ.
#21
,
|
|
|
Цитата Qraizer @ Классики сами путаются в определениях. Хочешь, чтобы я процитировал классиков? |
Сообщ.
#22
,
|
|
|
Цитата korvin @ If you want "late binding everywhere," you need a much more powerful dispatch system, e.g. CommonLispObjectSystem's generics Только вот это - не панацея и может иметь свои недостатки. Но тут уже начнётся холивар в стиле "статическая типизация vs динамическая типизация". К слову, C++ хорош именно тем, что позволяет ещё на этапе компиляции проверять большое количество констрейнтов, связанных с типами и связыванием, облегчая тем самым задачи рантайма. Впрочем, те, кто любят ловить на страницах undefined object'ы, на этот счёт другого мнения. |
Сообщ.
#23
,
|
|
|
Flex Ferrum, а ООП тут при чем?
|
Сообщ.
#24
,
|
|
|
Цитата D_KEY @ Flex Ferrum, а ООП тут при чем? При том же, при чём цитата Корвина. Это не ко мне вопрос. |
Сообщ.
#25
,
|
|
|
Flex Ferrum, а ты как определяешь ООП?
|
Сообщ.
#26
,
|
|
|
Цитата D_KEY @ а ты как определяешь ООП? Как подход к проектированию и декомпозиции программных систем. А на каком языке и как это будет реализовано - уже второй вопрос. То есть для меня дискуссия об ООП - это не дискуссия о языках, его так или иначе реализующих. Добавлено Популярная сейчас микросервисная архитектура - это то же ООП, вид в профиль. |
Сообщ.
#27
,
|
|
|
Цитата Flex Ferrum @ Цитата D_KEY @ а ты как определяешь ООП? Как подход к проектированию и декомпозиции программных систем. А на каком языке и как это будет реализовано - уже второй вопрос. То есть для меня дискуссия об ООП - это не дискуссия о языках, его так или иначе реализующих. Добавлено Популярная сейчас микросервисная архитектура - это то же ООП, вид в профиль. Задам хитрый вопрос - исходя из того, что ты сказал, что будет НЕ являться ООП? |
Сообщ.
#28
,
|
|
|
Цитата Астарот @ Задам хитрый вопрос - исходя из того, что ты сказал, что будет НЕ являться ООП? То, что дизайнится без применения ОО-подхода. Очевидно же! |
Сообщ.
#29
,
|
|
|
Цитата Flex Ferrum @ Как подход к проектированию и декомпозиции программных систем. который заключается в ... В чем? Добавлено Цитата Flex Ferrum @ Популярная сейчас микросервисная архитектура - это то же ООП, вид в профиль. А акторы? |
Сообщ.
#30
,
|
|
|
Цитата Астарот @ Ответ очевиден: то что не использует ООЗадам хитрый вопрос - исходя из того, что ты сказал, что будет НЕ являться ООП? Цитата Flex Ferrum @ подход к проектированию и декомпозиции программных систем. Типа ООП это как не ООП, но наоборот. |