LCore的专栏

上一篇文章中主要介绍了设计模式的定义与分类,不过在具体学习那种设计模式之前还是有必要        掌握面向对象、设计 模式中的类的关系，这对于之后的设计模式的学习是有很大好处的。因为只有         理解了面向对象中类之间存在的关系，才有可能运用恰当的设计思想。                    在面向对象的程序设计中类是对象的抽象，展示了对象的结构与系统的交互行为(数据、数

同样以计算器程序为参考对象,上一篇文章中通过业务的封装将业务逻辑和界面逻辑分开            从而降低了他们的耦合度,使得扩展性和维护性提高.但是仅仅这样还不够.因为,Operation类中,加            法、减法、乘法、除法的运算是在一起的，如若需要加入一种新的运算方式（开根）就势必去修            原有的代码,不加注意就会造成问题.

今天下午不小心将设计模式栏里面的两篇博文删掉了，又不想联系管理员。因此自己重新补上了   但是，由于时间上的原因可能会存在顺序上的差错。         先给出阅读顺序，方便自己日后查阅：                   设计模式学前思考----->-代码无错便是优?-->面向对象--->简单工厂模式

现实中有这样一种情况：有些对象的内部结构比较复杂,一般是由各种对象数据组合而来的.而且在某些  情况下,对象的属性必须按照一定的顺序赋值才有意义。这样无论是使用工厂模式、工厂方法模式亦或是抽  象工厂模式都不符合该情景。       解决上述问题，应该使用建造者模式。       建造者(Builder)模式：               建造者模式也叫生成

今天浏览一篇博客的时候看到的，觉得说的很有道理，一些疑点一下子就明了了！转载过来    留待日后巩固       在学习面向对象设计对象关系时，依赖、关联、聚合和组合这四种关系之间区别比较容易混淆。特别是后三种，仅仅是在语义上有所区别，所谓语义就是指上下文环境、特定情景等。他们在编程语言中的体现却是基本相同的，但是基本相同并不等于完全相同，这一点在我的前一篇博文《设计模式中类的

前前后后设计模式的学习也有一段日子了，自己我已经把创建型设计模式学完，自我感觉掌握   的还算可以。但是，继续学习感觉上对于设计模式里面的一些原则现在不甚明了，对于后期的理解   可能会不深刻。因此，打算将设计模式中的一些原则深刻的理解下，之后再进入结构型，行为型   模式的学习。         通过查阅资料了解了,设计模式应该遵循以下原则:

在前面一篇文章中，谈及到了设计模式的定义与分类。GOF标准将设计模式分为三类：创建型    、行为型、结构型。具体而言可以看前面文章：            http://blog.csdn.net/kiritor/article/details/8621570           学习设计模式也有一段时间了，零零散散的总算是将创建型设计模式弄明白了，现在做一些复       习工

上篇文章提及到设计模式中应遵循的设计原则，并且列出了设计模式中应当遵循的六大原则。       次篇文章主要讨论单一职责原则。             单一职责原则(SRP)：                         不要存在多于一个导致类变更的原因。简单的讲，就是一个类或接口只负责一个"职责"。              如果一个类有一个以上的职责，这些职责就耦合在一起了

在学习里氏替换原则之前，首先应该理解继承的概念与好处，我们知道在java程序设计语言     中继承是通过extends关键字实现的，那么继承到底有哪些优点呢？                 1、实现了代码共享                 2、提高了代码的重用性                 3、提高了代码的可扩展性             不过有利必有弊，继承虽然带来

依赖倒转原则，听名字感觉就十分的奇怪。“依赖”是什么？为什么要到转呢？理解这些        首先要从"依赖倒转原则"的定义入手。                依赖倒转原则：                         高层模块不应该依赖于底层模块，而是应该依赖于抽象；抽象不应该依赖于具体的                 细节；细节应该依赖于抽象。

在编程中有时候我们会发现，当我们需要一个实例，可是这个实例的创建过程十分复杂，在执行过程中    会消耗大量的时间，同时创建第一个实例和创建第二个时间的初始化信息并未改变。在此种情况下，直接New  一个实例对象显得太浪费，不合理。            那么如何避免使用new一个实例的方法，提升程序的性能呢？可以通过原型模式改善！            原型模式：

记得在设计模式学习的开始遇到一个问题: http://blog.csdn.net/kiritor/article/details/8609105       简单工厂模式在添加新类的时候必须去修改其工厂类,这种方式十分的不好,可以通过工厂方法模式加以改进.           工厂方法模式:                 定义一个用于创建对象的一个工厂接口,将对象的创建工作推迟到

喟然叹息间,旧的一年又过去了.这一年有着太多的无法忘怀的事.可是生活终将继续,            由不得我们半点的迟疑. 作为一名投身软件工程的学子来说,大学两年来的学习总会给我一种           恍然如梦的感觉.学校的学习与我们来说更像是死板的接受,而且知识面也许会是早已经过时          了的技术,这不是我想要的!略有庆幸的是自己一直在自学,也许这样的学习不过系统和

首先给一段简单的计算器的代码，基本上所有的菜鸟都做过的package com.kiritor;import java.io.BufferedReader;import java.io.Console;import java.io.IOException;import java.io.InputStream;import java.io.InputStreamReader;im

上一篇的计算器的实现中并未采用面向对象的编程方法，而只是使用面向对象的语言     在做结构化的程序设计。使得程序不容易维护，不容易扩展，更不容易复用。             面向对象的思想是将现实世界的事物抽象为一个对象，利用多态、继承、封装抽象的     思想实现业务需要，最后通过整合各模块达到高内聚、低耦合的效果。

前面学习了简单工厂模式，工厂方法模式，并且通过实例知道了他们的应用情景和优缺点。于此回顾一下：     简单工厂模式:                    一个工厂负责所有类的对象的创建,不支持无缝的新增类的类型对象的创建，不符合高内聚的             原则.(可以通过反射机制)改良一下。     工厂方法模式：                   多个工厂负责多个

CSDN的博客栏目的维修终于结束了!                在前面的文章中,我们知道为了实现程序的可维护,可扩展,灵活性更高,能够复用，只是简单的封装与     继承是不够的，而是要通过一些设计模式来降低程序的耦合度.             那么,到底何为设计模式呢?                   说到底设计模式也就是一种解决问题一种思路、方案,只是这种方案经过反复

在学习单例模式之前，首先我们必须明白为何需要单例模式。即单例模式存在的意义。考虑到    这样一种场景：在整个应用中某个类只有一个独一无二的实例，也就是"单例"，例如笔者在以前完    成的一个聊天程序的聊天窗口。有这样一种需求，即是当聊天窗口已经打开的时候不在实例化它。          基于上述描述，单例模式的存在是有其实际意义的！那么，何为单例模式呢？          单例

在学习接口隔离原则之前首先我们必须明白接口的概念。java中的接口是一些方法特征集合       其方法并未实现。                接口有其两种含义：                     1、java接口：java语言中存在的结构，具有特定的语法和结构。                            说的直白一点就是对象接口，java中的类通过关键字new