设计模式一点感悟

Question

本人刚毕业在一家公司主要从事Java CS方向开发，经常要设计界面。可是界面的组件非常之多，维护起来相当吃力。了解了一点工厂的设计模式之后，打算做一个组件工厂，负责生产所有的界面组件。有2个设计方案，第一种是就一个工厂接口，一个工厂实现类，接口的每个方法都可以返回一个实用的组件（比如：JTable、JButton、JTextField等等）；第二种方法就是每种组件写一个工厂，例如：JButtonFactory、JTableFactory、JTextFieldFactory，JLabelFactory。然后写一个抽象工厂类UIFactory，根据这个抽象工厂类再来得到这些具体的工厂（JButtonFactory、JTableFactory、JTextFieldFactory，JLabelFactory）。第二种方案可能比较复杂点，但是后期维护应该很方便。但是又想到公司的界面设计都不是很复杂，都是一些简单的界面设计，做的也不是很漂亮，注重的是功能，有没有必要设计成方案二呢？就是不知道这2中方法那一种好些？在这里跟大家讨论下！设计模式java

Answer 1

维护起来相当吃力
接口的每个方法都可以返回一个实用的组件（比如：JTable、JButton、JTextField等等

这种需求需要牵扯到工厂设计模式吗？
不太了解LZ的项目背景
一般公司如果对JTable(JButton...)有定制的话，
做一个基类的Table继承自原生态的JTable
维护的时候只需维护这个基类,不会吃力

Answer 2

用第一种的话你最终会得到一个至少数千行，方法数不清的近乎无法维护的工厂类。即使第二种，单纯的工厂方法也还是有其局限性。有时可能直接用构造方法也很好。
有时可能用 Builder Pattern 更好。
看情况。好的控件设计应该满足：1 - 允许用户方便的定制数据模型，比如 JTable 和 JList，用户可以方便的写处他们自己需要的 TableModel, ListModel， ListSelectionModel ... 等等2 - 对外观友好，即尽量对 LookAndFeel 友好。工厂方法的话，我觉得甚至每一种组件的分支都独占一个包，有自己的工厂接口比较好，比如你做一个日期选择控件 JDatePicker，它自己就占一个包，对外接口可以有数据模型接口，工厂接口等。提供公共构造方法的好处是允许用户方便的用匿名类来写实现，比如 AbstractTableModel 这种。