原文网址：http://www.cnblogs.com/mailingfeng/archive/2012/09/13/2683246.htmlOCP(Open-Close Principle)开闭原则 Software entities should be open for extension,but closed for modification,(在设计一个模块的时候，应当使这个模块可以在不被修改的前提下扩展)。 对扩展开放open，对修改关闭close。 如何实现？ 1.抽象化是关键 2.对可变性的封装原则(Principle of Encapsulation of Variation EVP)。 3.对可能的拓展预留接口 备注: 1) 对于抽象化, 我的理解是, 接口是相对稳定的, 实现是根据需求多变的. 对于大多数可能预料的变化点, 我们可以抽取出共性或者常态点, 进行接口的封装, 而选择不同的实现类嵌入模块, 从而达到可扩展的作用. 2) 对于某个业务点, 可能以后有多种介入处理的情况, 那么这时候可以将业务抽象成事件(event)接口和监听器(listener)接口, 不同的处理需求生成不同的listener, 接入模块的listener收集器, 从而得到业务点的介入机会. 最后达到功能的扩展. 典型容易理解的例子，工厂模式。当需要新增加一个类的时候，直接继承product接口就可以了 , 由工厂类来组装产生需要的product, 而不用大范围修改原有代码。OCP～Liskov Subsitution Principle(LSP)里氏代换原则 就是子类可以代替父类出现的任何地方，在抽象的时候，重要的要理解的一个地方两个类之间是什么关系，是“has-A”？还是“Is-a”的关系。在 “has-a”的关系中，两个类存在的是依赖的关系(在类A里面存在类B的的变量)；在“Is-a”的关系中，可以提取这两个类的“共同代码”放在抽象类 C中，然后A，B继承与C，这也是一种重构。Dependency Inversion Principle(DIP)依赖倒转原则 就是在我们编程的时候方法的参数类型，变量，对于其他具体类的依赖，我们尽量的使用抽象类 。 就是说尽量依赖于抽象，而不是依赖于实现。 在书中两种表述: (1)，Abstraction should not depend on details.details should depend on abstraction. (抽象不应当依赖于细节，细节应当依赖于抽象)。Abstraction就像是建筑物的基础，而其实现类就是在基础上面一层一层的往上面走。你拆掉最上面 那层，和拿走最下面的基础，有什么不同了，这就是差异了。所以Abstraction是要相当的稳定，是维护的重点。也正是因为稳定，所以我们尽量的依赖 于Abstraction，既是稳定系统，也是灵活系统。 (2),Program to an Interface,not an implementation(要针对接口编程，不要针对实现编程) 应当使用java接口和抽象java类进行变量的类型声明，参数的类型声明，方法返回值的类型和数据类型的转换。 备注: 依赖倒转原则的作用在于多模块或者类间有统一的"知识", 都知道有这个接口, 都知道这个接口是这样用,会返回什么数据. 至于最初的实现类是什么, 只有提供该接口功能的实现类自己关心, 其他模块或者类只管用就行了. 即使以后需求更改, 实现会换成别的一个, 其他模块和类也无需修改代码. 例如A模块提供了一个接口是: List getProducts() 而B和C会使用该模块, 他们只知道这个方法就会返回List , 他们知道List和Product代表什么. 但他们不会管你的接口内部是使用List list = new ArrayList() , 还是List lis = new LinkedList() 或者具体的Product是什么(可能是衣服,鞋子等)Interface Segregation Principle(ISP)接口隔离原则 限制一个实体对另一个实体通信时候的宽度。 就是一个类对另外一个类依赖的时候，应当是建立在最小的接口上面。对于接口隔离原则来说，有两种接口，一种是真正意义上面的“java 接口”Interface；另外一种是指一个类的方法的集合。对于这来两种有，两个接口隔离的原则，对于一个类里面的方法的集合的接口隔离，我们称作是 “角色隔离原则”；另外一种叫做“定制服务”。 定制服务，就是一个类，我给你这个客户端一些方法，我放在一个java接口(Interface)里面。给另外一个客户端另外一些方法，放在另外一个接口(Interface). 角色隔离原则，是指客户端要多个不同的类的方法，我们就搞几个不同类别的接口(Interface)，在书中，这么比喻的，就相当于电影剧本里面的人物，我们找人来演，这个人就是具体的类。这就叫做角色隔离原则。Composition/Aggregation Reuse Principle(CARP)组合/聚合复用原则 就是说要尽量的使用合成和聚合，而不是继承关系达到复用的目的。 其实这里最终要的地方就是区分“has-a”和“is-a”的区别。相对于合成和聚合，继承的缺点在于：父类的方法全部暴露给子类。父类如果发生变化，子类也得发生变化。聚合的复用的时候就对另外的类依赖的比较的少。Least Knowledge Principle(LKP)最少知识原则，又称为“Law of Demeter”迪米特原则。 和ISP接口隔离原则一样，限制类与类之间的通信。ISP限制的是宽度，而LoD迪米特原则限制的是通信的广度和深度。 LoD在广度上面，尽量减少远距离类的关联，而使用与自己有关的类，并且也与远距离类有关的类。 可是这种做法有一点麻烦。多个远距离类产生关联的时候，不怎么容易处理，所以增加一个远距离类的抽象类。所有的远距离类都是通过抽象类的形式来访问。 在深度上面，控制权限是最重要的，对于类，一个是default 和public，尽量最小权限；对于成员，private，default，protected，public。往上面走，权限越小，依赖的耦合就越小。 有几种描述： (a)Only talk to your immediate friends. (b)Don’t talk to strangers. 设计模式“facade”,"调停者模式"。在这里是IoD的典型表现。 备注: 当一个系统比较大的时候, 如果所有的模块都自己去寻找与自己相关的类的时候, 那么引用关系就会变得极度复杂, 耦合度高. 这个时候最好就设定一个为各个模块所熟悉的对象, 例如Context容器. 另外,各个模块可以应用facade模式, 提供一个简单的对外接口, 并将其嵌入Context容器. 这样, 模块间通过熟人Context来获取其他模块的Facade接口,…
Android IT:分享一些程序员个人修养的行为表现，希望程序员们能够引以为戒，更快的成长！1) 情绪化的思维如果你开始使用不同颜色的眼光来看待这个世界的话，那么你可能会成为一个很糟糕的程序员。情绪化的思维或态度很有可能会把自己变成一个怪物。相信你 经常可以看到很多很糟糕的程序会使用下面的这些语句：我的程序不可能有这种问题。Java就是shit。我最恨的就是使用UML做设计。需求怎么老在变，没办干了。受不了这些人，他们到底懂不懂啊。这些带着情绪化的思维和态度，不但可以让你成为一个很糟糕的程序员，甚至可以影响你的前途。因为，情绪化通常都是魔鬼，会让你做出错误的判断和决定，错误 码率的判断和决定直接决定了你的人生。2) 怀疑别人糟糕的程序总是说：“我的代码一定是正确的，我怀疑编译器有问题”，“我这应该没有问题吧，STL库怎么这么难用啊”。我曾经见过有程序员这样使用 STL类：map，当他发现这样放入字符串后却取不出来，觉得那是STL库的BUG，然后自己写了一个map！我的天啊！某些时候，过早的下结论是一个很不好的习惯，任何事情都有其原因，只有知道了原因，你才能知道是谁的问题。一般来说，总是自己出的问题。3) 过多关注实现，陷入问题细节有些时候，当我们面对一个问题或是一个需求的时候，糟糕的程序员总是会马上去找一个解决方案或是实现，这是一个很不好的习惯。设计模式告诉我们， “喜欢接口，而不是实现”就是告诉我们，认清问题的本质和特性要比如何实现更重要。对于一个客户的问题来说，首先应该想到的是如何先让用户正常工作，如何恢复正在“流血”的系统，而不是把用户放在一边而去分析问题的原因和解决方 案。对于解决一个bug来说，重现bug，了解原来程序的意图是首先重要的事，而不是马上去修改代码，否则必然会引入更多的BUG。对于一个需求来说，我们需要了解的需求后面的商业背景，usecase和真实意图，而不是去讨论如何实现。只有了解了用户的真实意图，实际使用的方式和案例，你才能真正如果去做设计。糟糕的程序总是容易陷入细节，争论于如何实现和实现难题，以及问题的根本原因，而忽略了比这些更重要的东西。只有看懂了整个地图，我们才知道要怎么去走。4) 使用并不熟悉的代码糟糕的程序员最好的朋友是 Ctrl-C 和 Ctrl-V，有些时候，他们并不知道代码的确切含义，就开始使用它，有证据表明，由拷贝粘贴引发的bug占了绝大多数。因为，代码总是只能在特定的环境下才能正常地 工作，如果代码的上下文改变了，很有可能使得代码产生很多你不知道的行为，当你连代码都控制不住了，你还能编出什么好的程序呢？5) 拼命工作而不是聪明的工作对于糟糕的程序员，我们总是能看到他们拼命地修正他们的bug，总是花非常多时间并重复地完成某一工作。而好的程序可能会花双倍的时间来准备一个有 效的开发环境，工具，以及在开发的时候花双倍甚至10倍的时间来避免一些错误。好的程序员总是会利用一切工具或手段来让自己的工作变得更有效率，总是为在 开发的时候尽可能得不出错。后期出错的成本将会是巨大的，而且那时改正错误的压力也是巨大的。所以，糟糕的程序通常会让自己进入一种恶性循环，他们看上去 总是疲惫的，总是很辛苦的，所以更没有时间来改善，越没有时间来改善，就有越多的问题。所以，拼命工作有些时候可能表明你不是一个好的程序员。6) 总是在等待、找借口以及抱怨当需求不明确的时候，当环境不是很满意的时候，他们总是在等待别人的改善。出现问题的时候，总是在找借口，或是抱怨这也不好，那也不好，所以自己当 然就没有做好。糟糕的程序员总是希望自己的所处的环境是最好的，有明确的需求，有非常不错的开发环境，有足够的时间，有不错的QA，还有很强的teamleader，以及体贴自己的经理，有足够的培训，有良好的讨论，有别人强有力的支持……，这是一种“饭来张口，衣来伸手”的态度，这个世界本来就不完 美，一个团队需要所有人去奋斗，况且，如果什么都变得完美了，那么，你的价值何在吗？driving instead of waiting,leading instead of following.7) 滋生办公室政治有句话叫“丑女多作怪”，意思是说如果一个自己没有真实的能力的话，那么他一定会在其它方面作文章。糟糕的程序员也是这样，如果他们程序编不好的 话，比不过别人的话，他们通常会去靠指责别人，推脱责任，或是排挤有能力的人，等等不正常的手段来保全自己。所以，糟糕的程序通常伴随着办公室政治。8 ) 说得多做得少糟糕的程序员总是觉得自己什么都懂，他们并不会觉得自己的认识和知识都是有限的。这就是所谓的夸夸其谈，是的，什么都做不好的程序员能靠什么混日子 呢？就是吹啊吹啊。另一个表现方式是他们在评论起别人的程序或是设计，总是能挑出一堆毛病，但自己的程序写得也很烂。总是批评抱怨，而没有任何有建设性的意见，或是提 出可行的解决方案。这些糟糕的程序员，总是喜欢以批评别人的程序而达到显示自己的优秀。9) 顽固当你给出一打证据说明那里有一个更好的方案，那里有一个更好的方向的时候，他们总是会倔强的认为他们自己的做法才是最好的。一个我亲身经历的事例就 是，当我看到一个新来的程序员在解决一个问题的时候走到了错误的方向上时，我提醒他，你可能走错了，应该是另外那边，并且我证明了给他看还有一个更为简单 的方法，有。然而，这位程序员却告诉我，“那是我的方法，我一定要把之走下去，不然我会非常难受”，于是，在三天后的代码评审中，在经过顽固地解释以及一 片质疑声中，他不得不采用了我最先告诉他的那个方法。这些程序员，从来不会去想，也不会去找人讨论还有没有更好的方法，而是坚持自己的想法，那怕是条死路都一往直前，不撞南墙永不回头。10) 写“聪明”的代码他们写出来的代码需要别的同事查看程序语言参考手册，或是其程序的逻辑或是风格看上去相当时髦，但却非常难读。代码本应该简洁和易读，而他们喜欢在 代码中表现自己，并尝试另类的东西，以显示自己的才气。是的，只有能力有问题的程序员才需要借助这样的显示。记得以前的一个经历，一位英语很不错的程序员加入公司，本来对我们这些英语二把刀来说，我们喜欢看到的是简单和易读的英文文档，然后，那位老兄为了 展示他的英语如何牛，使用了很多GRE中比较生僻的短语和词汇。让大家阅读得很艰苦。最有讽刺意味的是，有一位native的美国人后来在其邮件中询问他 某个单词的意思。呵呵。
CygWin使用命令tail打印出来日志中文乱码的解决办法我在win7上安装了CygWin，使用ls等命令，都可以把中文正常的显示出来。但是当使用tail -f 来打印SytemOut.log的时候，出现了乱码。要解决就只要在Cygwin.bat中添加set LANG=en_US就可以了。@echo offd:chdir d:cygwininset LANG=en_USbash –login -i