寻找扩展班级结构的最佳实践 [英] Looking for Best Practice on Extending Class Structure

问题描述

你好，

一个普遍的问题是，在进行中的项目需求期间确实经常更改.可以使用装饰器模式等来处理功能更改.但是一个严重的问题是，当任何实体的静态结构发生变化时.您必须对持久性存储，报告，映射，模型，域等进行不懈的更新.

是否存在任何模式或最佳实践来应对此类更改，可能仅通过扩展静态结构即可.

谢谢，最好的问候..

Hello,

It is a common problem that during an ongoing project requirements do change frequently. Functional changes can be handled using -for instance- the decorator pattern and so on. But a serious problem is that when the static structure of any entity changes. You have to do relentless updates on your persistent storage, reports, mappings, models, domain etc.

Does there exist any pattern or best practice to handle such changes, may be by just extending static structure.

Thanks and best regards..

推荐答案

解决方案不能通用，因为一切都取决于不断变化的需求的性质.依靠扩展而不是修改是没有帮助的.

我只能看到一种方法:将方法从硬编码结构更改为存储的元数据和知识工程，尤其是本体工程(请参见下面的链接).但是，这种技术的体系结构远远超出了 Quick Questions&如果不是一本书，答案可能是一件非常大的文章.

简而言之，您所面临的不断变化的需求可以被视为知识.由于业务环境的变化以及自然缺乏强大的预测技能，甚至利益相关者的视线通常很小，这种知识可以被称为垃圾知识". (在这种情况下，开发人员说他们不了解自己想要的东西"，而这仅仅是生活中的事实，通常是不可避免的.)因此，对此类知识进行硬编码可能是不切实际的.在某些情况下，知识工程可用于以元数据的形式开发非常抽象的知识模型，该模型不是硬编码的，而是存储在某些持久性媒体(数据库，XML文件)中.例如，过去我开发了以某种元数据模式的形式表示知识的技术，并且我们开发了用于以UML结构图的形式添加/修改结构的元数据引擎和图形工具.该工程步骤的持久工件用于生成代码.这里最困难的问题是备份兼容性的支持，但是架构演变的自动化特性很有帮助.一种想法是:您可以尝试仅坚持增量更改.删除的元素不会从元数据中物理删除，而是标记有特殊属性"deprecated"；因此，系统只能将这些元素与旧数据一起使用.同样，这很难用一个简短的答案来完整解释. (不，此代码不可用，抱歉.)

这一点都不容易.您可以考虑在高科技方法与频繁的手动更改和修复的痛苦之间进行权衡.您可以尝试找到一些实际的折衷方案，而这本身就是困难的.从根本上讲，这个问题很难解决.

参见:
http://en.wikipedia.org/wiki/Knowledge_engineering [ http://en.wikipedia.org/wiki/Ontology_%28information_science%29 [ ^ ]，
http://en.wikipedia.org/wiki/Ontology_engineering [ http://en.wikipedia.org/wiki/Metadata [ http://en.wikipedia.org/wiki/Expert_system [

The solution cannot be universal because everything depends on the nature of changing requirements. Resorting to extensions as opposed to modification cannot really help.

I can see only one way: to change approach from hard-coded structures to stored meta-data and knowledge engineering, in particular ontology engineering (please see the links below). However, the architecture of such technology goes well beyond the format of Quick Questions & Answers and could be a matter of a really big article if not a book.

In brief, the changing requirements you face with can be considered as knowledge. Due to changed business settings and quite natural lack of powerful predictive skills and often even the minimal vision of stakeholders, this knowledge can be characterized as junk knowledge. (In such cases developers say "they don''t know themselves what they want", and this is just the fact of life, generally unavoidable.) So, hard-coding of such knowledge can be impractical. In certain situations, knowledge engineering can be used to develop a very abstract model of knowledge in the form of meta-data, not hard-coded but stored in some persistent media (database, XML file). For example, in the past I developed technology where the knowledge was represented in the form of some meta-data schema, and we developed meta-data engine and graphic tools used to add/modify structures in the form of UML structural diagrams. The persisting artifact of this engineering step is used to generate code. Most difficult problem here is supporting of backup-compatibility, but automated character of schema evolution helps a lot. One idea is: you can try to stick to incremental changes only. The removed elements are not physically removed from meta-data, but are marked with the special attribute "deprecated"; so the system works with those elements only with legacy data. Again, this is difficult to explain in full in a short answer. (No, this code is not available, sorry.)

This is not easy at all. You can consider some trade-off between highly technological approach and the suffering of frequent manual changes and fixes. You can try to find some practical compromise which itself is difficult. The problem is fundamentally pretty difficult.

See:
http://en.wikipedia.org/wiki/Knowledge_engineering[^],
http://en.wikipedia.org/wiki/Ontology_%28information_science%29[^],
http://en.wikipedia.org/wiki/Ontology_engineering[^],
http://en.wikipedia.org/wiki/Metadata[^],
http://en.wikipedia.org/wiki/Expert_system[^],

—SA

很遗憾，这是野兽的本质，您无法使用传统的编程方法来避免它.

但是，使用文档数据库并以JSON或XML等存储对象结构确实会降低更改和所需的测试，并且在大多数情况下，它们与架构更改无关.

Unfortunately it''s the nature of the beast, and you cannot avoid it using traditional programming methods.

However using document databases and storing object structures in JSON or XML etc. do lower the changes and testing needed and in much of the cases are indifferent to schema changes.

这篇关于寻找扩展班级结构的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！