Параметризация. Часть 6. Полиморфизьмъ

Проведение аналогий между геометрическим моделированием и объектно-ориентированным программированием начну с термина который обычно идет последним в списке - Полиморфизм. Такой “финт ушами” я себе позволю дабы немного сократить временные затраты на изложение. Дело в том, что частично о полиморфизме я уже писал. Даже привел три/четыре наиболее часто используемые методики геометрического моделирования.

Однако, если почитать умные статьи про полиморфизм, то оказывается что смысл полиморфизма можно описать как: «Один интерфейс, множество реализаций».  Наиболее простой вариант модификации в нашу отрасль: Одна геометрия, множество вариантов создания”. В то же время в этих же умных статьях говорится, что  полиморфизм имеет внешнюю и внутреннюю общность. Внутренняя общность это как раз то, что уже было описано. В программировании этим термином описывается “одинаковая функциональность методов”. Т.е. по сути одна и та же результирующая геометрия, которую можно создать как угодно. При этом пока запомним, что если геометрия не отличается “визуально”, это еще нам ничего не дает. А поговорим об этом чуть позже. Впрочем как и о том, что два визуально отличающихся “объекта” могут иметь одинаковую функциональность.

Внешняя общность обычно выражается как: “одинаковый набор методов с одинаковыми именами и сигнатурами”. И? Как прикажете это понимать и интерпретировать? Одинаковые названия файлов? так нет. Все строить в рамках одной из методик? тоже нет.
Хорошо, тогда зайдем с другой стороны. Что есть “Метод”? Метод - это функция, принадлежащая какому-то классу или объекту. Тут уже ближе. Тогда спросим, что есть “Класс”? Тут проще не цитировать, а сразу послать в вики. Ух ё... Ладно... А что есть “Объект”? Объект — некоторая сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеет заданные значения свойств (атрибутов) и операций над ними (методов). При этом вспомним, что “термины «экземпляр класса» и «объект» взаимозаменяемы”.

Ладно. Попробуем “вкурить”. Методы в программировании это то к чему мы непосредственно обращаемся, вне зависимости от того работаем мы с классами или объектами. Ну ладно. А с чем мы работаем в геометрическом моделировании? С параметрами. Угу. Типа должно было полегчать? Ладно пойдем так. Вопрос: Когда мы собираем сборку мы работаем с чем? Ответ: С элементами геометрии (то с этим компланарно, это соосно это и пр... ). Являются ли эти связи параметрами? Как не смешно, но являются. Оки. Что мы еще можем сделать в сборке? Наложить взаимосвязи между геометрическими элементами или численными параметрами, через привязки и уравнения. Т.е. “Метод” - это параметр (численный или геометрический элемент не суть важно), который принадлежит компоненту (модели или подсборке). И по аналогии (между методами различных объектов в ООП) между элементами различных компонентов мы настраиваем взаимосвязи. Что нам это дает? (Вспоминаем базовые определения) А дает нам это вот, что - чтобы у нас по нормальному работали взаимосвязи нам необходимо, как-то стандартизировать принципы построения геометрии и методики ее параметризации, так чтобы в случае замены одного компонента на другой СХОЖИЙ (не такой же с другими размерами, а другой, но схожий по “функциональности”) у нас не возникало проблем. Классно сказано... Только как это реализовать?

Приведу цитату из ГОСТа 3452-59, кроме прочего, он предусматривает следующее:

Для перечисленных ниже величин, указываемых на чертежах и в других технических документах, устанавливаются следующие буквенные обозначения:

• ·   длина – L, l;
• ·   ширина – B, b;
• ·   высота, глубина – H, h;
• ·   толщина (листов, стенок, ребер и т. д.) – δ;
• ·   диаметр – D, d;
• ·   радиус — R, r;
• ·   сторона многоугольника – a;
• ·   величина фаски – c;
• ·   зев ключа (размер под ключ) – S;
• ·   шаг резьбы – s;
• ·   шаг зубчатых зацеплений, цепей и звездочек, винтовых пружин, болтовых и заклепочных соединений – t;
• ·   модуль зубчатого колеса, червяка – т;
• ·   число зубьев зубчатых колес и звездочек, число заходов червяка – Z;
• ·   углы – α, β, γ, θ, φ, ψ;
• ·   площадь – F;
• ·   объем – V.

Об чем речь? Речь об том, что в далеком 59 году (а на самом деле и того раньше) задумывались над тем как проще параметризовать объекты и как сделать это более стандартизовано.

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

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

Не смотря на то, что я уже по сути писал о полиморфизме, тогда я просто описывал ситуацию, без проведения параллелей. Честно говоря мне кажется, что без параллелей было лучше. Пока я это просто на словах описывал мне казалось что все понятно, когда начал писать задумался сам. Теперь я понимаю, почему студенты волком выть готовы на лекциях… Сам виноват. Ладно с понедельника продолжим и поговорим об инкапсуляции. Будем надеяться что мои бредни о черных ящиках будут проще ;)