zhvsby的专栏

昨天我们学习了（1）---（4）节其实前4节讲述的都是简单工厂模式，并不是工厂模式，这一节我们引进工厂模式 并对比它和简单工厂模式的不同工厂模式如下：先创建一个工厂接口interface IFactory(){ Operation CreateOpertion();}然后加减乘除各建立一个具体工厂去实现这个接口 class AddFactory : IFactory { public Operation CreateOperatio

由 Robert Martin提出的S.O.L.I.D 原则，用来更好编写面向对象程序，更灵活应对变化。S - Single Responsibility Principle 单一职责，简称SRP这个我前面几篇文章刚刚写：对象的责任与职责如何从职责和协作中发现丰富对象？比如：报表的内容和报表的格式都会变化改变，但是这两种变化的性质不同，一个是实质内在，一个是表面上的，SRP认为这是问题的两个方面，其实代表不同的职责，应该将它们分离放入不同的类或模块中，而不应该放在一起，否则的话，因为不同原因发生变化，导致对

<br /><br /> <br /> <br />先上图<br />如上图可知简单工厂模式里的工厂类里要有接口类或父类。即会涉及到所有想实例化的类和基类（接口)）。<br /> <br />在看这句话的理解：<br />简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类（这些产品类继承自一个父类或接口）的实例。<br /> <br />-----------------------<br />设计代码大体如下：<br />1:设计一个基类或接口<br />     该基类或接口中

Singleton模式要求一个类有且仅有一个实例，并且提供了一个全局的访问点。这就提出了一个问题：如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例？客户程序在调用某一个类时，它是不会考虑这个类是否只能有一个实例等问题的，所以，这应该是类设计者的责任，而不是类使用者的责任。 从另一个角度来说，Singleton模式其实也是一种职责型模式。因为我们创建了一个对象，这个对象扮演了独一无二的角色，在这个单独的对象实例中，它集中了它所属类的所有权力，同时它也肩负了行使这种权力的职责！ public seal

<br />至此简单工厂模式我们已经学习完毕：对于自己而言有几点需要总结<br />1：面向对象的概念 如何在实际应用中抽象出来，以后接到一个需求修改功能不能在盲目的去实现，为了完成而完成。这样既无法提高代码质量也不能提高个人的代码水平,最后还是会搞到上司不满意，同事来抱怨的地步。更重要的是目前的自己需要一个实质性的跨越，不然最后面临的是下岗走人。<br />2：业务层和界面层的分类。其实这里的分离主要是为了以后的维护所用。是否需要分类主要看实际项目情况。但是建议还是分类的好。分离用到了面向对象的封装特性。

回顾上一节：我们利用面向对象方法把计算器的输入和计算做作为一个类来对待，然后利用继承特性让加减乘除来继承该类实现了修改或者添加一个新的运算不影响其他的运算。如何去实例化对象成了我们的问题。方案：简单工厂模式,也就是说到底要实例化谁，将来会不会增加实例化的对象,比如开根运算,这是很容易变化的地方,应该考虑单独一个类来做这个创造实例化的过程，即工厂.    public class OperationFactory    {        public static Operation createOperat

<br />上一节中的代码段存在一种弊端,若我们想些一个web段应用的计算器如何实现呢？直接了当-----把上一节的代码段直接拷贝过去。这就是程序员的悲哀 -----Ctrl+C 和Ctrl+V 我们可以试着将业务逻辑层和界面逻辑分开<br />首先这里要搞清楚的是哪里是业务逻辑层：计算方法即加减乘除运算<br />界面逻辑层：输入数字和数字显示结果<br />如下：<br />//Operation 运算类<br />public class Operation()<br />{<br />      p

面试题目：请用任意一种语言以面向对象方式编写一个计算器代码最初始代码public void DoOperation(){            //输入            Console.Write("请输入数字A");            string A = Console.ReadLine();            Console.Write("请选择计算符号+,-,* ,/");            string B = Console.ReadLine();            Con

开放--封闭原则：是说软件实体(类，模块，函数等)应该可以扩展，但是不可修改。我们做任何系统的时候不要指望系统一开始需求就是确定的。这是不科学也不现实的想法。既然需求是变化的。那么如何在面对需求的变化时，设计的软件相对容易修改，不至于说，新需求一来，整个程序推倒重来。开闭原则告诉我们设计的时候，时刻要考虑，尽量让这个类足够好，写好后就不要去修改了。新需求来时，增加一些类就可以了，原来的代码能不动就不要动。但是绝对的对修改关闭是不可能的。无论模块是多么的封闭，都会存在一些无法对之封闭的变化。既然不能完

<br />/// 单例模式实际业务理解：以登陆者LoginUserInfo为列，进入系统的时候就要获取到该登陆用户的所有信息<br />        /// 如所在的公司,所在的部门,所在的地区,名字,ID,性别,级别,等等，一般登陆人的这些属性都是固定死的,一旦进入系统<br />        /// 读取后，对该系统的其他操作若用到了上述属性，可以直接利用静态类直接调用.当然前提是在登陆者类中要有相应的对上述属性的<br />        /// 设置<br />    public class