TCMY的专栏

正如上节说的抽象提供了一个让你忽略实现细节的模型来管理复杂度，而封装则强制阻止你看到细节。这两个概念是相关的，因为没有封装，抽象就容易被打破。关于封装的指导建议：尽可能地限制类和成员的可访问性 不要公开暴露成员数据 避免把私用的实现细节放入类的接口中 不要对类的使用者做出任何假设 避免使用友元类 不要因为一个子程序里仅使用公用子程序，就把它归入公开接口 让阅读代码比编写代码更方便 要格外警惕从语言上破坏封装性（要针对接口编程，而不是透过接口针对内部实现编程） 留意过于紧密的耦合关

接口：不是指编程语言上的接口类，而是指类公开给外部能使用的方法或属性。在读整节时，对接口的概念都是这个，而不要想到是编程语言的接品类，不然会影响对相关内容的理解或都直接理解 错了。针对接口编程，而不是针对实现编程：这句话的意思是说我们在使用其它类时，只需要从类的接口（公共方法或属性）就能清楚知道该怎么使用这个类进行编程，而不用深入类的内部实现细节，才知道该怎么调用方法。说明了类的抽象封装的重要性。...

越看《代码大全2》越发现它的博大精深，真的由衷佩服作者，有如此宽广的知识面，而且文笔又是这么的好，作为专业技术书籍，没有写得框框条条，枯燥无味。而是写得详略有当，排版布局直观，为能遇到这样的好书真是感到荣幸。如果刚工作时就接触这本书，并能理解的话，相信现在水平绝对是几何级别的。今天看到了第6章的：抽象数据类型（ADT)，整个6.1就讲了什么是ADT，它有什么好处，并举了实际的例子，以方便理解ADT，整个6.1核心就是要明白抽象数据类型概念的定义。说实话...

之前讲的都是好的设计应该具有的样子，这篇讲一些我们可能采用而且常常可以获得良好结果的工作步骤。迭代和代码一样，设计也需要迭代的，从高层和低层不同视角去审视问题，高层视角的大范围图景有利于把相关低层细节纳入考虑。从底层视角获得的细节也会为高层决奠定基础。分而治之把设计分解为不同区域。使用增量式改进。自上而下，自下而上的设计方法作者详细分析了两种方法的特性、使用方式、优缺点。并说明了两种方式并不排斥，两者的协作会让设计更加受益。设计是一个启发式（试探）的过程，这就意味着没有任何解

该篇先讲了使用设计模式4个益处，然后列出了12个常见的设计模式名称及描述，作为索引参考，推荐了关于设计模式的经典书。对设计模式，一直没有很清晰的认识、理解和应用，像工厂方法、单件这两个模式有应用，其它的确实不理解，各模式的特点和具体应该怎么实践。最近也是在阅读《代码复用，设计模式》这本书，想通过对模式的学习，对目前项目代码进行优化重构。作者也很客观的讲了使用设计模式的陷阱，我觉得写得很好，让我们能认识到一个工具或方法应该怎么合理使用才是最好的。陷阱一：强迫让代码适用于某种模式。陷阱二：为了模

耦合度表示类与类之间或子程序与子程序之前的关系的紧密程度。耦合设计目标是：尽可能设计小的、直接的、清晰的类或子程序(模块)，使他们之间关系尽量灵活，这种就被称为“松散耦合"

找出易改变的区域优秀设计师的一项特质：对变化的预期能力好的一项设计最重要的挑战之一就是：适应变化目的是：把不稳定的区域隔离出来，从而把变化的影响限制在一个子程序内部一、可采取的措施：找出看起来容易变化的项目 把容易变化的项目分离出来 把看起来容易变化的项目隔离开来二、容易变化的区域：1、业务规则 这是很容易成为软件频繁变化的根源，应对它进行封装，而不能遍布整个程序2、对硬件的依赖 主程序不直接与特定硬件连接，而是通过一个硬件接口子系统，利于调试后硬件兼容3、输入和输

使用信息隐藏该部份讲了“信息隐藏”的好处，如果没有合理使用“信息隐藏”可能带来的问题。在平时编码和设计中，我确实没考虑“信息隐藏”这个概念。“信息隐藏”所要“隐藏的主要包括两大类：1、隐藏复杂度：让代码更易读易维护2、隐藏变化源：这样当需要修改时，只需要修改一处，而不用修改外部引用到的地方其实“信息隐藏”也是封装的体现。如果你觉得使用“信息隐藏”有障碍，那可能是错误的一些设计造成的，如：1、信息过度分散2、循环依赖3、把类内数据误认为全局数据：尽量少或...

