jeseeqing's technology roadmap

剖析SharpDevelop：Command模式的应用    

SharpDevelop是一个非常优秀的开源项目，其中有一些思想非常出色的，如插件结构，服务设计，设计模式的应用，UI与行为的抽离，以及可插入式的设计结构, 其中有些设计思想我已经应用到我以前开发过的一些项目中。由于我的文笔不好及工作太忙，所以一直没有写什么心得之类的笔记。现在有点时间，也来记录一下我的分析随笔，先来分析一下SharpDevelop中模式的应用，至于其非常优秀的插件结构，博客园已有兄弟作过分析了。

           在剖析Command模式之前，先来看一下.NET Framework中的菜单及工具栏处理存在的一些缺点：

1.            无法自动同步更新菜单项与工具项的状态以及相关的行为及特性，需要手动去处理两个事件，从而造成了相同的两个操作需要两次处理，也就造成了需要手动地同时维护多份相同的操作；

2.            无法重用菜单项这部分的功能，因为在dotnet中菜单项的单击需要集成在UI中；

3.            无法很好地扩展，如需要增加或删除菜单项，则需要更改原有的代码及UI部分的设计，从而违反了OCP(开闭)原则。按照OCP原则，当扩展相关的功能时，不应该修改原始的代码，而应该扩展该代码；

4.            无法将相关的消息当作原子状态处理，试想一下，如果一个系统不仅通过菜单、工具栏来操作用户接口，也可通过命令（如Visual Studio就可以通过输入命令而执行相关的操作）来执行，如果不将相关的操作抽象出来的话，维护这个操作的成本太大。并且如果想实现更进一步的控制比如精确到原子状态的权限控制，则很难实现。

我们可以运用Command模式，将菜单项相应的操作抽象出来，定义一个命令接口ICommand，此接口仅具有Run方法，可以作为任何命令的基接口。但是由于菜单还具有一些其它的特性，如是否可见，是否可用，文本，需要执行此菜单项的宿主，所以再定义了一个IMenuCommand接口继承此接口，加入了一些新的特性，并定义了一个实现IMenuCommand接口的抽象基类MenuCommand，其它类可以派生此类。由于我自已修改了SharpDevelop中的一些设计，所以可能有些与原版的不一样。

 
          ICommand接口：是一个最基本的接口，代表一个动作的行为；

IMenuCommand接口：派生于ICommand接口，作为菜单项或工具项所实现的行为及特性来使用；

IStatusUpdate接口：描述一个能够更新状态的接口，当对象需要更新状态时将调用此接口，如菜单项需要动态地更新Enable，Visible特性；

MenuCommand抽象基类：实现了IMenuCommand接口，任何菜单命令可以从此继承；

CustomCommandBarItem：继承于CommandBar组件的CommandBarButton类，类似于菜单项或工具项，实现了IStatusUpdate接口，以根据IMenuCommand接口的Visible、Enabled属性的改变而相应地更新其Enabled,Visible属性；

CustomCommandBarMenu：继承于CommandBar组件的CommandBarMenu类，类似于菜单条。           
    当我们在客户端需要创建命令时，只需写相关的类继承于MenuCommand         
        

           在这里使用了另外一个开源组件CommandBar。CustomCommandBarItem类的构造函数通过传入一个IMenuCommand类的实例与IMenuCommand关联起来，将单击事件(OnClick方法)委托给ICommand接口的Run方法来执行，其Update方法用于更新状态。CustomCommandBarMenu类中的OnDropDown方法用于当打开菜单条时通过调用IStatusUpdate的Update方法自动更新所有菜单项的状态。

           在SharpDevelop处理所有插件的菜单中，此处的设计是支持的基础。

           如果更进一步，可以在SharpDevelop中加入类似于Visual Studio的“命令窗口”；如果是一个ERP系统或MIS系统，可以将权限控制写在IMenuCommand中的Enabled中，在执行Run方法之前先检测Enabled，如果Enabled为false则禁止执行，我先前写过一个权限框架，通过Attribute及Reflect技术来实现权限的自动控制。

           Reference:

1.            吕震宇的设计模式系列文章

2.            GoF的Design Pattern

1月7日的会议我因为后来有点事，参加了10多分钟后来退出去了，对此表示抱谦。对于这次会议的成果，我只能通过会议记录总结了

看到Wayfer说到GMail的事，我也来派发GMail。

申请到GMail已经差不多1个多月了，虽然其号称1G，但由于测试其间速度太慢，所以也就很少使用。

