BlogJava-liuyf8688-文章分类-架构设计http://www.blogjava.net/liuyf8688/category/54098.htmlzh-cnMon, 06 Jan 2014 06:32:42 GMTMon, 06 Jan 2014 06:32:42 GMT60谦卑的架构师http://www.blogjava.net/liuyf8688/articles/408543.html风沙风沙Mon, 06 Jan 2014 01:17:00 GMThttp://www.blogjava.net/liuyf8688/articles/408543.htmlhttp://www.blogjava.net/liuyf8688/comments/408543.htmlhttp://www.blogjava.net/liuyf8688/articles/408543.html#Feedback0http://www.blogjava.net/liuyf8688/comments/commentRss/408543.htmlhttp://www.blogjava.net/liuyf8688/services/trackbacks/408543.html
原文地址：http://architects.dzone.com/articles/humble-architects
谦卑对于软件架构师来说不是一个很常见的特征。在参与过一些让人敬畏的架构后，并且最近还参与过一个令人愉快的项目，我以每个架构师都比较喜欢的方式总结了一些经验：作为一套规则。
规则0：不要装糊涂（Don't assume stupidity）
就像一些架构师假定开发人离开他们自己的设备，表现的将像个猴子。在我的经验里，这是很少会发生的。我只看到过一种开发人员做事时犯糊涂的情况，就是默默的抗议和反对架构师。如果你认可这个规则，接下就是一些细节。
规则1：你可能是错的（You may be wrong）
当审阅一些人的设计理念时，我更喜欢开诚布公的尝试问一些问题。我认为开发人员可能忽略了一个关键点，如并发。这儿有一些应对这些场景的方法：
1. 架构师：“你不能那样做，因为他可能破坏代码设计准则。”
2. 架构师：“你不能那样做，因为在多用户情况下，他是不安全的。”
3. 架构师：“你是否想过多用户时，他如何工作呢？”
4. 架构师：“你的方案如何应付多用户场景呢？”
亲爱的架构师：请从最不可能到最有可能得到一个尽可能好的系统的角度来评估这些方法。（提示：尽管有许多架构面对这个问题经常失败，但这真的是一个项很容易的工作。）
规则2：谨慎选用技术（Be careful with technology）
每种技术都会带来成本。大部分技术只能带来很小的益处。
这儿有一个我所经历过的成本大于益处的技术列表，因此将永不再使用（如果你不知道他们，也不用担心。关键是数量。）：JavaServer Pages, Java Server Faces, JAX-WS, Hibernate, Spring, EJB, Oracle SOA Server, IBM WebSphere, Wicket, Google Web Toolkit, Adobe Flex, JBoss jBPM, JMS（all implementations）, JBoss。
这儿有一个我比较愿意使用的技术列表：JUnit, Jetty, Joda-time, Java Standard Edition。
这儿有一个你可能想要尝试或模仿的谦虚的交流方式：
架构师：你应该使用X技术。
我：我注意过X技术，我不认为他能帮助我解决业务问题。
架构师：你想表达的意思是什么呢？
我：哦，我需要做：...，这些是X技术假设的：...；我不认为他们匹配得上。
架构师：那么你建议使用什么来替代他呢？
我：嗯...，我认为我们可以使用普通的Java来解决它。事实上，我昨晚做了一个非常好的demo来证明其可行性（I made a pretty good proof-of-concept yesterday evening.）。
受人尊敬的架构师：很酷，让我们用它吧。
规则3：一致性不像你认为的那样重要（Consistency isn't as important as you think）
如果我有一便士，每次我都将会听到...
架构师：“是的，我觉得这种方式可能比较笨，但你必须这样做。你是知道的，如果不这样做，系统会产生不一致并且是不可维护的”
相当然吧，我不常常做维护工作，但是我处理任何系统时，最困难的部分通常是理解系统的业务逻辑。X系统（有一套业务逻辑）还是Y系统（另一套业务逻辑）是不是一致性的问题在让我失眠的任务列表中优先级都是被排的比较低的。
事实上，X系统是非常复杂的，因为他有十二层且每层都要和Y系统一致。现在这让我特别生气。不同的上下文环境有不同的权衡。
哦，是的：还记得规则0吗？假如在一个给定的环境中，开发人员尝试为这个环境创造一个好的解决方案。
哦，是的，另一件事：我从未见到过一个小的可维护的东西复杂到难以理解。复杂只是因为我们让他发展壮大造成的。
哦，好的，还有另外一件事：如果因为开发人员中一些使用这样的花括号方式，另外一部分使用另一种花括号方式编程，而导致开发人员大吵着远离编码。我将失去所有对人性的信仰。
规则4：自底向上的一致性不如从上到下的一致（Bottom-up consistency beats top-down consistency）
这儿有一种我有能力创建系统内部一致性的方法：
1. 使用更容易被沿用，而不是使用具有突破性的架构来创建一个参考应用。如果你这样做的话，在遇到一些偏离架构的想法时，除非他们真的需要，在这种情况下他是非常好的，否则开发人员将会摇头。
2. 培训一种交叉交流的文化（Foster a culture of cross-pollination）：彼此互相看代码的开发人员一致性要比仅仅看他自己代码的开发人员更好。结对编程（Pair programming），代码review（Code reviews）和培训交叉技术分享会（Tech sharing sessions all foster cross-pollination）。
规则5：跨系统的策略重用不是最优选择（Tactical reuse in across systems is suboptimization）
重用将会产生耦合。如果系统X和系统Y重用了一些功能，系统X需要对功能进行修改，这将会影响到系统Y。但至少，工作在系统X的团队必须决定对重用的功能做一份私有副本。那意味着他不再被真正的重用。在极端情况下，由于对重用功能的修改，将造成系统Y产生bug。
当你跨系统重用时，那应该是稳定的（例如，Java SE平台或别的东西，如此稳定，你不需要自己动手做它）或策略性的内容。关于策略重用，是指整合信息但不是仅仅复制功能的服务。
换句话说：重用应该是要不被使用，要不被集成。副本是你的朋友。
规则6：分辨规则和教条（Separate between rules and dogma）
有三种原因使用这个任何编码规范中都有的规则：
1. 不安全（Unsafe）：代码在某种场景（真实存在，非理论上）中会出现bug
2. 令人费解（Incomprehensible）：“我”不理解这是怎么回事
3. 旁门左道 （Heresy）：使用了大家都不喜欢的方式来写代码
抽查测试：是否你有这样一个规则，“所有属性必须有注释”。关于安全问题，关于易理解问题或是旁门左道？使用这个例子做为标准：
/**
 * Contains the name value of the object
 */
