比较的Java Swing的MVC与Android设计模式 [英] Comparing Java swing MVC with Android design pattern

问题描述

我在做设计模式的小研究在不同的平台上，我有在Java编程经验。

I'm doing a small research on design patterns in various platforms and I have prior experience in programming with Java.

在阅读这些文章： MVC模式在Android的和的 MVC中的Andr​​oid 架构，
我想到一个有趣的问题：为什么的Java Swing的MVC不能与Android开发模式进行比较？或为什么我们不能说Android的遵循MVC？ （总体而言，外观和感觉）。

While reading these posts: MVC pattern in Android? and MVC architecture in Android,
I had an interesting question in mind: Why Java swing MVC can not be compared with Android development pattern? or Why we can't say that Android follows MVC? (in the context of overall "look and feel").

在一个答案，有人澄清 MVC 作为：

In one answer, someone clarified MVC as:

• 型号：什么来呈现

查看：如何渲染

控制器：活动，用户输入

确定。好了，现在我的理解是：

OK. well, now what I understand is:

• 在的Java Swing的MVC，组件类是一个抽象类为所有 属性中的视觉环境。有一种独特的关键字被称为 控件用于某些组件如按钮，列表等。 因此，所有的控件和组件是 Model部分 MVC中。

• In Java swing MVC, component class is an abstract class for all attributes in visual environment. There is a distinct keyword called controls is used for some components such as buttons, lists etc. So, all controls and components are part of Model in MVC.

容器继承组件。有几个 布局管理定义布局部件和地点的 容器。还有一些监听器必须与注册 根据 EventSources 。所以，他们都在查看 MVC中。

Container inherits component. and there are several LayoutManagers that defines layouts and place of components in container. Also there are Listenershave to be registered with according EventSources. So, they all are the View in MVC.

类实现 Listener接口的方法中，我们把我们的主要 逻辑和有一些 EventClasses 的每个事件。他们都是 部分控制器 MVC中。

Class that implements Listener interface methods in which we put our main logic and there are some EventClasses for each event. They all are part of Controller in MVC.

将所有这些实施例一起实施于图像;在摇摆MVC 我们有：

putting all these examples together in an image; in swing MVC we have:

• 我觉得控件是相同控件在这里。此外，还有一些 其他 EventSources 。他们都充当型号

• I think widgets are same as controls here. Also, there are some other EventSources.They all act as a Model.

查看包有 viewgroups （也包含几种 布局）和监听器接口。它们都是部分 查看 MVC中。

View package has viewgroups (that also contains several kinds of layouts.) and Listener interfaces. they all are the part of View in MVC.

同摆动MVC中，我们可以说 Listener接口的方法和活动 部分控制器

Same as swing MVC, we can say Listener interface methods and activities are the part of controller.

将所有在一起的图像;在机器人我们有：

putting all together in an image; in Android we have:

根据以上比较，我认为下面的相似

As per above comparison, I consider following similarities:

• 容器 - 相同查看

布局管理器 - 相同的ViewGroup

监听器 - 在这两个结构相同的整体

Listeners - overall same in both architecture

控件 - 整体一样控件

事件代表团（注册适当的侦听器，事件源，然后执行监听器的方法） - 在这两个结构相同的整体

