基于组件开发为SOA提供了一些理论基础。据说下面这两些书不错。 Component-Based Software Engineering: Putting the Pieces Together Component Software: Beyond Object-Oriented Programming Component-Based Development for Enterprise Systems" by Paul R. Allen Component-Based Software Development" by Kung-Kiu Lau 基于组件的企业级开发 by Peter Herzum, Oliver Sims
作者：Meilir Page-jones 1. 面向对象软件的可理解性和可维护性，以及其它一些特性都是以封装性和Connanscence为基础的 2. 包：里面的类来自同一领域，但它们未必相互发生影响；组件：里面的类相互作用完成一系列业务逻辑 (启示：平时应该注意把内聚、耦合这种理念扩展到对象之外，扩展到包、组件或者更高的级别) 3.高内聚/低耦合并不是oo的专利，在结构化时代就已有比较系统化的研究；这方面可以看作者的另一本经典书籍：’practical guide to structured systems design’，它里面提出的一些东西在OO时代照样有用. 4. Encumbrance: 一个类的encumbrance就是它直接引用和间接引用的所有类的数量。 越低层次的类，它的encumbrance就应该越小； 越高层次的类，它的encumbrance就应该越大。 5.一些错误的内聚： a.混合事例型内聚：比如在“几何图形”这个类里搞一个“对角线”属生就是这种不当内聚，因为虽然四边形有对角线，但三角形并没有对角线。 b.混合领域型内聚：比如在“实数”这个类里写一个“华氏温度转摄氏温度”的方法，这样做会从扩大一个类的encumbrance,引入不相关的领域，导致可重用性降低 c.混合角色型内聚：比如在“人”这个类里写一个“拥有狗的数目”的方法。人和狗可能都属于业务领域，但人和狗完全是不同的角色。
越来越感觉到，弱耦合性是系统可维护性的关键, 有必要研究一下各种耦合的形态及相应解耦手段。 Robert C. Martin 在他的《敏捷软件开发》里提出了很多面向对象的原则，《代码大全》里也有一些，本质上都是为了实现弱耦合。 对耦合这个概念本身贡献最大的人可能是Meilir Page-Jones，他在他的《UML面向对象设计基础》中使用了connascence这个词(单词里的第一个a发/ei/音)。 Connascence就是Coupling的同义词，Page-Jones给出了它的定义，还指出了它有几种类别。 另有一个叫 Jim Weirich的Ruby高手对connascence非常感兴趣。他把它称为OO理论中的Grand Unified Theory(物理学术语). 他在一次演讲中专门介绍了这个东西，并有一定的展开。 我本想找一本专门讲弱耦合的书，但可惜目前没有； 于是只好自己研究一下上面提到的材料，下面是一些笔记。 附资源： connascence的wiki页面： http://en.wikipedia.org/wiki/Connascent_software_components Meilir Page-Jones的书：Fundamentals of Object-Oriented Design in UML, 看第三部分就好 Jim Weirich的演讲：http://confreaks.net/videos/77-mwrc2009-the-building-blocks-of-modularity ==================================================================== Connascence的定义：两个软件元素A和B之间，如果A改变，B也就必须改变, 或者当某第三方元素发生改变时，A和B必须同时改变。 ———————————————————- 各种Connascence: 静态Connascence： 1. connascence of name methodA()改名为methodB()时, 调用methodA()的地方都要改名 2. connascense of type or class 如果变量从值100变成了一个很大的数, 则变量类型可能要从int改成BigInteger 3.connascense of convention magic …
两个jar库之间不应该互相依赖,否则两个jar包都不能独立编译
Ubuntu下用sudo运行java程序时,要注意此时用户目录为/root,而不是/home/ yourname之类的 如果没注意到这一点,就可能会遇到这样一种情况: 某个java相关的组件把某些配置默认放在/home/ yourname,而你用sudo启动的java程序却又去/root下找这个文件,结果没找到; 而如果相关的模块又不报错或者不够高调的报错,你就很难发现错在哪里. 我今天就遇到了这种情况: eclipse默认把embedded jrebel的license文件配在/home/kent下, 而我启动jboss时又用了sudo. 搞得我折腾了很久才发现错误.
因为互相调用可能会造成执行时的无限循环,比如 1.Component A下面的 service A1 调用了 Component B下的service B1 2.Component B下面的 service B2 调用了 Component A下的service A2 这样看没什么问题; 但某一天某个不知情者让B1调用了B2,另一个不知情者则让A2调用了A1, 就有可能在执行时造成 A1 -> B1 -> B2 -A2 -> A1 这种无限循环
1.gnome terminal会把标题强行置为user@host, 所以第一步是去掉这个强制: vi ~/.bashrc,然后注掉下面这段代码 If this is an xterm set the title to user@host:dir case "$TERM" in xterm*|rxvt*) PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1" ;; *) ;; esac 2.安装xttitle (注意x后面有两个t) 3. xttitle "The title"
1.研究下: MySql开发的36条军规 2.淘宝技术大学放出的 java中间件 pdf 3.connanscence 研究
《软件架构设计》 温昱 ============================================ 等分析完所有需求才进行架构设计，一般是来不及的；应该针对关键性需求在有限的时间内做出可用的架构设计。至于非关键性需求，可以把它们用来验证架构：从每项非关键需求的角度对架构方案进行走查。 那么哪些需求是关键性需求？ 1.约束，因为它们必须被满足 2.关键Use Case 3.需求方眼里的高优先级需求 4.对系统受认可程度有较大影响的质量属性
《软件架构设计》温昱著 ================================================= 非功能需求可分为： 1.约束 2.质量属性 a.运行期质量属性 b.开发期质量属性 先说下约束。约束会从三种途径影响设计： a.设计可以直接遵守约束，比如“必须运行在Linux上” b.约束转换为功能性需求，比如“系统必须严格按人行利率执行” => “必须提供利率调整的功能” c.约束转换为非功能性需求，比如“操作者的计算机水平不高” => “必须有良好的易用性” 关于质量属性，作者创新地把它们分为运行期属性和开发期属性： a.运行期: Performance, security, usability, availability, scalability, interopreability,reliability, robustness b.开发期: Understandability, extensibility, reusability,testability, maintainability(可被修改的难易程度), portability