雪一更--SRDC_data-analysis platform 项目整理

目的：精炼项目设计开发要点

---

index:

1.架构层级

2.局部

3. 

---

1. 架构反思概述

1.大处着眼，外部交互的接口定义。整个流程的控制。(+1, 高层设计很重要，前置, 此处现实中矛盾点是 一些部分会在实现阶段才出现，

结合现实，尽可能在高层考虑到成本高的部分,提取通用模块，将各自实现部分以抽象类在通用模块中存在.

 

2.整体流程的控制层级，各阶段的输出要按照最终结果的接口要求实现，阶段性的成果的状态，位于finalization 时，属于最终结果。

3.user specification 结构性的数据外置，能很好的将职责分离，一定范围内的易于变化。

 

---

2.局部要点

2.1 阶段性的结果各异，客户端需要使用的内容不同，但在内部要统一结果. 整洁。

 

 

 

统一结果，即使 Exclusive 部分可能只需要 名称列表.但要统一.可对外再提供便捷接口.

 

---

3. 阶段性架构的反思

　　1. 全局性信息的完整性和罗列，是必要的信息.

　　2. process 有多个阶段，不同阶段所产出的 process result 不同, 应用职责给出result，抽象 result, 方向正确，但在其设计和使用上,简化以便易于理解。

        3.user specify 职责要内聚，data-pro v2.0.2023 版本，有其在外部处理的部分.

　　4.Extension object 模式的不正确使用.

　　5.compose 设计模式的精简，其实现局部和整体的关系，不要将层级对象的构建属性杂糅进去.  AquaEdgePart 接口，错误的想将各不同节点的一些信息抽象。造成其抽象本体和实际层级对象的大量转换，抽象本体的弃用，属性的命名困惑不清晰。

　　6.conditional equal 分流的功能设计合理性需要思考. 职责定位，或是缺少协作，未完成分离。

　　7.流程各阶段status 尽可能简化为二元，implicit 关联.

　　8. enum 结合 interface 使用的合理性。

　　9.流程各分阶段的stats 要自身承担起来。结合全局的process enum 关联起来。自身数据自己管理。后续的整体统计方便.职责内聚，也避免信息暴露给外部.

---

 1》全局性反思资料：

3-4 ， ExtensionObject

 

延申思考：extensionObject 基于主体 AquaEdgeProResult 的 validation 可用在过程中，或是类似 report 的输出到外部，外部持久化保存，而在

内存中，除非 AquaEdgeProResult 持有该状态，否则再下次使用依然需要运行相同的方法.

考虑下组合关系，将相应的状态对象组合进去。 思考泛型避免类型转换

interface 结合 enum 

 

---

2023-06-08

抽象结构的构建，需要把职责抽象出来. 不然只能使用原型. 泛型要合理使用.

 以下具体了 composite 局部--整体 此种关系.

---

 

针对不同的 xml 数据结构, 合理的构建需要设计。考虑 组合关系， 结合该类对象的职责抽象.

组合  装饰器模式

例如： value entry, 不同的属性数量. 

职责：1. sequence 对应, 2. 值对比, 会为后续提供数据转换. 

1.xml-1  Chiller - SAP 

 xml-2  Performance 

xml-3 price

---

 

2023-06-08