Exceeder (exceeder) wrote,
Exceeder
exceeder

  • Mood:
  • Music:

Опять скучное про программирование...

(давно вот тут обещаное продолжение)

...под нею красовался кусок фанеры с надписью чернилами вкривь и вкось:

                     КОТ НЕ РАБОТАЕТ
                                 Администрация
© А. и Б. Стругацкие


Итак, посмотрим на несколько обьективных причин, почему не всегда работает обьектно-ориентированный кот.

1. Неопределенность удаленного воздействия
Пусть x,y это обьекты классов X и Y соответственно; пусть f - метод класса X и g - метод класса Y. Введем нотацию
x.f ≈> y.g

означающую:
x.f может быть причиной вызова y.g как напрямую, так и опосредовательно, через вызовы других методов.

Во всех ОО языках существует понятие импорта, которое в лучшем случае обьясняет, какие другие классы нужны для работы текущего, но мало что дает при выяснении области воздействия W(x,f) вызова метода x.f:
W(x,f) = {(y.g) | x.f ≈> y.g}

В лучшем случае об этом можно узнать из комментария. Но собственно корень проблемы уходит в наследование имплементаций (динамическое по сути), что усложняет или делает невозможным статический анализ. Больше об этом можно прочитать в будущем п. 4.

От себя: собственно, это одна из основных проблем начинающих программистов - беззаботно и необдуманно раширять область воздействия методов по всей программе. Кстати, новая тигровая Джава как раз разрешает импорт единичных методов. Это частичное решение проблемы. А вот дальше, на первый взгляд, кажется, что бороться с наследованием почти невозможно: ты не знаешь, кто там как что поменяет в унаследованных методах, на которые ты опираешься, и в итоге ты не можешь контролировать область воздействия твоего метода. Создается впечатление, что наследование нужно тогда вообще убрать - что есть возврат в каменный век. На самом деле это не так. Во-первых, можно оставить только абстрактные методы и интерфейсы. Во-вторых, даже для прямого наследования методов можно выработать более математически строгие правила, которые борятся с анти-паттернами.

2. Бумеранг
Область воздействия может в процессе своего распространения через вызовы методов вернутся на исходный класс:
x.f ≈> x.g

В случае f=g мы имеем тривиальную рекурсию. Даже опытный программист не видит здесь проблемы, хотя именно этот эффект стал причиной огромного количества трудноустраняемых ошибок. Обычно на практике разработчики наивно полагают, что каждый обьект перед вызовом и после завершения каждого метода находится в непротиворечивом (целостном, consistent) состоянии. Однако на момент вызова x.g, который произошел глубоко внутри кода x.f, обьект как раз выглядит случайным образом и может как угодно противоречить логике x.g. По крайней мере, следует различать между методами, которые требуют целостности обьекта, и такими, которым все равно.
Одно из главных наблюдений здесь, это что спецификация поведения классов попадает в такие же трудности, как и распределённые интерактивные системы (включая одновременность выполнения операций и их гранулярность). Таким образом, ООП требует введения знаний о контейнере-оркестраторе, который и обеспечивает настоящую параллельность процессов и целостность обьектов.

От себя: если вы когда-либо работали с MS Project, то наверняка знаете что такое критичный путь в проекте и пробовали распределить обязанности и ресурсы между исполнителями. При этом самих исполнителей отнюдь не надо переделывать. Просто требуется достаточно знаний и опыта для оптимальной оркестрации проекта. Точно также встроенные средства следующего поколения языков могли бы помочь оркестраторам систем с распределением их выполнения. На первый взгляд кажется, что Бумеранг не связан со scalability, однако же Брой здесь дает блестящее обоснование

... пока всё :) там еще много, на пять таких постов, но такое надо читать кусочками, переосмысливая мир вокруг нас :-D...
ЗЫ: А может уже перевести все и где-нибудь опубликовать? Впрочем, я совершенно ничего не знаю о русскоязычных программерских журналах и опыта у меня 0, в отличие от америки. Буду пока тут потихоньку писать. Критика, тем не менее, приветствуется, в том числе и претензии к стилю и качеству изложения.
PPS. А еще я последние пару месяцев серьезно перетираю идеи для нового языка программирования. Оттолкнувшись от "трехмерной" ООП-модели моей дипломной работы, я пытаюсь воткнуть в нечто лаконичное и самодостаточное решения хотя бы десятка проблем, которые пытаются покрыть таким уродством, как EJB, или бездумно применяя аспекты.
Tags: programming
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 19 comments