现在手上有5个邀请，谁要的话留下email及其firstName,lastName。

希望Google的东西永远是好东西，最近Google发布了Google Desktop Search，用于搜索桌面上的信息，可以与Google在线的集成。

谁要的话留给email，最后更新日期：2005.8.15日

C# Programming Guidelines（摘录）

1. Elegance Always pays off.

2. First make it work, then make it fast.  在敏捷开发中，有一条原则：Keep it simple

3. Remember the "divide and conquer" principle.

4. Separate the class creator from the class user (client programmer)

5. When you create a class, attempt to make your names so clear that comments are unnecessary.

6. Your analysis and design must produce, at minimum, the classes in your system, their public interfaces, and their relationships to other classes, especially base classes.

7. Automate everything. 类似于敏捷开发中的Continue Integrated.

8. Write the test code first (before you write the class) in order to verify that your class design is complete. 类似于敏捷开发中的Write Test First

9. All software design problems can be simplified by introducing an extra level of conceptual indirection.

10. An indirection should have a meaning.

11. Make classes as atomic as possible.  单一职责原则(SRP)很好地解释了这一点，SRP可以理解为为“就一个类而言，应该仅有一个引起它变化的原因”，详细信息请参阅《Agile Software Development Principles, Patterns, and Practices》；

12. Watch for long argument lists. 可以使用重构中的Introduce Parameter object（引入参数对象）来重构代码，关于重构，请参阅《Refactoring: Improving the Design of Existing Code》

13. Don't repeat yourself. 不要使你的代码有Duplicated Code坏味道，当有后可以使用重构中的Extract Method手段来重构代码；

14. Watch for switch statements or chained if-else clauses. 不要使你的代码有Switch Statements坏味道，当有后可以使用重构中的Replace Conditional with Polymorphism手段来重构代码；

15. From a design standpoint, look for and separate things that change from thins that stay the same.

16. Don't extend fundamental functionality by subclassing.

17. Less is more.

18. Read your classes aloud to make sure they're logical.

19. When deciding between inheritance and composition, ask if you need to upcast to the base type.

20. Use data members for variation in value and method overriding for variation in behavior.

21. Watch for overloading.

22. Use exception hierarchies;

23. Sometimes simple aggregation does the job.

24. Consider the perspective of the client programmer and the person maintaining the code;

25. Watch out for "giant object syndrome."

26. If you must do something ugly, at least localize the ugliness inside a class.

27. If you must do something nonportable, make an abstraction for that service and localize it within a class.

28. Objects should not simple hold some data.

29. Choose composition first when creating new classes from existing classes;

30. Use inheritance and method overriding to express differences in behavior, and fields to express variations in state.

31. Watch out for variance;

32. Watch out for limitation during inheritance.

33. Using design patterns to eliminate "naked functionality.";

34. Watch out for "analysis paralysis.";

35. When you think you've got a good analysis, design, or implementation, do a walkthrough.

Implementation

36. In general, follow the Microsoft coding conventions.

37. Whatever coding style you use, it really does make a difference if your team (and even better, your company) standardizes on it.

38. Follow standard capitalization rules.

39. Don't create your own "decorated" private data member names;

40. Follow a "canonical form" when creating a class for general-purpose use.

41. Sometimes you need to inherit in order to access protected members of the base class.

42. If two classes are associated with each other in some functional way (such as containers and iterators), try to make one an inner class of the other;

43. Anytime you notice classes that appear to have high coupling with each other, consider the coding and maintenance improvements you might get by using inner classes;

44. Don't fall prey to premature optimization;

45. Keep scopes as small as possible so the visibility and lifetime of your objects are as small as possible.

46. Use the containers in the .NET Framework SDK.

47. For a program to be robust, each component must be robust.

48. Prefer compile-time errors to run-time errors 尽可能地将错误在编译阶段解决;

49. Watch for long method definitions;

50. Keep things as "private as possible"; 应尽量少暴露外部接口给用户

51. Use comments liberally, and use the comment-documentation syntax product your program documentation.

52. Avoid using "magic numbers"; 应该使用常量来代替

53. When creating constructors, consider exceptions.

54. If your class requires any cleanup when the client programmer is finished with the object, make your class implement IDisposable interface;

55. When you are creating a fixed-size container of objects, transfer them to an array;

56. Choose interfaces over abstract classes;

57. Inside constructors, do only what is necessary to set the object into the proper state;

58. Watch out for accidental overloading;

59. Watch out for premature optimization;

60. Remember that code is read much more than it is written;