Проведение аналогий между геометрическим моделированием и объектно-ориентированным программированием начну с термина который обычно идет последним в списке - Полиморфизм. Такой “финт ушами” я себе позволю дабы немного сократить временные затраты на изложение. Дело в том, что частично о полиморфизме я уже писал. Даже привел три/четыре наиболее часто используемые методики геометрического моделирования.
Однако, если почитать умные статьи про полиморфизм, то оказывается что смысл полиморфизма можно описать как: «Один интерфейс, множество реализаций». Наиболее простой вариант модификации в нашу отрасль: Одна геометрия, множество вариантов создания”. В то же время в этих же умных статьях говорится, что полиморфизм имеет внешнюю и внутреннюю общность. Внутренняя общность это как раз то, что уже было описано. В программировании этим термином описывается “одинаковая функциональность методов”. Т.е. по сути одна и та же результирующая геометрия, которую можно создать как угодно. При этом пока запомним, что если геометрия не отличается “визуально”, это еще нам ничего не дает. А поговорим об этом чуть позже. Впрочем как и о том, что два визуально отличающихся “объекта” могут иметь одинаковую функциональность.
Внешняя общность обычно выражается как: “одинаковый набор методов с одинаковыми именами и сигнатурами”. И? Как прикажете это понимать и интерпретировать? Одинаковые названия файлов? так нет. Все строить в рамках одной из методик? тоже нет.
Хорошо, тогда зайдем с другой стороны. Что есть “Метод”? Метод - это функция, принадлежащая какому-то классу или объекту. Тут уже ближе. Тогда спросим, что есть “Класс”? Тут проще не цитировать, а сразу послать в вики. Ух ё... Ладно... А что есть “Объект”? Объект — некоторая сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеет заданные значения свойств (атрибутов) и операций над ними (методов). При этом вспомним, что “термины «экземпляр класса» и «объект» взаимозаменяемы”.
Ладно. Попробуем “вкурить”. Методы в программировании это то к чему мы непосредственно обращаемся, вне зависимости от того работаем мы с классами или объектами. Ну ладно. А с чем мы работаем в геометрическом моделировании? С параметрами. Угу. Типа должно было полегчать? Ладно пойдем так. Вопрос: Когда мы собираем сборку мы работаем с чем? Ответ: С элементами геометрии (то с этим компланарно, это соосно это и пр... ). Являются ли эти связи параметрами? Как не смешно, но являются. Оки. Что мы еще можем сделать в сборке? Наложить взаимосвязи между геометрическими элементами или численными параметрами, через привязки и уравнения. Т.е. “Метод” - это параметр (численный или геометрический элемент не суть важно), который принадлежит компоненту (модели или подсборке). И по аналогии (между методами различных объектов в ООП) между элементами различных компонентов мы настраиваем взаимосвязи. Что нам это дает? (Вспоминаем базовые определения) А дает нам это вот, что - чтобы у нас по нормальному работали взаимосвязи нам необходимо, как-то стандартизировать принципы построения геометрии и методики ее параметризации, так чтобы в случае замены одного компонента на другой СХОЖИЙ (не такой же с другими размерами, а другой, но схожий по “функциональности”) у нас не возникало проблем. Классно сказано... Только как это реализовать?
Приведу цитату из ГОСТа 3452-59, кроме прочего, он предусматривает следующее:
Для перечисленных ниже величин, указываемых на чертежах и в других технических документах, устанавливаются следующие буквенные обозначения:
- · длина – L, l;
- · ширина – B, b;
- · высота, глубина – H, h;
- · толщина (листов, стенок, ребер и т. д.) – δ;
- · диаметр – D, d;
- · радиус — R, r;
- · сторона многоугольника – a;
- · величина фаски – c;
- · зев ключа (размер под ключ) – S;
- · шаг резьбы – s;
- · шаг зубчатых зацеплений, цепей и звездочек, винтовых пружин, болтовых и заклепочных соединений – t;
- · модуль зубчатого колеса, червяка – т;
- · число зубьев зубчатых колес и звездочек, число заходов червяка – Z;
- · углы – α, β, γ, θ, φ, ψ;
- · площадь – F;
- · объем – V.
Об чем речь? Речь об том, что в далеком 59 году (а на самом деле и того раньше) задумывались над тем как проще параметризовать объекты и как сделать это более стандартизовано.
Понятное дело, что в больших сложных объектах подобным набором не обойдешься, но никто не мешает установить ряд стандартных названий для параметров, которые обозначают определенные вещи, и тогда нет надобности задумываться, как “звучит” тот или иной параметр. Вам это известно заранее.
Не смотря на то, что я уже по сути писал о полиморфизме, тогда я просто описывал ситуацию, без проведения параллелей. Честно говоря мне кажется, что без параллелей было лучше. Пока я это просто на словах описывал мне казалось что все понятно, когда начал писать задумался сам. Теперь я понимаю, почему студенты волком выть готовы на лекциях… Сам виноват. Ладно с понедельника продолжим и поговорим об инкапсуляции. Будем надеяться что мои бредни о черных ящиках будут проще ;)
Комментариев нет:
Отправить комментарий