本来想就我要说的几个问题单独开帖的。但是考虑到关心GUI的人本来就不多，而且网络又是快餐文化，还是一次性的杂述一些我关于GUI的想法。
关于GUI，比如windows下如何开窗口啊，MFC，别的什么库之类的，我相信很多朋友都很了解了。GUI的库，事件驱动也应该很熟悉。RAD工具，诸如Delphi之类的用的人也应该不少。因此，我仅仅谈谈大家可能在专门学习GUI，而不是开发一个大型GUI时不大会注意的几个问题
1、GUI的表现单位是Frame
Frame应该是Delphi的词汇。在.net中应该是UserControl。其实就是拥有一个完整功能的GUI模块。平时用的控件是构成Frame的组件，而Frame则构成了整个GUI的控件。所以可以说Frame就是粗粒度的自定义控件
GUI应用靠Frame组合起来变成一个大的应用。Frame之间靠提供的接口，public属性和事件回调来达到交互的目的。
2、GUI的排版
在Delphi这样的工具中很容易忽略排版。排版在GUI中其实是一个很有挑战的工作。举一个最简单的例子就是你如何应对窗口的缩放？
对于GUI的排版，Java有Layout，.net有anchor docking，Delphi是绝对排版，GTK, TK这些有Box容器。基本上关于排版的解决方案是一个库一种，但是背后的基本原理其实都是一样的，通过某种属性限制，计算出正确的窗口位置。问题就出在到底用什么属性。关于这个问题我这里只是提示你注意一下，不要小视它。希望以后有机会单独开帖讲讲GUI中的排版
3、GUI是以界面为中心的
按照Alan Cooper的说法，软件设计应该由开发人员和界面设计人员完成。我现在越来越倾向于同意这种看法，界面设计不是普通程序员能够完成的。而最近与业内的一些工程师交流，普遍的感觉是“最乱的”就是表现层。
除了对人员的影响这个方面，界面为中心还深深的影响者表现层的技术和代码。在业务层我们往往会通过领域建模，以对象为中心来进行模块划分。但是这种划分的思想不能照搬到界面这块来，为此我付出了完全抛弃两版设计的代价才弄明白。界面就是围绕窗口交互来进行的，Frame就是表现层的划分。放到Web上来，页面就是划分。然后以这种分划为中心展开对后台代码的调用。而这个时候，DTO，模板，MVC等技术才得意登场。不过最基本的还是要把握住界面为中心。
希望通过小小一点杂述能够让你在以后有机会写比较大型的GUI应用时，想起我说过的话。
关于GUI，比如windows下如何开窗口啊，MFC，别的什么库之类的，我相信很多朋友都很了解了。GUI的库，事件驱动也应该很熟悉。RAD工具，诸如Delphi之类的用的人也应该不少。因此，我仅仅谈谈大家可能在专门学习GUI，而不是开发一个大型GUI时不大会注意的几个问题
1、GUI的表现单位是Frame
Frame应该是Delphi的词汇。在.net中应该是UserControl。其实就是拥有一个完整功能的GUI模块。平时用的控件是构成Frame的组件，而Frame则构成了整个GUI的控件。所以可以说Frame就是粗粒度的自定义控件
GUI应用靠Frame组合起来变成一个大的应用。Frame之间靠提供的接口，public属性和事件回调来达到交互的目的。
2、GUI的排版
在Delphi这样的工具中很容易忽略排版。排版在GUI中其实是一个很有挑战的工作。举一个最简单的例子就是你如何应对窗口的缩放？
对于GUI的排版，Java有Layout，.net有anchor docking，Delphi是绝对排版，GTK, TK这些有Box容器。基本上关于排版的解决方案是一个库一种，但是背后的基本原理其实都是一样的，通过某种属性限制，计算出正确的窗口位置。问题就出在到底用什么属性。关于这个问题我这里只是提示你注意一下，不要小视它。希望以后有机会单独开帖讲讲GUI中的排版
3、GUI是以界面为中心的
按照Alan Cooper的说法，软件设计应该由开发人员和界面设计人员完成。我现在越来越倾向于同意这种看法，界面设计不是普通程序员能够完成的。而最近与业内的一些工程师交流，普遍的感觉是“最乱的”就是表现层。
除了对人员的影响这个方面，界面为中心还深深的影响者表现层的技术和代码。在业务层我们往往会通过领域建模，以对象为中心来进行模块划分。但是这种划分的思想不能照搬到界面这块来，为此我付出了完全抛弃两版设计的代价才弄明白。界面就是围绕窗口交互来进行的，Frame就是表现层的划分。放到Web上来，页面就是划分。然后以这种分划为中心展开对后台代码的调用。而这个时候，DTO，模板，MVC等技术才得意登场。不过最基本的还是要把握住界面为中心。
希望通过小小一点杂述能够让你在以后有机会写比较大型的GUI应用时，想起我说过的话。
