Поэтому критика работ Вирта воспринимается там очень болезненно.
В чем Вирт не прав?
В том, например, что включил "куцее" ООП в Оберон... Либо он понимает суть ООП, либо... нафиг-нафиг...
То есть такое ООП не следовало вообще включать? Или поддержку ООП не нужно в языках вообще? В каком языке правильная поддержка ООП?
Давайте попробуем разобраться, что такое ООП... по сути. Суть ООП в классификации, то есть в разработке и создании многих типов сущностей, которые что-то получают от предков (re-use), что видоизменяют. В результате получается множество (описаний) прототипов сущностей со схожим поведением. В традиционном программировании нет аналога этому механизму, а это порождает много проблем. Например, если появляется второй прототип, чем-то похожий на первый, то надо описать его отдельно и подпрограммы, которые работали с первым прототипом необходимо пересмотреть и при необходимости, создать новые, с изменённым поведением. Но теперь мы встаём перед проблемой, что надо как-то одинаково обращаться к одинаковым по сути, но различным по имени и содержанию подпрограммам. Школьный пример, "некто" обращается к фигурам и просит их нарисовать себя... "треугольник" рисует на экране треугольник, "квадрат" рисует квадрат, "круг" рисует круг. "Некто" может и не знать, какие фигуры входят в коллекцию, но как же он тогда узнает, какие подпрограммы вызывать?.. Но если у нас определён класс фигур с методом "рисовать себя", от него унаследованы конкретные фигуры, то можно к любым фигурам обращаться одинаково, при этом каждая фигура будет вести себя сообразно своей сути. Что и требовалось. Другими словами, классификация на основе свойств сущностей позволяет упорядочить их организацию и, как следствие, снизить затраты на разработку, развитие и сопровождение.
Второй элемент ООП - полиморфизм. Сходные, но имеющие отличия свойства прототипов, являются полиморфными. Но полиморфными могут быть и сами прототипы, на этой основе работает классификация. Но при этом полиморфизм "шире" наследования, поскольку классы могут иметь полиморфные свойства, которые отсутствуют у их общего "предка" (да, и сам общий "предок" у этих классов может отсутствовать). Например, летать может самолёт и утка... означает ли это, что у них (в рамках данной предметной области) есть общий "предок", умеющий летать?.. Не очевидно...В общем случае, полиморфными могут быть: элементы структуры класса, его методы и... сами классы (в рамках наследования). Полиморфность
ключевых элементов и методов является основой наследования, но полиморфными могут быть элементы и методы вне наследования.
Инкапсуляция - третий элемент ООП, он подразумевает, что структура класса сокрыта от внешних сущностей, с другой стороны, инкапсуляция подразумевает, что всё, что нужно данной сущности, реализовано в ней самой, то есть никакие внешние элементы ей не нужны. Сокрытие структуры и методов необходимо для того, чтобы внешние элементы не привязывались к частной внутренней реализации сущности, поскольку в противном случае, при изменении сущности, придётся проверять и видоизменять её окружение. Впервые инкапсуляция была реализована в подпрограммах, когда доступ к подпрограмме происходил посредством обращения к её заголовку и замещению формальных параметров фактическими. Это позволяло модифицировать подпрограммы без модификации её окружения, если, конечно, объявление подпрограммы (её интерфейс) не менялись. Если внешний код мог входить в "тело" подпрограммы, минуя её заголовок, то изменение "тела" подпрограммы могло привести программу к краху. Дальнейшее развитие инкапсуляции - это модульное программирование... где свойства инкапсулированы в модуле, и только интерфейсы "торчат" наружу.
Это основы ООП... А теперь давайте задумаемся... зачем они нужны в программировании?.. Если мы пишем программу, то зачем нам плодить множество похожих, но не одинаковых по сути, элементов, выстраивать из них классификацию, вникать в полиморфизм, защищать их организацию?.. Это всё не нужно, это мешает и снижает эффективность программы. Ведь прямой доступ, например, всегда эффективнее, чем косвенный, посредством каких-то дополнительных элементов. Почему вдруг, программист не может изменить значение поля какой-то структуры
его программы?
Важность и полезность всех перечисленных элементов ООП становится понятна на некотором подмножестве программ, равно, как и полезность библиотек подпрограмм/модулей была осознана тогда, когда эти библиотеки/модули стали использоваться из многих программ. А ООП позволяет перейти от программ к системам... И здесь всё становится на свои места, каждый уровень системы имеет свой интерфейс, который реализует на множестве прототипов, и внешний уровень принципиально не должен знать устройство какого-то элемента, поскольку такое знание снижает не только надёжность, но и эффективность(!) системы в целом. Простой пример, элемент А получал нечто от элемента Б, это было хорошо и удобно, но ситуация изменилась, в системе появился элемент В, который способен обеспечивать элемент А более быстро и эффективно, но элемент А об этом ничего не знает и по-прежнему получает нечто от элемента Б... А если элемент Б исчез?.. Что будет с системой?..
Понимаю, что стучусь в открытые ворота, но... тем не менее... это надо было произнести, чтобы ответить на Ваши вопросы... Начну с конца... с последнего вопроса.
Наиболее полно и правильно ООП был реализован в SmallTalk, IMHO...
Поддержка ООП, конечно, нужна, но... это задача не одного уровня. Поддержка ООП нужна для проектирования (и, отчасти, при моделировании), чтобы можно было не программировать, а собирать/настраивать
систему для решения определённого
класса задач, но не для решения отдельной
задачи/программы. Поддержка ООП нужна и в программировании, для реализации объектной иерархии, объявления интерфейсов (полиморфных свойств), для спецификации ролей и пр. Всё это при решении отдельной задачи - излишество. Но то, что сделано в Оберон - это "подачка бедным"... расширили структуры методами и... всё. Следует понимать, что создание иерархии классов и её использование - это совершенно разные задачи, равно как изготовление кирпичей и их использование при строительстве. Что есть в Оберон? Изготовление кирпичей... остальное отдано на совесть разработчика... Нет никаких средств для разработки надуровня... того самого, где изготовленные кирпичи превращаются в здание.
И, наконец, надо ли было включать ООП?.. Если Н. Вирт объявил Оберон языком
создания систем, то, конечно, ООП надо было включать, но отвечает ли Оберон требованиям языка создания систем?.. В таком ракурсе я не могу ответить на этот вопрос... Как Вы сами считаете, удобен ли Оберон для написания систем?
Не программ, а именно систем?.. На мой взгляд нет, в этом смысле он ничем не лучше Паскаля или Си... А, следовательно, ООП там излишество... Для написания программ этого не нужно. Что же касается создания систем.... то, что в есть в Оберон в плане создания и разработки архитектуры?.. Ничего...
