OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 11 Декабрь, 2018 22:57

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 11 ] 
Автор Сообщение
 Заголовок сообщения: Модули и классы
СообщениеДобавлено: Четверг, 15 Декабрь, 2005 14:32 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9060
Откуда: Россия, Орёл
На форуме Королевства Дельфи Руслан Богатырев очень хорошо выступил со сравнением концепций модуля и класса, оценкой подхода Б. Мейера к их полному отождествлению, и т.п.:
http://www.delphikingdom.com/asp/talkto ... t=10&pNo=1

Рекомендую почитать.

Свое мнение на эту тему уже высказывал в соседней ветке:
Цитата:
Почему в Java единственной единицей инкапсуляции является класс? Класс - это абстракция из предметной области. А техническое средство для формирования связанного набора из функций, типов, переменных и т.п., с сокрытием некоторых из них - это модуль. Когда пытаются обойтись без модулей и переложить соответствующие обязанности на классы, получается изврат.
Мое мнение - что модули и типы - сущности разные. А разные концепции должны выглядеть и использоваться по-разному. Лучше, когда "суп отдельно, мухи отдельно" При этом это должно закладываться в самой идеологии языка, дабы не было путаницы в головах и необходимости разбираться в наворотах излишне "творческих" писателей программ.

Идея использовать классы вместо модулей мне напоминает знаете что? Когда люди, плохо понимающие ООП, начинают использовать вместо агрегации наследование. Ну раз есть, механизм, то, типа, почему бы не использовать? Аналогично: ну раз можно в классе инкапсулировать типы и процедуры класса, то почему бы не запихать их туда?

Кстати, в ETH (Цюрихском технологическом) идет сейчас борьба между Обероном, который является там стандартным с 1989 года, и Eiffel, который продвигает Мейер.

У Мейера подход к подготовке программистов очень оригинальный: в самом начале предоставлять новичку огромные билиотеки из "черных ящиков" и учить просто их совмещать между собой, как конструктор. Потом понемногу эти "черные ящики" вскрываются, и где-то через год доходят до изучения алгоритмики, то есть, "программирования в малом". Бывает "кидание контролов на форму", а тут "кидание вызовов библиотек".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Четверг, 23 Февраль, 2006 23:27 

Зарегистрирован: Среда, 22 Февраль, 2006 10:35
Сообщения: 144
Откуда: Новочеркасск
В чем основная задача ООП? На мой взгляд - облегчить сопровождение программы. И такие вещи как наследование, полиморфизм и инкапсуляция действительно помогают в этом. Потому что в верно спроектированную ОО-систему всегда не трудно добавить функциональность или внести какие-нибудь другие изменения. Кто-то говорил, что ООП возможно не только на ОО языках. Возможно... но я слабо представляю себе полиморфизм на языке C (Ручное создание таблицы виртуальных функций?!). ОО языки облегчают сам процесс ООП. Основное понятие ООП - объект. (Вернее даже "субъект"). Мы знаем ЧТО он делает , но нам совсем не обязательно знать КАК он делает, если конечно он делает то, что мы от него ожидаем, не больше и не меньше :D
Например, легковой автомобиль. Мы знаем для чего он предназначен, как им управлять, какое топливо покупать, у нас есть даже права, но при этом мы можем и не знать, какие процессы происходят внутри автомобиля. Также не секрет, что автомобиль содержит в себе множество различных деталей, каждая из которых также может состоять из других деталей. Кроме того, детали нашего легкового автомобиля врядли подойдут другим объектам, например нашей стиральной машине или холодильнику. А теперь представим, что мы конструкторы автомобиля...
Прежде чем создать автомобиль нам нужно создать детали, из которых он состоит. И вот тут возникают вопросы... Понятно, что некоторые детали мы можем взять уже готовыми. Если говорить терминами КП - из других модулей. Но некоторые придется делать самим (должен же наш автомобиль чем-то отличаться от других!) Куда разместить эти наши детали? Опять же, если говорить о КП, то тут такие варианты:
1) для каждой детали создаем свой модуль.
2) все детали помещаем в тот же модуль, где находится автомобиль.
В КП второй подход, на мой взгляд, совершенно противоречит ООП, так как детали в автомобиле взаимодействуют между собой. А объекты внутри модуля могут получать доступ к полям друг друга, скорее всего невидимым вне модуля. А детали могут быть совершенно разными. И что произойдет, когда нам придет в голову поменять какую-нибудь деталь?! Конечно, детали внутри модуля могут быть связаны друг с другом только через свои интерфейсы. Они и должны быть связаны друг с другом только через свои интерфейсы!
ООП - фактически ограничение самого себя с помощью компилятора :D А если ограничений нет, то нет и ООП (программирования, проектирование есть). Получается, нам нужно каждую деталь хранить в отдельном модуле. А отдельный модуль с одним экспортируемым типом в КП, чем не класс в С++?
Можно также поместить все схожие по назначению детали в один модуль. Эти детали уж точно никак не будут взаимодействовать между собой (Карбюратор и инжектор внутри одного автомобиля не уживаются :D) Но где гарантия? То есть в этом плане КП ограничивает свободу - правильных решений не много.
Мне кажется, отсутствие инкапсуляции внутри модуля в КП, то есть отсутствие понятия КЛАСС - недостаток КП. Такой же, как отсутствие понятия МОДУЛЬ в С++. Чем плохо, если бы RECORD в КП аналогично CLASS или SCRUCT в С++ имел бы директивы PRIVATE и PUBLIC, действующие внутри модуля тоже?
[/b]


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пятница, 24 Февраль, 2006 00:57 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9060
Откуда: Россия, Орёл
Вашу позицию понял. Вам не нравится то, что внутри модуля нет ограничений доступа. Поэтому возникает желание раскидать все по разным модулям, в результате модули используются не по прямому назначению, вся идеология модульных языков летит куда подальше...

