Ответ на »сообщение 3719« (al_mt)
___________________________

Скажите, вам понятно, что в ООП исполнение кода ведется в рамках контекста иерархии классов? Что делегируются действия (обработка сообщений)? Что глядя в конкретное место исходного текста нельзя сразу понять, что же делается, пока не выявишь взаимосвязь между классами и привнесенное в ОО-слои доопределение/переопределение функций обработки?

Я так понял, что здесь собственно осуждается эта самая "рамка контекста", т.е. "скрытность" ООП кода.
Я что не так понял??
Или Вы отрицаете саму идею контекста?

1. Неучтиво отвечать вопросом на вопросы.
2. Прочитайте внимательно все сообщения с самого начала дискуссии (начинайте прямо от Дейкстры).
3. Я формулировал тезис о том, что ООП обладает дополнительными "степенями свободы" по отношению к модульному программированию -- наследованием и полиморфизмом. Эта дополнительная гибкость при прочих равных условиях является дополнительным источником ошибок.
4. Локализация эффекта воздействия изменений в ОО-системе сложнее, чем в МП-системе (МП -- модульное программирование), из-за врожденного в у ООП делегирования функций обработки сообщений (пресловутого ОО-контекста). Это приводит к потере контроля над системой (ее сложностью).
5. ООП -- парадигма, доказавшая свою полезность и практичность, но я против ее диктатуры.

Ответ на »сообщение 3717« (Руслан Богатырев)
___________________________
Цитата:

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

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

Руслан сказал:

Скажите, вам понятно, что в ООП исполнение кода ведется в рамках контекста иерархии классов? Что делегируются действия (обработка сообщений)? Что глядя в конкретное место исходного текста нельзя сразу понять, что же делается, пока не выявишь взаимосвязь между классами и привнесенное в ОО-слои доопределение/переопределение функций обработки?

Я так понял, что здесь собственно осуждается эта самая "рамка контекста", т.е. "скрытность" ООП кода.
Я что не так понял??
Или Вы отрицаете саму идею контекста?

Если Владимир данных взглядов не разделяет, а наоборот, извини :) значит это только к Руслану относится.

Ответ на »сообщение 3711« (Владимир Лось)
Кстати, а откуда взялся термин "кошачий пастух"?

http://www.books.ru/shop/books/309225

Ответ на »сообщение 3713« (al_mt)
___________________________

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

Хороший индикатор дискуссии. Такая игра называется "нанайские мальчики". Объяснить или понятно?

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

Прости, о чем мы говорим? Вы правда не понимаете или делаете вид?

Если не затруднит, ответьте на два вопроса:

1. Что такое модуль (в вашем понимании)?
2. С какими языками модульного программирования (не поддерживающими ООП) вы работали?

Вопросы несложные.

Ответ на »сообщение 3705« (al_mt)
___________________________


y:=sin(x);
Ву компре?

Вы имели в виду вызов стандартной функции sin, передачу ей в качестве аргумента переменной x и присваивание результат переменной y?

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

Рассмотрим два языка модульного программирования: Modula-2 и Оберон (в контексте нашего форума).

В Modula-2 мои действия будут следующими (варианты "обхода" могут быть разными):

1. Посмотреть DEFINITION-модуль и выяснить, является ли sin экспортируемой процедурой-функцией. Если да, смотрим в IMPLEMENTATION на реализацию функции (это нам интересно на предмет возможного оказания воздействия на другие модули системы при ее изменении).

2. Посмотреть список неквалифицирующего импорта (FROM ... IMPORT) в начале IMPLEMENTATION-модуля. Если нашли, смотрим, из какого модуля импортируется, его DEFINITION, где указано, что она делает (а вдруг не вычисляет синус, а делает что-то другое).

3. Если поиск по пунктам 1 и 2 закончился неудачей, значит, функция sin реализована в IMPLEMENTATION данного модуля и при этом не экспортируется. Находим реализацию этой функции. Видим, что она делает.


В Обероне мои действия будут следующими:

1. Функция sin не является встроенной функцией языка и не может при такой записи импортироваться, тогда была бы запись вида y := Math.sin(x) с явным указанием имени модуля (неквалифицирующего импорта в Обероне нет). Значит, эта функция sin реализована только внутри данного модуля. Ищем реализацию функции в данном модуле. Видим, что она делает.

2. Чтобы оценить эффект воздействия при возможном изменении смотрим, есть ли у имени процедуры-функции при ее реализации признак импорта (звездочка). Если есть, значит экспортируется (и где-то снаружи используется).

Все очень просто.

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

Нет, ну мне это нравится!
Тут наверное яростнее сторонника ПОЛНОГО СОКРЫТИЯ исходного кода от клиентов компонентов, чем я не найти и вдруг появляется al_mt и на белом глазу вываливает прямо противоположное утверждение!
Для вас повторяю, что по моим взглядам, компоненты должны быть полностью бинарными (ну, может быть в байт-коде, обероновских слимах, инферновских dis-ах...) и предоставлять наружу только строго оговоренный интерфейс (каким уже способом - вотрой вопрос).

Ответ на »сообщение 3713« (al_mt)
___________________________
Прозвучало разделяемое Владимиром и Русланом утверждение, что "ООП скрывает часть кода от разработчика и это плохо"

ГДЕ ЭТО У МЕНЯ БЫЛО ?????!!!!!
Или вы сами с сиобой дискуссию ведёте? :о)

ОК. Положите булыжники с иероглифами на место - не будем разорять могилки, вернёмся к конкретике:

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

Было такое утверждение? Все согласны и готовы поддержать?

p.s. Только просьба, если кто-то желает развернуть мысль, то играем в "50 слов".

Ответ на »сообщение 3709« (al_mt)
___________________________
Если Вы работаете с готовой библиотекой классов, то у Вас УЖЕ скомпонован глобальный контекст, в котором Вы УЖЕ можете работать со всеми включенными типами, и разумеется видимости УЖЕ на месте.
Вы же не будете утверждать, что предпочли бы для каждого проекта начинать разработку с проектирования процессора?

А об этом речи никто и не вёл.

Было проиллюстрировано понятие контекста исполнения "по умолчанию" в рамках ООП-подхода, если вам угодно...