随笔分类 - 程序设计
摘要：程序开发并非一定要面向对象不可，面向对象是一种方式，但是不是唯一的方式，这种方式很多时候有用，不代表任何时候都是最高效的，更不是唯一的真理。面向对象将相关的状态属性和操作方法放在一个实体中，起到了归类和分而治之的作用。对于一个系统来说，这个是最根本的方法。但是面向对象的分而治之并不完美。面向过程也有分而治之的思想和能力，这就是模块开发。对象是复杂的，他有生命过程，有复制克隆的需要，有保持状态的需要，他是一个复杂的实体。而很多时候我们不需要这么多的东西，而只要一个函数，一个过程，一个状态。第二个，面向对象的类型系统非常复杂。第三个，面向对象的封装不彻底，默认的实践是接口和实现同为一个对象实体，如
阅读全文
摘要：软件的设计阶段是相当重要的。一般来说，都不建议接到项目后第一时间就去考虑什么编码，怎么实现细节，而是有一个规划设计的过程。设计过程本身又有很多个过程，比如类设计，就是后期的，什么UML之类的，都是关注设计的后期，而不是前期准备。作为设计的最初状态，各位有什么好用的设计工具？我自己就是用txt来写思路而已，不知道这样是不是有点太落后了？就算是txt写思路，也有一些框架，可以用来衡量设计的进度到达哪一步了。我自己没有一个很好的想法，就是随便乱写，谁有更好的建议？-------------------------------第一步是需求的分析。需求分析是从宏观上去认识产品。不管你这个产品具体怎么做，
阅读全文
摘要：一、外观类。不管内部细节如何复杂，只是提供“消费者”需要的界面。任何类都是外观类，外观类是相对来说的。二、外观类的具体实现类。有些实现提供的界面是超越外观类的，但是在系统中还是用基本的界面。三、创建工厂。这一类是最易于修改的。就是负责创建系统需要的具体实现类。创建工厂知道具体实现类的使用细节，负责配置。创建类被主流程所使用。
阅读全文
摘要：五大设计原则是：1.职责单一2.对修改封闭，对扩展开放3.子类可在任何情况下替代父类4.接口细分5.具体实现依赖抽象简单指导，一看就晓：1.根据业务流程，把业务对象提炼出来。如果业务流层的链路太复杂，比如多条进线，那么就把这个业务对象分离为多个单一业务对象。当业务链路标准化后，对业务对象的内部情况做进一步的处理。把第一次标准化视为最高层抽象，第二次视为次高层抽象，以此类推，直到“恰如其分”的设计层次。第二，职责的分类需要注意。有业务职责，还有脱离业务的抽象职责，从认识业务到抽象算法是一个层层递进的过程。2.对客户代码（使用该类的地方）封闭，对服务代码（该类的具体实现可以修改，或者替换）开放。要
阅读全文
摘要：算法+数据结构=程序。这是一条很著名的公式。但是我觉得过于简单的公式或者不能适应现在的开发潮流了。程序一个目的是用来模拟人类的行为，让机器自动化处理本来人自己需要处理的事务。正因为这样，所以程序有很强的“过程性”，把人的步骤转化为计算机指令的序列。过程性的设计方法，是最原始的方法，是完全模拟人类习惯的一种方法。但是，其实过程并不是我们关注的重点，我们关注的是结果。只要是这个结果，我们不在乎这个过程究竟是如何实现的。有没有办法表述这种从输入到结果的对应关系呢？有，那就是函数。有了函数，我们就将过程给抽象化了，我们再也不关心过程如何，只需要知道这个函数能正常工作就行了。因此函数是过程的抽象。我们可
阅读全文
摘要：作为一个程序员，习惯和电脑打交道，对什么指令之类的相当熟悉。这个时候可能会出现一个毛病，就是喜欢什么事情都用电脑的思维去看。但是我不赞成这种习惯。我们是人，不是机器。这句话的意义是什么？你可以把人看作一个超级电脑，相对你的微机来说他解决问题的速度，和能力要高一万倍。如果你只是将自己局限于电脑的范畴，习惯用他的思维去想问题，只会制约你的思路。正确的做法是：第一步，用你的人脑去分析，解决问题第二部，用你学过的关于电脑的知识去把问题转化为计算机算法很明显的一点是，如果你自己都理解不了问题，无论如何也不可能写出程序的。
阅读全文
摘要：为什么要集中？因为软件经常需要修改，而集中便于修改。举例来说明：1.魔术数字，也就是一些孤立的数字，不能直观看出有什么意义的数字。这种数字可以用常量来代替，任何重复使用到的地方，都可以用这个常量来代替，如果你需要修改这个数值，那么只需要修改常量的定义就可以了，而不需要多处修改。2.函数把算法集中在一块了。你可以在每次用到该算法的时候，都直接写代码（或者复制过来），但是如果你用函数去代替，那么当改进算法质量的时候，任何用到该算法的地方，都能同时得到改善。3.对象把算法和状态集中在一块了。根据状态机理论，程序的实质就是从一个状态跳转到另外的一个状态，而对象很好的实践了这个理论。如果状态和对象各处一
阅读全文
摘要：设计编程的时候，往往根据具体的问题具体实施，而缺少提炼共性的动力。为什么会这样，我想主要是提炼共性是一个复杂的脑力劳动，在人们追求按时完成工作之余，是否有精力去做这个复杂繁重的脑力劳动呢？为此，我认为，一味去指责人们不去提炼复用，是没有意义的。要改善这方面的问题，可以培养一种可以提高复用性的编码习惯，这种习惯一旦养成，就可以不费劲的编写一些复用性相对较高的代码出来。1.基于接口编程。制定一个良好的接口规范（根据调用方的需求制定），再来完成内部编码。这个隔离可以避免对实现的过多猜测，减少调用方对具体实现的依赖。2.功能的专职化，每个接口应该只包含紧密相关的一组函数调用规格。3.主流程调用方案，方
阅读全文
摘要：面向对象的习惯思维是把形象的个体作为对象，这叫有形。和有形相对的是，形体内部的执行特性，比如算法，流程，这叫无形。从无形到有形，这里的哲学是，无形是有形的基础。一条鱼和一个人在形体上差别很大，但是从无形的角度去看，两者都有生老病死。在建立这个无形的基础后，有形的对象就可以顺理成章的建立起来。具体的例子，比如unix里面的file概念，就是一个无形的对象，他可以是具有鲜明形象的软盘，硬盘，也可以是通信设备，甚至是内存。
阅读全文
摘要：第一点：发现Google打“shijian”会有个当前时间：08:39。第二点：犯了个大忌，就是把所有的程序写完了，才运行，发现结果不对。有种焦头烂额无从下手的感觉。这里面涉及了两个工程实践，比如什么“每日编译”，“持续集成”什么的，总之就是强调尽快编译，而不是等到做了个大头佛才来编译。第二个就是自动化测试，如果把每个组件都编写好测试代码，那么就将调试局部化了，这个实在太重要了。第三点：ovvride string ToString()很有用，在调试的时候能以方便的格式在调试窗口里面查看数据，大大提高查错效率。第四点：我的设计方法是从上到下，从整体细分到局部，所以一直在展开，这种设计有个好处，
阅读全文
摘要：面向对象声称自己带来了革命性的进步，实际却没有。并不是说面向对象没有作用，而是语言在开发中的作用并不如想象中的高。在开发中，除了语言，还有管理，甚至还有人际关系，这些都不是面向对象所能涵盖的，也就是，不管面向对象多牛，他的作用相对于开发工程来说只是一小部分。面向对象是一组api和状态，并且有外部接口和内部实现的区别，可以减少第三方调用的复杂度。计算机的基础理论之一就是状态机，也就是一个状态迁移到另外一个状态，对象完美的对应了这种基础理论，因此是高效的。可是最近发现状态过于复杂，导致并行度难以提升的问题，因此出现了函数编程的概念。现代语言重点在于讨好计算机硬件，而不是讨好人，但是随着问题的复杂化
阅读全文
摘要：命令式精雕细琢，函数式的学术味道，都有同样的问题。声明式等更高层次的语言，应该会是未来的方向，而且，这个不会很遥远。在现在多线程，网络化等诸多复杂性的编程环境下，唯有将这部分的复杂性交给编译工具去解决，否则程序员很难在走下去。经过了这么多年的积累，已经有很多解决问题的模式出现了，编译器开发者完全可以利用这些模式来智能化实现程序员的目标。
阅读全文
摘要：接口是多态的语法基础之一。而可测试性是保证软件质量的标准之一。接口是不涉及具体实现的，而测试是针对具体的实现。那么接口某种层度上只是属于语法范畴，而测试是属于语义范畴。我们不能针对接口来测试，因为接口是没有语义的（不可测试的）。我们只能针对特定的类实现来测试。<p
摘要：看什么书不是重点,重点是知道怎么去看书.我想说说我的看法:1.语言不要太沉迷,不要玩语言游戏,不要懂得茴香豆的茴字有几种写法。关键你要明白，这是用来作事情的，不是用来搞研究的。当然，高手可能都很深入语言的特性，但是那个不是初学者应该关注的地方。②。多想想编程可以用来解决什么问题。编程的目的比编程的技巧更加重要，失去目的的技巧是无意义的，是没有生命力的，是专牛角尖的。多看一些解题思路之类的算法书，掌握一些分析问题的方法。三。编程是一个精细的活儿，一个字符写错，运行就出错。任何时候都应该培养自己精细做事情的态度。比如代码要有整洁感，做事情有规划，有文字记录，不要一知半解，不懂装懂，做事情要明确而清
阅读全文
摘要：<p
摘要：现在的软件开发流程是这样的:需求分析->概要设计->框架设计->模块设计->类设计->编码->维护新思路:用户特点分析（类似的功能，对不同用户的价值点有所不同）->软件价值分析(也就是软件给用户带来的实际利益的具体输出结果)->算法分析(确定软件结果所需要的相关算法,从这个可以得出数据的流通变换方式,得到数据实体类,同时还能确定用户所需要提供的数据内容,和如何提供这些内容的相关手段)->功能分析(建立业务类,业务类使用数据实体类进行数据的交换)->模块分析(归纳业务类,形成具体功能模块)->框架分析(归纳模块,形成具体框架)-&
阅读全文
摘要：UI，逻辑，数据三层模式是最为经典的面向大规模数据处理的项目场景的解决方案。下面是我的看法：UI层使用逻辑层，而逻辑层使用数据层。也就是，UI依赖逻辑，逻辑依赖数据。从面向对象角度，数据层位于抽象的顶端。面向对象的原则，是抽象顶端尽量不要变动，否则依赖他的底层必然需要修改。而底层可以变动，顶层无需更改。在这种三层模式下，数据层是最不允许变动的。不过实际项目的后期维护中，我们绝不会无端端为了修改UI而修改UI，而是用户的需求发生了变化，其中变化的主要层次，就是数据层的变化。这种现实下，三层模式是否已经失去意义了？应该说这种现实，会让三层模式失去很多架构上的优势，但是三层模式有助程序的面向对象化。
阅读全文
摘要：首先要明白 需求 和 （代码）实现 是怎样的对应关系。假设需求和实现是一一对应的。那么需求改变一处，代码也必然改变一处。有人想要需求变了，却也不改写实现，是不符合逻辑的。变化有三种，一句话：增删改。对三种情况作分析：增：不需要改写原来的，而增加新的实现。删：只需要去掉对应的部分。改：改掉对应的部分。因此，结论是，软件设计，应该满足在增加功能的时候，不修改固有代码这个原则。虽然删除需求的需求不多见~嗯~~~，这个其实是上一个规则的不同表诉。改，嗯~~~本质上也是第一个规则。如何应对需求不断的变化？这是折磨软件设计者的难题。需求变了，不改变实现是不可能的。我们要做到的是变化多少，改动多少，做到平滑
阅读全文
摘要：顾名思义，就是接口加上测试代码。任何符合这个接口的，除了接口样式要对应之外，同时还要运行通过测试。interface iphone{ void call(string number): test{ ... } ;}class Nokia : iphone{ void call(string number){...}}class Motorola : iphone{ void call(string number){...}}Nokia E72 = new Nokia(); E72.call("114"); // test ...Motorola V8 = new Moto.
阅读全文