Вы обращаетесь к аналогии с железной техникой - это хорошая аналогия. Только давайте-ка посмотрим немного под другим ракурсом. Пусть мы с вами делаем не сам автомобиль, а программную техническую систему, которая будет управлять виртуальными моделями автомобилей. Так вот, с точки зрения программного инженера Автомобиль, Карбюратор, Бензобак - это не модули, не части технической системы, это всего лишь типы данных, которые обрабатываются. Это - абстракции предметной области. Их можно называть типами, как в КП, можно классами, как во многих других языках. Однако ваша логика предполагает, что разбиение на модули нашей программной системы будет совпадать с разбиением на модули того самого автомобиля, моделированием которого мы занимаемся. Т.е. в программе действует набор таких активных "роботов"-объектов, каждый из которых является эквивалентом объекта реального мира. Подход заманчивый и соблазнительный, но на практике себя часто не оправдывающий. Если модель достаточно сложна, то при реализации классов не удастся игнорировать реализацию окружающих классов из некоторой группы. В том же С++ приходится использовать декларации friend или иные маневры, позволяющие для тесно связанной группы классов обойти инкапсуляцию.

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

А при вашем подходе мы дойдем до абсурда. Вот конкретный пример, прямо из ББ (модуль Dialog). Создаем набор типов для работы с деревом: Tree - само дерево, TreeNode - вершина дерева. Пользователь не имеет никакого понятия о реализации этих типов, для него создается набор общих методов. Теперь приступаем к реализации - и сразу же видим, что эти два типа должны иметь полный доступ к внутренностям друг друга. Если заставить их взаимодействовать между собой через тот же интерфейс, который мы описали для пользователя, мы получим красивую, но крайне медленную и бесполезную реализацию. А теперь представьте, что мы пишем не дерево, а операционную систему. Такие группы объектов, которые работают вместе, будут встречаться сплошь и рядом. Что будем делать тогда?
Оказывается, что у каждого объекта есть две стороны - одной он обращен к пользователю, а другой - к тому узлу, в составе которого он работает. И директивы friend в С++ являются очень корявым решением этой проблемы, практически костылем, поэтому основным советом является "используйте friend, только если вы абсолютно уверены, что это нужно". Напротив, модульность в сочетании с ООП - элегантное и системное решение проблемы. ООП помогает нам анализировать предметную область и проектировать нашу систему, модульность помогает нам ее успешно и эффективно реализовывать.

Кроме того, внутри модуля закрывать данные просто не от кого. Во-первых, в КП принято писать модули небольшого размера, обычно до 1000-1500 строк, и помещать в один модуль только тесно связанные типы и процедуры. Во-вторых, за модуль обычно отвечает один человек. И вряд ли найдется пример, когда открытость внутри модуля кому-то помешала. А если мы заменяем одну реализацию на другую - то мы всегда заменяем модуль целиком. Кроме того, в расширяемых системах стремятся не использовать межмодульное наследование реализации, наследуют в основном от асбтрактных типов.

