因为已突破原帖子主题“对结构型设计模式的理解”本身含义，所以转移出来
jamesby 写道
qinysong 写道
jamesby 写道
qinysong 写道
jamesby 写道
我觉得降低偶合，也就是解偶是关键，底偶合高内聚，高扩展，高复用是软件设计的目标。
我觉得“底偶合高内聚”应该在设计原则层次，通过原则指导利于达到设计目标——“高扩展，高复用”
面向接口和抽象编程
优先使用组成而不是继承,也就是HAS A OR IS A 等等,
而遵守设计原则的软件就是高内聚底偶合的设计,也就是高扩展，高复用的设计!
我认为高扩展，高复用是终极目标,但是达到了高内聚底偶合的目标也就达到了高扩展，高复用的目标.
嗯，非常好，这样的讨论非常促进我的认识
我想再引入一个词——属性，一个好的软件，一个最大限度接近优秀目标（高扩展，高复用）的软件本身应该具有一些基本属性，就像高尔基说的“不幸的家庭各有各的不幸，而幸福的家庭都是相似的”，软件也是，不好、劣质的软件各有各的不好之处，而优秀的软件（从设计角度来说）却都具有基本的属性，这些属性中我觉得就可以包括“高内聚、底偶合”。
所以“高内聚、底偶合”这是优秀软件的基本属性，而目标是表达我们最大渴望的主观意愿，一个软件只要高扩展，高复用我们就满足了，在这个满足的前提下我们不在乎是不是高内聚低耦合。但是幸福的家庭都是相似的
是不是也可以这样理解，软件的终极目标，就是复用。
可复用的软件一定是可扩展的，可扩展的一定具有高内聚、底偶合的特点。
而软件设计原则是达到这个目标的通道。设计模式是这个终极目标的表现方式。
我觉得软件设计有两个大的目标：
第一个：可重用性。可重用性通过复用之前的劳动成果提高了生产效率，降低了成本；
第二个：可维护性。可维护性通过延长系统的使用寿命，增值了产品价值；
要想设计达到这两个目标，系统就需要有一些特性
包括可读性、高灵活性、易扩展性、通用性、可移植性，这些特性是一个系统表现出来的，可概括为“白箱特性”：），而系统内部也要有一些属性，如高内聚、低耦合，这些内部属性更侧重内部结构性，概括为“黑箱属性”。
为了使一个系统具有那些优秀的特性，有一些手段，或者称为方法
这些方法/手段包括抽象（提高通用性）、封装（增强内聚性）、分离（降低耦合性）等等
当对这些方法/手段进行细化、分类、概括时，就产生了一些设计原则/准则
比如面向接口编程、优先使用对象组合、SRP单职责准则、OCP准则等等
这些准则/原则在一定场景下的经典表现方式，就产生了设计模式
以上是个人理解，因为这种层次的划分包括大量的理解上、语义上的因素，所以每个人的划分可能会有不同，不过我感觉这样的划分虽然可能因人而异，但是他可以让我们有一个全局观念，所以还是很有意义的
大家多批评
1 楼 jamesby 2007-04-04
我觉得软件的可重用性更重要，围绕可重用性会有很多东西，包括可重用性也分很多层次。
代码级别的重用，
设计的重用，
组件的重用。
框架的重用。
Service的重用(WebService，或者EJB)。
虽然很多人反对使用EJB,但是我仍然觉得EJB是Service级别的重用的不错的方式，当然有人会说用webservice更好。因人而异。
当然可维护性也很重要，但是我觉得相对于重用来说它占的比重很底。
如果能够将如上这么多级别的重用使用好。那设计出来的软件一定是个不错的软件（从重用的角度考虑）。
代码级别的重用，
设计的重用，
组件的重用。
框架的重用。
Service的重用(WebService，或者EJB)。
虽然很多人反对使用EJB,但是我仍然觉得EJB是Service级别的重用的不错的方式，当然有人会说用webservice更好。因人而异。
当然可维护性也很重要，但是我觉得相对于重用来说它占的比重很底。
如果能够将如上这么多级别的重用使用好。那设计出来的软件一定是个不错的软件（从重用的角度考虑）。
2 楼 xly_971223 2007-04-04
可重用性是软件设计的终极目标。 小到一行代码 一个方法， 大到一个类 一个模式 一个子系统
可维护行当然也很重要 毕竟在软件生命周期中，维护占的比例是非常大
那么可重用行跟可维护性之间有什么关系呢？是不是复用度高的的软件可维护性就高呢？
复用度高的程序--->内聚性强--->可维护性高
复用性高的程序其内聚性一定强，内聚性强的程序则更容易维护
软件设计还有一个目标是可扩展性，那么扩展性跟重用性 维护性之间又有什么关系呢？
可维护行当然也很重要 毕竟在软件生命周期中，维护占的比例是非常大
那么可重用行跟可维护性之间有什么关系呢？是不是复用度高的的软件可维护性就高呢？
复用度高的程序--->内聚性强--->可维护性高
复用性高的程序其内聚性一定强，内聚性强的程序则更容易维护
软件设计还有一个目标是可扩展性，那么扩展性跟重用性 维护性之间又有什么关系呢？
3 楼 qinysong 2007-04-05
xly_971223 写道
那么可重用行跟可维护性之间有什么关系呢？是不是复用度高的的软件可维护性就高呢？
复用度高的程序--->内聚性强--->可维护性高
复用性高的程序其内聚性一定强，内聚性强的程序则更容易维护
复用度高的程序--->内聚性强--->可维护性高
复用性高的程序其内聚性一定强，内聚性强的程序则更容易维护
对于可重用性和可维护性之间的关系，我也一直琢磨不定，到底是应该把这两者放到一个层次，还是把可维护性作为可重用性自身的一个连带属性，起初我也和xly_971223以及jamesby具有相同的看法——重构是软件设计的终极目标，但是《重构-改善既有代码的设计》第13章Wiliam的经历让我提升了可维护性的重要性，对于较大的项目以及版本需要不断升级的产品，可维护性就变得相当重要。
下面是那一节的引文，因为手边只有英文的电子文档，所以就把相关的段落拷贝下来
引用
13.1 A Reality Check by William Opdyke
I worked at Bell Labs for several years before I decided to pursue my doctoral studies. Most of
that time was spent working in a part of the company that developed electronic switching
systems. Such products have very tight constraints with respect to both reliability and the speed
with which they handle phone calls. Thousands of staff-years have been invested in developing
and evolving such systems. Product lifetimes have spanned decades. Most of the cost of
developing these systems comes not in developing the initial release but in changing and
adapting the systems over time. Ways to make such changes easier and less costly would result
in a big win for the company.
I can vividly recall presenting a talk in early 1993 at a technology exchange forum for staff at
AT&T Bell Labs and NCR (we were all part of the same company at the time). I was given 45
minutes to speak on refactoring. At first the talk seemed to go well. My enthusiasm for the topic
came across. But at the end of the talk, there were very few questions. One of the attendees
came up afterward to learn more; he was beginning his graduate work and was fishing around for
a research topic. I had hoped to see some members of development projects show eagerness in
applying refactoring to their jobs. If they were eager, they didn't express it at the time.
People just didn't seem to get it.
Over the next couple years, I had numerous opportunities to talk about refactoring at AT&T Bell
Labs internal forums and at outside conferences and workshops. As I talked more with
developers in the trenches, I started to understand why my earlier messages didn't come across
clearly. The disconnect was caused partly by the newness of object-oriented technology. Those
who had worked with it had rarely progressed beyond the initial release and hence had not yet
faced the tough evolution problems refactoring can help solve. This was the typical researcher's
dilemma—the state of the art was beyond the state of common practice. However, there was
another, troubling cause for the disconnect. There were several commonsense reasons
developers, even if they bought into the benefits of refactoring, were reluctant to refactor their
programs. These concerns had to be addressed before refactoring could be embraced by the
development community.
随着与一线开发人员的交谈越来越多，我开始明白为什么以前的演讲不能感染别人。我与听众的距离有一部分是因为面向对象技术自身就很新。那些使用它的人多半都还没有完成第一个版本的开发，所以还没有遇到[演进]这个大的问题，而这个问题是重构能够帮忙解决的。
I worked at Bell Labs for several years before I decided to pursue my doctoral studies. Most of
that time was spent working in a part of the company that developed electronic switching
systems. Such products have very tight constraints with respect to both reliability and the speed
with which they handle phone calls. Thousands of staff-years have been invested in developing
and evolving such systems. Product lifetimes have spanned decades. Most of the cost of
developing these systems comes not in developing the initial release but in changing and
adapting the systems over time. Ways to make such changes easier and less costly would result
in a big win for the company.
I can vividly recall presenting a talk in early 1993 at a technology exchange forum for staff at
AT&T Bell Labs and NCR (we were all part of the same company at the time). I was given 45
minutes to speak on refactoring. At first the talk seemed to go well. My enthusiasm for the topic
came across. But at the end of the talk, there were very few questions. One of the attendees
came up afterward to learn more; he was beginning his graduate work and was fishing around for
a research topic. I had hoped to see some members of development projects show eagerness in
applying refactoring to their jobs. If they were eager, they didn't express it at the time.
People just didn't seem to get it.
Over the next couple years, I had numerous opportunities to talk about refactoring at AT&T Bell
Labs internal forums and at outside conferences and workshops. As I talked more with
developers in the trenches, I started to understand why my earlier messages didn't come across
clearly. The disconnect was caused partly by the newness of object-oriented technology. Those
who had worked with it had rarely progressed beyond the initial release and hence had not yet
faced the tough evolution problems refactoring can help solve. This was the typical researcher's
dilemma—the state of the art was beyond the state of common practice. However, there was
another, troubling cause for the disconnect. There were several commonsense reasons
developers, even if they bought into the benefits of refactoring, were reluctant to refactor their
programs. These concerns had to be addressed before refactoring could be embraced by the
development community.
随着与一线开发人员的交谈越来越多，我开始明白为什么以前的演讲不能感染别人。我与听众的距离有一部分是因为面向对象技术自身就很新。那些使用它的人多半都还没有完成第一个版本的开发，所以还没有遇到[演进]这个大的问题，而这个问题是重构能够帮忙解决的。
4 楼 lane_cn 2007-04-05
可维护性就是重用性，软件的第一个维护者是开发者本人。
可维护性依靠扩展性，扩展性来自对变化的适应力，而不是对变化的预先判断。
开发迅速，节约成本，高效灵活，结构清晰……这些好的特征在软件上经常是同时存在，同时消失。
可维护性依靠扩展性，扩展性来自对变化的适应力，而不是对变化的预先判断。
开发迅速，节约成本，高效灵活，结构清晰……这些好的特征在软件上经常是同时存在，同时消失。
5 楼 lelong 2007-04-05
EJB 不是组件级别的重用吗？
6 楼 jamesby 2007-04-05
lelong 写道
EJB 不是组件级别的重用吗？
我个人理解，如果一个EJB组件只被一个应用程序使用那就是组件，但是我将企业的很多通用的功能都封装成EJB,这些通用的EJB被企业的N个系统共同使用，你能说这时候的EJB是组件级别的？PS:自己理解！
7 楼 jamesby 2007-04-07
我现在有一个问题就是什么是可维护性，可维护性是指系统要不停的添加新的功能或者需要不停的对现有功能的修改？
其实有些时候真的搞不清楚，感觉这些词的意义都差不多，好象包含了一个特征就同时具有了另外几个特征。
就象lane_cn说的
其实有些时候真的搞不清楚，感觉这些词的意义都差不多，好象包含了一个特征就同时具有了另外几个特征。
就象lane_cn说的
引用
可维护性就是重用性，软件的第一个维护者是开发者本人。
可维护性依靠扩展性，扩展性来自对变化的适应力，而不是对变化的预先判断。
开发迅速，节约成本，高效灵活，结构清晰……这些好的特征在软件上经常是同时存在，同时消失。
可维护性依靠扩展性，扩展性来自对变化的适应力，而不是对变化的预先判断。
开发迅速，节约成本，高效灵活，结构清晰……这些好的特征在软件上经常是同时存在，同时消失。
8 楼 qinysong 2007-04-12
lane_cn 写道
可维护性就是重用性，软件的第一个维护者是开发者本人。
可维护性依靠扩展性，扩展性来自对变化的适应力，而不是对变化的预先判断。
开发迅速，节约成本，高效灵活，结构清晰……这些好的特征在软件上经常是同时存在，同时消失。
可维护性依靠扩展性，扩展性来自对变化的适应力，而不是对变化的预先判断。
开发迅速，节约成本，高效灵活，结构清晰……这些好的特征在软件上经常是同时存在，同时消失。
我有两点补充：
第一，可维护性和可重用性并不相同
第二，某些好的特征是相互竞争的，需要根据需要加以平衡，比如易用性和灵活性，简单性和扩展性等