2D房屋平面图程序内部数据结构选型咨询

嘿，这个场景确实在户型设计、轻量CAD工具开发里太常见了！你提到的两个现有方案的痛点我也深有体会——矩阵方案的方向局限性、对象引用方案的反直觉和渲染难度，确实都不太适合长期维护。我来分享几个实际项目里验证过的靠谱思路：

推荐方案1：实体-组件模式的结构化对象模型 #

这是最常用也最直观的方案，核心是把每个元素拆成独立实体+依附组件，完美解决你提到的所有问题：

核心结构（伪代码示例） #

# 墙体实体：用坐标明确表示，不分水平垂直
class Wall:
    def __init__(self, wall_id, start_x, start_y, end_x, end_y, thickness):
        self.id = wall_id
        self.start = (start_x, start_y)  # 起点坐标
        self.end = (end_x, end_y)        # 终点坐标
        self.thickness = thickness       # 墙体厚度
        self.attachments = []            # 存储依附的柱/门/窗

# 依附组件：统一表示柱、门、窗，关联到对应的墙体
class PlanAttachment:
    def __init__(self, att_id, att_type, position_ratio):
        self.id = att_id
        self.type = att_type  # 可选值："column", "door", "window"
        # 用墙体长度的比例表示位置（比如0.3就是距离起点30%的位置）
        # 也可以用绝对坐标，后续计算时校验是否在墙体内
        self.position_ratio = position_ratio

优势 #

• 解决矩阵方案的方向问题：墙体用起点/终点坐标直接定义，不管水平、垂直还是斜向（如果未来需要扩展），都能统一处理，不存在矩阵行/列的限制
• 渲染友好：遍历所有墙体时，直接用起点/终点画线段；遍历每个墙体的附件时，通过position_ratio计算出附件的坐标（比如墙体向量的插值），直接绘制对应的图形，完全不需要复杂的矩阵转换
• 数据库适配简单：
  • 关系型数据库：拆成两张表——walls（存id、start_x、start_y、end_x、end_y、thickness）和attachments（存id、wall_id、type、position_ratio），关联查询就能还原整个平面图
  • NoSQL数据库：直接把Wall对象序列化为JSON存储，附件可以嵌套在JSON的attachments数组里，存/取都很方便

备选方案2：线段集合+附件映射表 #

如果不需要面向对象的封装，也可以用更轻量化的结构：

• 用一个列表存储所有墙体的线段数据：walls = [{"id": 1, "start": (x1,y1), "end": (x2,y2), "thickness": t}, ...]
• 用一个字典存储附件与墙体的关联：attachments_map = {1: [{"id": a1, "type": "door", "pos_ratio": 0.4}, ...], ...}

这个方案和实体-组件模式本质类似，但更灵活，适合快速原型开发，或者不需要复杂业务逻辑的场景。

避坑提醒 #

• 如果你之前考虑的对象引用方案是指让墙体/附件互相引用（比如墙引用柱，柱引用墙），确实要避免——这种双向引用不仅反直觉，还会增加序列化/反序列化的复杂度，渲染时也容易出现循环依赖问题
• 矩阵方案只适合像素级精度的简易平面图（比如像素画风格），对于需要精确尺寸的户型设计，用坐标化的实体方案才是长期可行的选择

内容的提问来源于stack exchange，提问作者Chapi