自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+

  • 博客(24)
  • 收藏
  • 关注

原创 不要迷失在技术的海洋中

  不要迷失在技术的海洋中     技术就好像一片汪洋大海,越深入越望不到边际。就拿自己的体验来说吧,2000年的时候在学校搞ASP,觉得网页开发就是这么简单,把数据库中的数据格式化一下显示在页面上,把用户的输入组装成添加删除和修改的SQL提交到数据库中去。几年后的今天,我对自己了解或听说过的ASP.NET相关(注意:仅仅是ASP.NET或者说网站制作相关)技术列了一下:

2007-10-28 19:09:00 723

原创 (原创)无废话C#设计模式之二十一:Visitor

 无废话C#设计模式之二十一:Visitor 意图        实现通过统一的接口访问不同类型元素的操作,并且通过这个接口可以增加新的操作而不改变元素的类。 场景 想不出什么好例子,我们在组合模式的那个例子上进行修改吧。我们知道,无论是游戏大区、游戏服务器还是游戏的服务都是一个元素,只不过它们的层次不一样。对于这样的层次结构,我们使用了组合模式来统一

2007-10-21 15:10:00 438

原创 (原创)无废话C#设计模式之二十二:总结(针对GOF23)

  无废话C#设计模式之二十二:总结(针对GOF23) 比较  设计模式 常用程度 适用层次

2007-10-21 15:10:00 497

原创 (原创)无废话C#设计模式之二十:Mediator

 无废话C#设计模式之二十:Mediator 意图        用一个中介对象来封装一系列对象的交互。中介者使得各对象不需要显式相互引用,从而使其松散耦合,而且可以独立地改变它们之间的交互。 场景 我们知道,一个网络游戏往往有很多大区。每一个大区可以是一组服务器,也可以是多组服务器,在这里假设一个大区是一组服务器。为了效率,一般每个大区都会有一个数据

2007-10-21 11:10:00 458

原创 (原创)无废话C#设计模式之十九:Observer

  无废话C#设计模式之十九:Observer 意图        定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。 场景 这次不说游戏了,假设我们需要在一个Web页面上分页显示数据。首先需要一个分页控制器和一个显示数据的表格。开始,客户的需求很简单,需要两个向前翻页向后翻页的按钮作为控制器,还

2007-10-20 10:10:00 427

原创 (原创)无废话C#设计模式系列文章

本系列文章从公司内部的知识分享修改而来,有错误或误导请指出。谢谢。(原创)无废话C#设计模式之一:开篇 (原创)无废话C#设计模式之二:Singleton (原创)无废话C#设计模式之三:Abstract Factory(原创)无废话C#设计模式之四:Factory Method (原创)无废话C#设计模式之五:Prototype (原创)

2007-10-17 16:10:00 661

原创 (原创)无废话C#设计模式之十八:Command

 无废话C#设计模式之十八:Command 意图        将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤消的操作。 场景        我们知道,网络游戏中的客户端需要不断把当前人物的信息发送到游戏服务端进行处理(计算合法性、保存状态到数据库等)。假设有这样一种需求,在服务端收到客户端的请

2007-10-17 15:10:00 431

原创 (原创)无废话C#设计模式之十七:Chain Of Resp.

 无废话C#设计模式之十七:Chain Of Resp. 意图        使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象能处理请求为止。 场景 假设我们在制作一个游戏的客服系统,客服有三种角色,分别是普通客服、客服经理和客服总监。玩家在网站中提问后,根据问题的分类

2007-10-14 21:11:00 380

原创 (原创)无废话C#设计模式之十六:State

 无废话C#设计模式之十六:State 意图        允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。 场景        我们在制作一个网上书店的网站,用户在书店买了一定金额的书后可以升级为银会员、黄金会员,不同等级的会员购买书籍有不同的优惠。你可能会想到可以在User类的BuyBook方法中判断用户历史消费的金额来给用

2007-10-13 15:11:00 438

原创 (原创)无废话C#设计模式之十五:Strategy

 无废话C#设计模式之十五:Strategy 意图        定义一系列的算法,把它们一个一个封装起来,并且使它们可相互替换。本模式使得算法可以独立于它的客户而变化。 场景        在开发程序的时候,我们经常会根据环境不同采取不同的算法对对象进行处理。比如,在一个新闻列表页面需要显示所有新闻,而在一个新闻搜索页面需要根据搜索关键词显示匹配的新

2007-10-13 12:11:00 382

原创 (原创)无废话C#设计模式之十四:Template Method

  无废话C#设计模式之十四:Template Method 意图        定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。 场景 模版方法是非常容易理解的设计模式,一来是因为它没有过多结构上的交错,二来是因为这种代码复用技术对于掌握OO知识的人来

2007-10-12 14:11:00 343

原创 (原创)无废话C#设计模式之十三:Decorator

 无废话C#设计模式之十三:Decorator 意图        动态地给一个对象添加一些额外的职责。就增加功能来说,Decorator模式相比生成子类更为灵活。 场景 在设计网络游戏的武器系统时,开始并没有考虑到武器的强化和磨损。之后,策划人员说希望给游戏增加强化系统和修理系统,那么我们的武器类型就需要对外提供强化、磨损、修理等方法了。发生这种改动

2007-10-12 13:11:00 396

原创 (原创)无废话C#设计模式之十二:Bridge

  无废话C#设计模式之十二:Bridge 意图        将抽象部分与实现部分分离,使它们都可以独立的变化。 场景 还是说我们要做的网络游戏,多个场景需要扩充的问题我们已经采用了创建型模式来解决。现在的问题就是,不仅仅是游戏场景会不断扩充,而且游戏的模式也在不断扩充。比如,除了最基本的战斗模式之外,还会有道具模式,金币模式等。对于这种在多个维