Event delegation (registering appropriate listener with Event source and then implementing Listener's methods) - overall same in both architecture

那么，谁能解释这是的东西，使得Android设计模式比Java不同的摆动MVC模式？
或者如果您认为两者是不同的东西（在设计模式用于发展的背景下），然后解释为什么呢？

So, can anyone explain which are the things that makes the Android design pattern different than Java swing MVC pattern?
or If you believe that both are different things (in the context of design patterns used for development), then explain why?

推荐答案

每个波段的JComponent具有的的ComponentUI 的是负责显示的组分。虽然JComponent中有一个paint方法，只有用户派生类直接使用 - 标准的实施往往只是<一href="http://grep$c$c.com/file/repository.grep$c$c.com/java/root/jdk/openjdk/6-b14/javax/swing/JComponent.java#JComponent.paintComponent%28java.awt.Graphics%29"相对=nofollow>呼叫连接UI的paint方法代替。这允许插件不同的外观和感觉的实现很容易 - 不同的外观和感觉只是提供了不同的ComponentUI的。很明显组成部分是模式，用户界面​​是视图。和Android没有继承这种分离非常明显的方式。例如，它的TextView似乎只是<一href="http://grep$c$c.com/file/repository.grep$c$c.com/java/ext/com.google.android/android/1.5_r4/android/widget/TextView.java#TextView.onDraw%28android.graphics.Canvas%29"相对=nofollow>绘画可绘制的时候了类似的JLabel具有的 UI 。

Each Swing JComponent has ComponentUI that is responsible for displaying a component. While JComponent has a paint method, only user derived classes use it directly - "standard" implementations very often just call the paint method of the attached UI instead. This allows to plug-in various look and feel implementations very easily - a different look and feel just provides different ComponentUI's. Very clearly component is the "model" and the UI is the "view". And Android does not inherit this decoupling in very obvious way. For instance, its TextView seems just painting drawables when a similar JLabel has UI.

但是，这是不是哪里MVC的方法是使用的唯一场所，以及其他一些特殊情况下，Android和摇摆MVC非常相似。例如，Android的的ListView 有一个模型（<$ C C $> ListAdapter ）非常像秋千 JList的的的ListModel 。在两种情况下，模型提供数据，同时组件本身提供可能性来显示。可能不同的是，摆有更多的组件，例如分离数据和presentation。 的JTable 和的JTree 有当Android不提供这些部件开箱同类机型。没有树的一切， TableLayout 是一个名为< A HREF =htt​​p://docs.oracle.com/javase/7/docs/api/java/awt/GridLayout.html相对=nofollow>网格布局 Swing中，没有类似的JTable 。

This is however not the only place where MVC approach is used, and for some other specific cases Android and Swing MVC are very similar. For instance, Android ListView has a model (ListAdapter) very much like Swing JList has ListModel. In both cases the model provides data while the component itself provides possibilities to display. The possible difference is that Swing has more components with such decoupled data and presentation. JTable and JTree have similar models when Android does not provide such components out of box. There is no tree at all, and TableLayout is a that is called GridLayout in Swing, not similar to JTable.

为无效，并重新油漆一般的方法是没有太大的不同，在这两个框架的唯一专用主线程可以触摸组件。此外，事件监听器（可能是另一组的控制器中）在Java和Android非常相似，它们之间的所有分歧很可能被称为微妙而已。

The general approach for invalidating and repainting is not much different and in both frameworks only dedicated master thread can touch components. Also, event listeners (probably other group of "controllers") are very similar in Java and Android, all differences between them could probably be called "subtle" only.

容器和布局管理也摇摆和Android之间颇为相似，在于摇摆的主要区别有它的布局管理在除机器人​​的的ViewGroup （类如的DatePicker ，而在的ViewGroup ，不是通用的布局管理器）。另外，Android的布局的一部分是连接codeD中的XML，而Swing是一般普通的Java而已。如果布局管理器也是一种控制器响应，如缩放或重新定位的事件，这部分是非常相似完成。但是我不知道，如果布局管理器是真正的控制器，因为他们更新更认为比模型。

Containers and layout manages are also quite similar between Swing and Android, the main differences being that Swing has much more possible implementations of its LayoutManager to choose from than Androids ViewGroup (classes like DatePicker, while derived from ViewGroup, are not general purpose layout managers). Also, part of Android layout is encoded in XML while Swing is typically plain Java only. If layout managers are also kind of "controllers" responding to events like resizing or reorientation, this part is very similarly done. However I am not sure if layout managers are really "controllers" as they update more the view than the model.

在一般情况下，摇摆，似乎对于大型，复杂的图形用户界面，显示了一个大屏幕上时，Android是更适合于只有几个有形成分的小屏幕，大到足以用手指没有手写笔操作更加优化。

In general, Swing seems more optimized for the large, complex GUI that shows up on a large screen when Android is better suited for small screens with just a few visible components, large enough to be operated with fingers without stylus.

这篇关于比较的Java Swing的MVC与Android设计模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！