对于具体编程工作来说，做了某事能得到某样结果，这样期待确定性是正常的。但对于软件设计来说并非如此，因为软件设计是非确定性的，因此，应用启发式方法（试探法）便成了合理的软件设计核心工作。启发式方法1、找出现实世界中的对象步骤：辨识对象及其属性（方法和数据） 确定可以对该对象进行的操作 确定对象能对其它对象进行的操作 确定对象那些部份是公用，那些是私用 定义对象的公开接口这些步骤并不以特定顺序来完成，它们经常被反复执行，迭代是非常重要的。2、形成一致的抽象抽象就...

作者将软件分为五个层次，提了需要在不事的层次上进行设计，不同层次上有不同的设计技术。层次性有利于我们能在任意层面上观察系统，并得到某种一致性的看法，而不需要进入其它层次。第二层 分解为子系统或包主要成果：识别出所有的主要子系统...

软件的首要技术使命：管理复杂度 引入了本质的属性和偶然的属性两个概念用在软件上，尽量做到1、把任何人同一时间需要处理的本质复杂度的量减到最小；2、不要让偶然性的复杂度无所谓的快速增长。 管理复杂度的重要性 应该试着以某种方式去组织程序，以便能够在一个时刻可以专注于一个特定的部份，这么做的目的是尽量减少在任一时间所要考虑的程序量。1、在软件架构层次上，可以通过把整个系统分解为多个子系统来降低问题的复杂度2、保持子程序短小精悍也能帮助你减少思考负担。 理想的设计特征 ..

设计分正式和非正式的，根据项目的规模，有不同的形式，但无论以何种方式进行设计，不管是小型项目还是大型项目，都能从精心的设计中获益。但要做出一个好的设计是非常困难的，以下是原因分析：一、设计是一个险恶的的问题所谓的险恶的(Wicked)的问题，是指只有通过解决（或部份解决）才能被明确的问题。这个在我们项目经验中经常遇到，也是我们常说的需求不清晰的问题，只有做出来了，用户才知道还有什么需求或问题，或没考虑到到因素，这就意味存着在反复的设计-开发-再设计-再开发。与在学校的学习项目不同，老师

坚持一件事确实不容易，从3月11日发第一篇阅读笔记，当时想着每天都读半小时，把自己理解和认为有有的写下来，主要是对自己的总结鞭策，如果能为他人带来些作用，那更好。今天阅读《核对表：变量命名》，是个很好的内容，就像代码走查25疑问一样，通过核对表，我们可以检查核实自己所取的变量合是不是个好变量名。命名的一般注意事项：名字完整并准确地表达了变量所代表的含义吗？ 名字反映了现实世界的问题而不是编译语言方案吗？ 名字足够长，可以让你无须苦苦思索它的意义蚂？ 如果有计算值限定符，它被放在名字的.

一、临时变量常用于存储计算的中间结果，它们常被赋予temp、X或其它模糊而且缺乏描述怀的名称。要警惕使用无意义的“临时”变量名，如temp=sqrt(b^2-4*a*b），特别是这一结果会被后面多次用到时，无意义的变量名会增加出错的可能，使用准确而且具有描述性的变量名，如discriminant=sqrt(b^2-4*a*b）有更好的改善。二、布尔变量给布尔变量赋予隐含"真/假“含义的名字，像done和success这样的名字是很不错的布尔型变量名，因为其状态要么是true要以是fals

状态变量用于描述你的程序的状态。为状态变量取一个比flag更好的名字，标记的名称不应该有flag，因为你从中丝毫看不出该标记是做什么的。为了清楚可见，标记应该用枚举类型、具名常量。示例：标记命名很差，含义模糊的标记if(flag){...}if(printFlag==16){...}flag=0x01;printFlag=16;示例：更好地使用状态变量if(dataReady){...}if(printFlag==...

对于较短循环，约定成俗用i、j、k来命名。如果一个变量要在循环外用，或者循环比较长，就应该为它取个比i、j、k更有意义的名字。因为循环在很长容易忘记i本来具有的含义，避免产生下标串话，用错变量。特别是代码经常要修改、扩充、复制到其它程序，因此很多有经验的程序员索性不使用i这样的名字如score[teamIndex][eventIndex]要比score[i][j]给出的信息更多。如果你一定要用 i、j、k那么不要把它们用于简单循环下标之外的...

变量命名 看似简单的事，但为变量取好的名字是编程中的一项重要事项。好的名字对代码编写、维护都将带来很大的好处。好变量命名的技巧和原则该名称要完全、准确地描述该变量所代表的事务，没有歧义； 一个好的名字反映的通常都是问题，而不是解决方案。要表达是“什么(what)”，而不是“如何(how)”； 适当的名称长度。太短不能描述清代表的意义及与其它变量关系，太长难写；变量命的败笔用简单的X1、XX、或太短的晦涩缩写...