2007-10-11 16:11:00 351

原创 (原创)无废话C#设计模式之十一:Composite

 无废话C#设计模式之十一:Composite 意图        将对象组合成树形结构以表示“部分-整体”的层次结构。Composite模式使得用户对单个对象和组合对象的使用具有一致性。 场景 我们知道,一个网络游戏通常会有多个游戏大区。每一个游戏大区会有很多游戏服务器(一个游戏大区就是一组游戏服务器)。每一个游戏服务器上会有不同的服务(可以是多个服

2007-10-11 08:11:00 315

原创 (原创)无废话C#设计模式之十:Flyweight

 无废话C#设计模式之十:Flyweight 意图        运用共享技术有效地支持大量细粒度的对象。 场景 在比较底层的系统或者框架级的软件系统中,通常存在大量细粒度的对象。即使细力度的对象,如果使用的数量级很高的话会占用很多资源。比如,游戏中可能会在无数个地方使用到模型数据,虽然从数量上来说模型对象会非常多,但是从本质上来说,不同的模型可能也就

2007-10-09 17:11:00 358

原创 (原创)无废话C#设计模式之九:Proxy

  无废话C#设计模式之九:Proxy 意图        为其他对象提供一种代理以控制对这个对象的访问。 场景 代理模式非常常用,大致的思想就是通过为对象加一个代理来降低对象的使用复杂度、或是提升对象使用的友好度、或是提高对象使用的效率。在现实生活中也有很多代理的角色,比如明星的经纪人,他就是一种代理,经纪人为明星处理很多对外的事情,目的是为了节省被

2007-10-08 18:11:00 323

原创 (原创)无废话C#设计模式之八:Facade

 无废话C#设计模式之八:Facade 意图        为子系统中的一组接口提供一个一致的界面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。 场景        在一个为游戏充值的网站中,创建订单需要与三个外部接口打交道:l         用户系统:根据用户名获取用户ID、查看用户是否已经激活了游戏l     

2007-10-07 18:11:00 498

原创 (原创)无废话C#设计模式之七:Adapter

 无废话C#设计模式之七:Adapter 意图        把一个类的接口变换成客户端所期待的另一种接口,从而使原本接口不匹配而无法在一起工作的两个类能够在一起工作。 场景        假设网络游戏的客户端程序分两部分。一部分是和服务端通讯的大厅部分,大厅部分提供的功能有道具购买、读取房间列表、创建房间以及启动游戏程序。另一部分就是游戏程序了,游戏

2007-10-07 16:11:00 384

原创 (原创)无废话C#设计模式之六:Builder

 无废话C#设计模式之六:Builder 意图        将一个复杂的构建与其表示相分离,使得同样的构建过程可以创建不同的表示。 场景        在电脑城装机总有这样的经历。我们到了店里,先会有一个销售人员来询问你希望装的机器是怎么样的配置,他会给你一些建议,最终会形成一张装机单。和客户确定了装机配置以后,他会把这张单字交给提货的人,由他来准备

2007-10-07 13:11:00 328

原创 (原创)无废话C#设计模式之五:Prototype

 无废话C#设计模式之五:Prototype 意图        用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。 场景        游戏场景中的有很多相似的敌人,它们的技能都一样,但是随着敌人出现的位置不同,这些人的能力不太一样。假设,我们现在需要把三个步兵组成一队,其中还有一个精英步兵,能力特别高。那么,你或许可以创建一个敌人抽象

2007-10-06 18:11:00 339

原创 (原创)无废话C#设计模式之四:Factory Method

 无废话C#设计模式之四:Factory Method 意图        定义一个创建产品对象的工厂接口,将实际创建工作推迟到子类中。 场景        上次,我们使用抽象工厂解决了生产一组产品的问题,但是我们把各个场景作为了具体工厂来生产场景模式和场景纹理两个产品。在调用代码中也并没有出现具体工厂的影子。其实,场景类要做的不仅仅是创建具体的产品系

2007-10-06 14:11:00 337

原创 (原创)无废话C#设计模式之一:开篇

 无废话C#设计模式之一:开篇 什么是设计模式?        什么是少林拳呢?少林拳是少林僧人经过长期的总结,得出的一套武功套路。有一本叫做少林拳法的武功秘籍,上面记载这这套拳法的适用人群,打法套路和学成后的效果。设计模式虽然记录在了设计模式一书上,但是要真正掌握设计模式光靠看每一个模式的结构并且进行模仿是不够的。试想一下,在真枪实战的情况下,谁会和你按照少林拳法,

2007-10-05 20:11:00 455

原创 (原创)无废话C#设计模式之三:Abstract Factory

  无废话C#设计模式之三:Abstract Factory 意图        提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。 场景        还是上次说的那个网络游戏,定下来是一个休闲的FPS游戏。和CS差不多,8到16个玩家在游戏里面分成2组对战射击。现在要实现初始化场景的工作。要呈现一个三维物体一般两个元素是少不了的,

2007-10-05 14:11:00 379

原创 (原创)无废话C#设计模式之二:Singleton

  无废话C#设计模式之二:Singleton 意图        保证一个类只有一个实例,并提供访问它的全局访问点。 场景        我们现在要做一个网络游戏的服务端程序,需要考虑怎么样才能承载大量的用户。在做WEB程序的时候有各种负载均衡的方案,不管是通过硬件实现还是软件实现,基本的思想就是有一个统一的入口,然后由它来分配用户到各个服务器上去。

2007-10-05 13:11:00 395

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除