IfcBuildingElementProxy: удобный костыль или скрытая проблема?
Часть 1 из 3
Давно хотелось написать про IfcBuildingElementProxy (а также IfcProxy для версий до IFC4x1). Он часто используется, когда в IFC-стандарте не удается найти подходящий класс. Но загвоздка в том, что его бесконтрольное применение может создать больше проблем, чем решить их.
Чем грозит такое использование IfcBuildingElementProxy для классификации элемента?
➡️ Потеря семантики - элемент становится "черным ящиком". Он лишается своего назначения, если proxy-класс применяется без дополнительной классификации. А это нарушает принципы информационного моделирования и не совсем вписывается логику онтологии IFC.
➡️ Проблемы для коллег. То есть по сути перекладывание задачи классификации на кого-то позднее, кто будет вынужден вручную разбираться, что же скрывается за такими Proxy-элементами.
Оставлять Proxy-элементы в таком виде - плохая практика.
Но почему так происходит и что делать? - разберемся в следующих частях.
👥 @IFC_ru
👥 @IFC_club
Часть 1 из 3
Давно хотелось написать про IfcBuildingElementProxy (а также IfcProxy для версий до IFC4x1). Он часто используется, когда в IFC-стандарте не удается найти подходящий класс. Но загвоздка в том, что его бесконтрольное применение может создать больше проблем, чем решить их.
Чем грозит такое использование IfcBuildingElementProxy для классификации элемента?
➡️ Потеря семантики - элемент становится "черным ящиком". Он лишается своего назначения, если proxy-класс применяется без дополнительной классификации. А это нарушает принципы информационного моделирования и не совсем вписывается логику онтологии IFC.
➡️ Проблемы для коллег. То есть по сути перекладывание задачи классификации на кого-то позднее, кто будет вынужден вручную разбираться, что же скрывается за такими Proxy-элементами.
Оставлять Proxy-элементы в таком виде - плохая практика.
Но почему так происходит и что делать? - разберемся в следующих частях.
👥 @IFC_ru
👥 @IFC_club