Параметризация. Часть 7. Черный пречерный ящик.

Никогда не любил термин “инкапсуляция”. Но не смотря на это принцип “черного ящика” является одним из наиболее почитаемых.

Многим из нас, можно даже сказать большинству, приходилось разбираться в чужом программном коде или в чужих моделях. Даже при наличии комментариев, даже если автором того, в чем приходится копаться, являемся мы сами, просто делалось это пару лет назад... Нужно иметь недюжинное терпение, чтобы продраться сквозь тернии к звездам. Проще все сделать заново. Но не всегда достаточно времени на переделку всего проекта, только на часть.

Возможно ли это? Зачастую возможно, но иногда приходится, не смотря ни на что, переделывать весь проект. В чем причины таких вариантов? Причины либо в неправильной исходной постановке, либо от неправильного подхода к решению. С первым случаем мало что можно сделать, а вот второй подкорректировать можно попытаться. Самое интересное, что при правильном подходе, даже при наличии проблем в изначальной постановке переделывать приходится существенно меньше.

Что ж это за подход такой волшебный? Подход, о котором я говорю, не волшебный,  но без него принцип черного ящика теряет смысл. Нет, серьезно, нет в нем никакой волшбы. А что тогда есть? Наверное здравый смысл... Ну да в общем, судите сами. Подход лучше всего описывается классическим “divide et impera” т.е. “разделяй и властвуй”. В нашем варианте один сложный объект мы представляем в виде системы более простых “блоков”. Отдельные “блоки” так же можно разделить на подблоки.
Нет, я не издеваюсь. Да, я помню, что мы и так работаем со сборками подсборками и компонентами. Только вопрос не в этом, а в системности. В большинстве случаев (исключение составляют случаи следования одной из техник параметрического моделирования), создание сборки происходит бессистемно, даже если происходит в режиме top-down. Единственная закономерность, которая прослеживается в таком случае - это попытка повторить принцип сборки объекта “в живую”. А это не самый лучший вариант. ведь реальный объект собираемый “в живую” состоит из “неживых” компонентов. То есть тем самым мы убиваем жизнь и параметричность нашей сборки. Пусть не всегда убиваем полностью, но калечи точно. Отсутствие “жизни” состоит в отсутствии движения параметров в теле сборки. И тут не всегда достаточно “костылей” в виде “связок” между параметрами различных компонентов. Потому как это будет похоже на стул о четырех ногах. Вроде все в порядке, но стоит поставить его на слегка неровный пол и стул всегда стоит только на каких-то трех ногах. Качните его и он опять будет стоять на трех, только других. Т.е. вместо устойчивого положения равновесия мы будем иметь этакого “шалтая-болтая”. Да шататься он будет не сильно, но будет.

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

При нормально построенной подобной схеме можно “включить” принцип черного ящика на каждом блоке, так как теперь глубоко все равно, что находится внутри любого из блоков. Лишь бы он исправно работал - т.е. принимал что нужно и выдавал тоже не что попало. Главная прелесть состоит в том, что теперь нет проблем заменить один блок на другой с подходящей спецификацией (спецификация - это описание функционала и входных/выходных параметров). Возможно ли вышеописанное - вопрос который требует дополнительного рассмотрения.