分层对象设计(Java)
我正在寻找一种优雅的设计来解决类似于以下的问题:
故事可以具有灵活的层次结构。它可能由多本书组成,每本书都有章节,每本书都有章节,每本书都包含文本。或者,它可能只是有几个部分(例如短篇小说)。或者它可能只包含有章节的章节。在所有情况下,都不允许您混合风格(因此您不能向基于书籍的故事添加章节,您必须将章节添加到书籍本身)。
我针对此类问题提出了一些设计解决方案,但它们变得混乱。是否有一种干净的方式来表示这一点,以便在参考 Story 类的情况下,我可以以清晰、系统的方式访问内容?
I am looking for an elegant design for a problem analogous to the following:
A story can have a flexible hierarchical structure. It might consist of several books, each of which have chapters, each of which have sections, each of which contain text. Or, it might simply have sections (a short story for instance). Or it might just consist of chapters that have sections. In all situations, you mustn't be allowed to mix styles (so you couldn't add a chapter to a story based on books, you would have to add the chapter to the book itself).
I have come up with a couple of design solutions for this type of problem but they get messy. Is there a clean way to represent this so that, given a reference to a Story class I can get access to the content in a clear, systematic fashion?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
这是一种棘手的情况,因为像“书籍”、“章节”、“部分”这样的概念可能有一些共同的元素,这些元素表明类层次结构或公共接口实现。
同时时间,足够不同,可以作为不同的类/对象来处理,完全按照“所以你不能向基于书籍的故事添加章节”的要求。
在概念上处理分层对象时,有将它们转化为代码的几种方法,每种方法一个更适合特定的情况。
1.类组成
每个概念都有一个类或原型,它们可能通过继承或接口相关或不相关。
元素有内部集合,并且可以限制它们的操作,
通过方法。
当不同的类不多(可能是 5 个)时,这些方法很好。
2。树设计模式。
当所有元素即使不相似也将相等时,适用该模式,
通常是相同的类或接口,通常有很多项。
这些不适用于您的情况,但是,
我不得不提一下,为了更好地申请。
通常,使用树/分层集合类。
它可以是通用/模板树集合的子类,
或基本 tre 集合的子类,
它旨在被具有特定成员的子类所取代。
3.混合动力。
这是前两者的组合,
当有很多相关项目时使用它,
它比较复杂,可以使用也可以不使用Factory &抽象工厂模式,
其更常见的例子是视觉控制和视觉控制。小部件库。
您可能会注意到我没有使用“工厂模式”和“工厂模式”。 “抽象工厂”,
由于需要更多代码。
祝你好运。
Its kind of tricky situation because the concepts like "Books", "chapters", "sections", may have some common elements that suggest a class hierarchy or common interface implementation.
And at the same time, enough different to be handle as different classes / objects, at all, as the requirement of "so you couldn't add a chapter to a story based on books".
When dealing conceptualy with hierarchical objects, there are several approaches of how to turn them into into code, each one suits better to a particular situation.
1. Class Composition
There is a class or prototype for each concept, they may be related or not by inheritance or interfaces.
There are internal collections of the elements, and their operations can be restricted,
by methods.
These approach is good when there are not many different classes, maybe 5.
2. The Tree Design Pattern.
These one applies when all elements will be equal if not similar,
usually same class or interface, usually a lot of items.
These one does not apply to your case, but,
I had to mention, to apply better.
Usually, a tree / hierarchical collection class, its used.
It could be a subclass of a generic / template tree collection,
or a subclass of a base tre collection,
that is intended to be replaced by child classes with particular members.
3. The Hybrid.
These one is a combination of the previous two,
its used when there is a lot of related items,
its more complex, may use or not the Factory & Abstract Factory Patterns,
and its more common example are visual controls & widgets libraries.
You may notice that I didn't use the "factory pattern" & "abstract factory",
due to require more code.
Good Luck.
好的面向对象设计从考虑用例开始,而不是类层次结构。这是一个常见的错误,并且往往会产生过于复杂的设计。
首先考虑您正在构建的内容,并使用问题领域的语言使用英语散文写出问题陈述,即您正在解决的问题的描述。
如果产品是 UI,则考虑制作模型。
然后,您可以开始编写用例并开始思考对象如何彼此交互。
这称为面向对象编程,而不是面向类编程。类是管理/创建/运行系统中所有对象的代码规范。我会思考物体以及它们在做什么。类只是一个实现细节。
如果您的目标是对层次结构执行操作,您可能需要考虑使用复合模式。您可以做一些事情,例如拥有一个包含 Story 对象列表的 Story 对象。每个 Story 对象也将有它自己的类型(书集、书籍、章节、子章节、段落、论文),以及它自己的属性和方法(取决于您的用例)。
Good OO design starts with thinking about Use Cases and not class hierarchies. This is a common mistake and tends to produce over-complicated designs.
First consider what you are building and write out a problem statement a description of the problem you are solving using English prose in the language of the problem domain.
Then consider making a mockup if the product is a UI.
Then you can start writing out use cases and start thinking about how objects will interact with each other.
It's called Object-oriented programming, not Class-oriented programming. Classes are the specification in code to manage/create/run all the objects in the system. I'd be thinking about objects and what they are doing. Classes are simply an implementation detail.
If your goal is to perform operations on hierarchies, you might want to consider using the Composite pattern. You could do something like have a Story object that can contain a list of Story objects. Each Story object would also have it's own type (book-collection,book,chapter,sub-chapter,paragraph,essay), and it's own attributes and methods (depending on your use cases).
我会尝试这样的事情:
现在你可以有一个书籍的故事或一个文本的故事。
警告:当尝试复杂化事情时,Java 泛型往往会失败。如有疑问,请忘记泛型和强制类型转换。
I'd try something like this:
Now you can have a Story of Books or a Story of Text.
Warning: Java Generics tend to fall flat on their face when trying to complex things. In case of doubt, just forget generics and cast.
感谢所有的海报。这是我正在进行的解决方案:
我尝试使用泛型来实现相同的目的,但由于需要反映容器的参数化类型,它看起来相当难看。
Thanks to all the posters. Here is my work-in-progress solution:
I tried using generics to achieve the same end, but it looked rather ugly due to need to reflect the parametrised type of a container.