Как построить структуру класса, когда члены также структурированы иерархически?

Ответ 1

Возможно, я слишком задумываюсь, но я предлагаю вам использовать немного другую модель, чтобы отразить вашу бизнес-логику.

Следующее может быть полным недоразумением, но я дам ему шанс.

Итак:

Основываясь на том, что на самом деле какая-либо связь, вот понятие:

• Каждое соединение представляет собой набор узлов, через которые данные должны перемещаться, чтобы добраться до места назначения.
• Каждый node может подключаться со следующим node с использованием определенного протокола, который специфичен только для прямого соединения между двумя конкретными узлами.
• Протокол имеет свои собственные свойства, общие для исходных и целевых узлов.

Основываясь на этом, я предлагаю следующую модель построения, управления и хранения конфигурации продукта:

Здесь:

• LogicalConnection - это ссылка на встроенную композицию фактического соединения, node и классов протокола

• Соединение содержит двойной список узлов, которые составлены в порядке поступления данных. i.: 1-й элемент является источником node, а второй - его целью и т.д.

• Конкретный node содержит конфигурацию для конкретной платформы, ссылку на цель (* Node), источник node (* Node) и конкретный протокол (* Протокол)

• Протокол содержит определенную конфигурацию для источника и цели, экземпляры node могут ссылаться на экземпляр протокола для извлечения необходимой конфигурации.

• Целевые и исходные узлы "см." конфигурация каждого другого источника и источника-источника с помощью структуры с двойными связями ".

• Конфигурации\* Реализации ConfigBuilder организуют процесс принятия данных из пользовательского интерфейса и преобразуют его в фактический состав Connection, node и Protocol в зависимости от случая.

• Пространства имен IBM\ConnectDirect\и IBM\FTGW\содержат конкретные реализации для протокола и * Node (например, WindowsNode, UnixNode)

Если по-прежнему существует потребность в node или в протоколе содержать как исходные, так и целевые атрибуты, а часть из них по-прежнему может быть NULL в некоторых конфигурациях - я предлагаю использовать модель хранения EAV для БД, если есть какая-либо озабоченность неиспользуемые столбцы и т.д.

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

Connection:IBM_CD {
  nodes:[
    {//LinuxNode
      target:*nextElement,
      protocol:{//IBM.ConnectDirect.Protocol
        ..target attributes..
        ..source attributes..
      }
      ..platform specific attributes..
    },
    {//WindowsShareNode
      target:*nil,
      protocol:{
        //IBM.ConnectDirect.Protocol(same instance or null)
      }
      ..platform specific attributes..
    },
  ]
}

Connection:IBM_FTGW {
  nodes:[
    {//LinuxNode
      target:*nextElement,
      source:*nil,
      protocol:{//IBM.FTGW.Protocol
        ..target attributes..
        ..source attributes..
      }
      ..platform specific attributes..
    },
    {//IntermediateServerLinuxNode
      target:*nextElement,
      source:*prevElement,
      protocol:{//IBM.FTGW.Protocol
        ..target attributes..
        ..source attributes..
      },
      ..platform specific attributes
    },
    {//WindowsShareNode
      target:*nil,
      source:*prevElement,
      protocol:*nil,
      ..platform specific attributes..
    }
  ]
}