private String name;
关于“在左花括号前面没有换行”规则？关于“花括号样式应该统一”的规则？是否符合不安全代码，不易理解或旁门左道？
我们应该更关注在特定场景下写适当的代码，少关注一致性。
最后：谦卑（Be humble）
在我从事软件开发的那些年里，我见过到软件架构师的伤害要多于帮助。做为一个职业角色，如果我们解雇他们（我们自己），我们将节省很多钱。那怕我们仍付给他们薪水。
如果你工作在一个他们造成的伤害要多于他们所能阻止，你有两个选项：你可以尝试改善或在没有人的时候祈祷。


风沙 2014-01-06 09:17 发表评论
]]>面向对象六原则http://www.blogjava.net/liuyf8688/articles/408469.html风沙风沙Sat, 04 Jan 2014 01:19:00 GMThttp://www.blogjava.net/liuyf8688/articles/408469.htmlhttp://www.blogjava.net/liuyf8688/comments/408469.htmlhttp://www.blogjava.net/liuyf8688/articles/408469.html#Feedback0http://www.blogjava.net/liuyf8688/comments/commentRss/408469.htmlhttp://www.blogjava.net/liuyf8688/services/trackbacks/408469.html1.单一职责原则(Single Responsibility Principle: SRP)
应该有且仅有一个原因引起类的变更。
===========================================================
There should never be more than one reason for a class to change.
注：该原则主要用在接口、类和方法中。
2.里氏替换原则(Liskov Substitution Principle: LSP)
如果对每一个类型为S的对象o1，都有类型为T的对象o2；使得以T定义的所有程序P在所有的对象o1都替换成o2时，程序P的行为不发生任何变化，那么类型S的类型T的子类型。(所有引用基类的地方必须能透明的使用其子类的对象)
===========================================================
If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged where o1 is substituted for o2 then S is a subtype of T.(Functions that use pointers or references to base classes must be able to use object of derived classes without knowing it)
注：
(1)子类必须完全实现父类的方法(如果父类的某些方法在子类中已经发生“畸变”，则建议断开父子继承关系，转而采用依赖、聚集、组合等关系代替继承)
(2)子类可以自由扩展，子类对象可以代替父类，但父类对象不能代替子类对象
(3)子类覆盖或者实现父类的方法时输入参数可以被放大(子类中的方法输入参数可以和父类方法的输入参数同类型，或者是父类方法输入参数的父类型。保证如果子类与父类构成重载时传入子类对象调用的方法仍是父类的方法，如果子类重写了父类的方法，则传入子类对象调用的方法是子类的方法)
(4)覆盖或实现父类的方法时输出结果(返回值)可以被缩小(子类覆写或实现的方法的返回值必须与父类对应方法的返回值同类型或者是父类对应方法的返回值类型的子类)
3.依赖倒置原则
原则1：高层模块不应该依赖低层模块，两个都应该依赖抽象
原则2：抽象不应该依赖细节，细节应该依赖抽象
4.接口隔离原则
接口隔离的定义
(1)客户端不应该强行依赖它不需要的接口(Clients should not be forced to depend upon interfaces that they don't use)
(2)类间的依赖关系应该建立在最小的接口上(The dependency of one class to another one should depend on the smallest possible interface)
===========================================================
这里的接口是指：
(1)对象接口(Object Interface)
(2)类接口(Class Interface)
===========================================================
接口隔离原则使用时的规范：
(1)接口尽量小
(2)接口高内聚
(3)接口设计有限度
5.迪米特法则(Least Knowledge Principle: LKP)
“最小知识原则”，一个对象对其它对象有最少的了解，即一个类应该对自己需要耦合或调用的类知道得最少，只需要知道它所提供的接口就行。
===========================================================
过分使用迪米特原则，会产生大量这样的中介和传递类，导致系统复杂度变大。所以采用时要反复权衡，既做到结构清晰，又要高内聚低耦合。
6.开闭原则
用抽象构建框架，用实现扩展细节。

风沙 2014-01-04 09:19 发表评论
]]>