Вышеописанная проблема, кстати, эта одна из причин, почему С++ не особенно жалуют системщики. Торвальдс и Танненбаум очень критически выссказывались по поводу использования С++ при написании ОС. Linux, QNX, ядро Windows - все это написано на голом С. Потому что если ваш с Мейером подход может себя оправдать при создании прикладных систем, то в системном программировании он безусловно пасует - либо реализация получается очень неэффективной, либо приходится постоянно обходить инкапсуляцию.

Оберон же как раз в первую очередь использовался как язык системного программирования (для прикладных задач он еще только начинает использоваться) - на нем оказалось очень удобно реализовывать операционные системы. И две промышленные системы жесткого реального времени (JBed и XOberon) тому доказательство, не считая исследовательских Oberon-1, Oberon System 3, Blue Bottle. Именно Оберон позволил использовать для ОС ООП без потери эффективности (кстати, и сборку мусора тоже).

Если хотите понять идеологию модульных языков - почитайте материалы в разделе Статьи у нас на сайте - там как раз эта тематика освещается.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пятница, 24 Февраль, 2006 03:28 

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857
Илья Ермаков писал(а):
Tree - само дерево, TreeNode - вершина дерева. Пользователь не имеет никакого понятия о реализации этих типов, для него создается набор общих методов. Теперь приступаем к реализации - и сразу же видим, что эти два типа должны иметь полный доступ к внутренностям друг друга. Если заставить их взаимодействовать между собой через тот же интерфейс, который мы описали для пользователя, мы получим красивую, но крайне медленную и бесполезную реализацию.


Эта проблема в С++ может быть решена и без friend'ов. Просто пользователь видит только интерфейсы, а реализация (модуль в терминах С++) и внутренности.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пятница, 24 Февраль, 2006 18:56 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9060
Откуда: Россия, Орёл
Можно, не спорю.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Воскресенье, 26 Февраль, 2006 11:40 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Андрей писал(а):
...


Какая у Вас жуткая каша в голове... :shock:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Воскресенье, 26 Февраль, 2006 12:09 

Зарегистрирован: Среда, 22 Февраль, 2006 10:35
Сообщения: 144
Откуда: Новочеркасск
Сергей Губанов писал(а):
Андрей писал(а):
...


Какая у Вас жуткая каша в голове... :shock:

Перед Вами типичный самоучка, да еще с довольно маленьким опытом


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Воскресенье, 26 Февраль, 2006 14:23 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9060
Откуда: Россия, Орёл
Ничего, самоучками были почти все, а опыт - дело наживное :-)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вторник, 28 Февраль, 2006 00:09 

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 992
Если есть желание менять детали впоследствии - то оформляйте их отдельным модулем. Кстати, очень мало программ страдает от излишней модульности.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Модули и классы
СообщениеДобавлено: Вторник, 20 Май, 2008 00:39 

Зарегистрирован: Среда, 14 Ноябрь, 2007 19:03
Сообщения: 1314
Запоздалый коментарий:
Вот В. Лось тоже обещал мне качественный скачек в понимании ООП.:) И надо сказать он произошел. Перелопатил я кучу литературы по ООП и вот что я понял : лохи и лохи для лохов
это ООП. Там на самом деле никакой общепринятой точки зрения нет. Есть распростаненные мифы и куча бреда в виде например переписанных в т.н. ООП-стиле стандартных приемов программирования известных еще как "паттерны пректирования" или т.н. ОРМ (для баз данных. К смеху сказать но когдато в одой из контор директор поставил перед нами (я и мой дружок) настрочить на Firebird эволюционную БД с объектным интерфейсом. Так вот большая часть идей заложенных в ОРМ ясна была любому идиоту до появления всех этих теорий.Читая книжки по этому вопросу умиляешься до слез :)). Вообщем бред и бред.... :) :) :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re:
СообщениеДобавлено: Вторник, 20 Май, 2008 11:56 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7930
Откуда: Троицк, Москва
GUEST писал(а):
... очень мало программ страдает от излишней модульности.

Удачно сформулировано.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 11 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2018, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB