访问者设计模式和观察者设计模式可以结合使用吗?

huangapple go评论80阅读模式
英文:

Can Visitor Design Pattern and Observer Design Pattern be combined?

问题

让我说,我有一个简单的Java程序,它读取一些文件并显示一些数据。

我感到困惑,我认为应该应用某种设计模式,但我不能决定要实现哪种。

这里是情景

每当我选择一个目录,我希望我的程序显示目录名称,所有文件列表和其他数据(如文件大小、文件扩展名等)。每当我点击一个文件名时,我希望我的程序显示其路径,如果它是图像文件,则预览它以及一些其他内容。

程序将在一个数据持有者类中保存数据:选定的目录(selectedDirectory)、该目录中的文件列表(filesInthatDirectory)、选定的文件(selectedFile)、JSON对象文件数据等等...

该程序将有许多用于显示的GUI对象:文本字段、面板、标签、列表。

传统的老方法是在单个方法中编写所有代码:*按按钮 -> 在actionListener中获取磁盘上的文件 -> 读取它们的名称和其他信息 -> 填充GUI对象的数据。这有点不好。

因此,我决定使用设计模式。然后,每当我点击此按钮并从磁盘读取数据时,我只会更新数据持有者类(例如,调用setSelectedDirectory、setFileData、fillCurrentFilesList等方法)。这些更新操作将触发执行所需GUI更新的类。

但我陷入了两种方法之间:

  • 使用观察者模式,我创建一些观察者,例如,当数据持有者的fileData(JSON)对象更新时,我将通知相关的文本字段,然后它们将显示正确的数据。

  • 但是使用访问者模式,一个访问者类将处理不同的对象,它将针对不同的GUI类运行不同的代码。JList将尝试显示List,或者某些文本字段将尝试解析JSONObject并仅显示相关的字符串。但我不需要很多不同的函数,我的意思是我只想让GUI对象显示一些数据,我的唯一的访问者类将是一个DisplayVisitor,它将期望GUI显示对象的唯一任务是显示数据。如果我需要doSomethingVisitor、doAnotherThingVisitor、doAmazingThingVisitor等类,那种方法可能很好,但我不需要其他函数。

这两种方法都能解决问题吗?我只是无法理解这种情况的区别。它们都提供了解决方案,观察者模式更简单,但它是否提供处理不同的GUI类,例如填充一个JList,Arraylist或使JLabel显示JPEG文件?

或者我可以结合使用这些模式吗?感谢阅读。

英文:

Let me say I have a simple Java program, which reads some files and displays some data.

I am confused, I think a pattern should be applied but I can't decide which one to implement.

Here is the scenario:

Whenever I choose a directory I want my program to display the directory name, all the files list and other data (like file sizes, file extensions etc.) Whenever I click a filename I want my program to display its' path, preview it if it is an image file and some other stuff.

The program would keep keep the data in a dataHolder class: File selectedDirectory, List<File> filesInthatDirectory, File selectedFile, JSONObject fileData etc...

That program would have many GUI objects for display; textfields, panels, labels, lists.

Classic old approach would be writing all the code in a single method *press a button -> inside the actionListener *get files from the disk, *read their names and other stuff, *fill the GUI objects with data. This is kinda bad.

So I decided to use a design pattern. Then whenever I click this button and read from the disk, I would only update the dataHolder class (setSelectedDirectory, setFileData, fillCurrentFilesList.. methods like these) And these update operations would trigger classes which will do the needed GUI updates.

But I stayed between two approaches;

-With Observer pattern, I create some observers, for example when dataHolder's fileData (JSON) object is updated I would notify related textFields, then they will display the proper data.

-But with Visitor pattern, a visitor class will handle different objects, it would run different codes for different GUI classes. JList will try to display a List<File> or some textFields will try to parse a JSONObject and display only the related String. But I do not need much different functions, I mean I only want the GUI objects to display some data, my only visitor class would be a DisplayVisitor which will expect the GUI display object's only job - display the data. If I needed doSomethingVisitor, doAnotherThingVisitor, doAmazingThingVisitor... classes that approach would be nice but I don't need another functions.

Do both approaches do the trick? I just can't get the difference for this scenario. Both of them offer a solution, Observer is more simple but does it offer handling different GUI classes like filling a JList with Arraylist<String> or making a JLabel displaying an jpeg File?

Or Can I combine these patterns? Thanks for reading.

答案1

得分: 1

我会说观察者模式更适合您的情况。访问者模式适用于您希望向某些对象添加功能的场景,而您可能无法或不希望修改这些对象。

英文:

I would say that the Observer pattern is more suitable for your case. The Visitor pattern is for scenarios when you want to add functionality to some objects that you can't/don't want to modify.

huangapple
  • 本文由 发表于 2020年8月26日 03:00:04
  • 转载请务必保留本文链接:https://go.coder-hub.com/63585474.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定