CISC的特点: 指令系统庞大,指令功能复杂,指令寻址方式多,指令格式多 绝大多数指令须要多个机器周期完毕 各种指令都能够訪问存储器 採用微程序控制 有专用寄存器,少量 难以用优化编译技术生成高效的目标代码程序 RISC特点: 大多数指令在单周期内完毕 LOAD/STORE结构 硬布线控制逻辑 降低指令和寻址方式的种类 固定的指令格式 注重编译的优化(三地址指令格式.较多的寄存器.对称的指令格式) *我觉得RISC与CISC的不同之处在于指令精简.寻址方式降低以及注重编译优化,这要得益于二八法则

SRP设计原则面向对象类设计的第一个原则,最优先考虑的因素 一个类应该有且仅有一个职责.所谓一个类的职责是指引起该类变化的原因,如果一个类具有一个以上的职责,那么就会有多个不同的原因 引起该类变化,其实就是耦合了多个互不相关的职责,就会降低这个类的内聚性. 也就是说每一个类只做一件事,那么什么叫做"一件事"? 比如说一个学生信息管理类,这个类有"添加学生信息". "查询学生信息". "修改学生信息". "删除学生 信

今天上午,我拿着支付中心的设计文档,给入职不久的同事讲解目前支付中心系统的应用部署情况.当时同事嗯嗯地点头反应. 下午呢,发现自己设计的有问题,赶紧给予完善. 代码重构方面讲究DRY编程原则.我们在设计流程图.时序图.应用架构图.计划.接口文档等等,同样要遵循这样的原则.让人一看就能比较明白,必要的环节只需简单的解释即可,而不用每次都重复地讲解一遍.——文档设计得不完整或存在欠缺,也会给别人的理解造成困惑. [原文档截图] [更改后] DRY(Don't repeat yourself),"不要

S.O.L.I.D 是首个 5 个面向对象设计 (OOD) 准则的首字母缩写,这些准则是由 Robert C. Martin 提出的,他更为人所熟知的名字是 Uncle Bob. 这些准则使得开发出易扩展.可维护的软件变得更容易.也使得代码更精简.易于重构.同样也是敏捷开发和自适应软件开发的一部分. S.O.L.I.D 意思是: 扩展出来的首字母缩略词看起来可能很复杂,实际上它们很容易理解. S - 单一功能原则 O - 开闭原则 L - 里氏替换原则 I - 接口隔离原则 D - 依赖反转原则

这篇文章我会不停的维护它,它将会越来越长,但它是关于我在面向对象中的一些学习的思考心得.希望对自己对各位都能实用处.     开篇前,说明一下写这篇文章的原因.原因是由于设计模式.由于设计模式里的各种模式.都是建立在这些原则之上的. 好比盖房子须要夯实的地基,或者比作数学论证中的使用到的公理.你不能说为什么盖房子一定要建立在地基之上.也不能说为什么两点一直线,三点一面这些公理为什么就这么牛逼的存在,由于这是自然规律.你必须遵守它们. 这些设计原则也类似,它们没有24种设计模式那样华丽的身姿,但它

1.端到端原则(end-to-end principle) 当我们设计一个大的系统(如操作系统或协议族)时,随之而来的一个问题通常是在什么位置实现某个功能.影响TCP/IP协议族设计的一个重要原则是端到端原则(end-to-end principle):只有在通信系统端点的应用知识的帮助下,才能完全和正确地实现问题中提到的功能.这种观点表明底层功能不应以完美为目标,这是因为对应用程序需求做出完美推测是不可能的. 2.命运共享原则(Fate-sharing) 什么是命运共享原则,以下是维基的解释:

S.O.L.I.D是Robert C. Martin提出的前五个面向对象设计(OOD)原则的首字母缩写,他更为人所熟知的名字是Uncle Bob.   将这些原理结合在一起,可使程序员轻松开发易于维护和扩展的软件.它们还使开发人员可以轻松避免代码异味,轻松重构代码,并且是敏捷或自适应软件开发的一部分.   注意:这只是一篇简单的“欢迎使用_ S.O.L.I.D ”,它只是阐明了S.O.L.I.D是什么..   更多学习内容可以访问从码农成为架构师的修炼之路 S.O.L.I.D代表: 首字母缩略词

1 变量不可以包含具体类的引用.一旦new,就对具体类产生依赖,用工厂模式来避开. 2 类不要派生至具体类.用派生抽象类避开. 3 不要覆盖基类已经实现的方法.基类中已实现的方法应该由所有子类共享.

建表高级属性 下面几个 shell 命令在 hbase 操作中可以起到很大的作用,且主要体现在建表的过程中,看 下面几个 create 属性 1. BLOOMFILTER 默认是 NONE 是否使用布隆过虑及使用何种方式,布隆过滤可以每列族单独启用 使用 HColumnDescriptor.setBloomFilterType(NONE | ROW | ROWCOL) 对列族单独启用布隆 Default = ROW 对行进行布隆过滤 对 ROW,行键的哈希在每次插入行时将被添加到布隆 对 ROW

前言 本篇博文来自一次公司内部的前端分享,从多个方面讨论了在设计接口时遵循的原则,总共包含了七个大块.系卤煮自己总结的一些经验和教训.本篇博文同时也参考了其他一些文章,相关地址会在后面贴出来.很难做到详尽充实,如果有好的建议或者不对的地方,还望不吝赐教斧正. 一.接口的流畅性 好的接口是流畅易懂的,他主要体现如下几个方面: 1.简单 操作某个元素的css属性,下面是原生的方法: document.querySelector('#id').style.color = 'red'; 封装之后 fun

http://www.ibm.com/developerworks/cn/webservices/ws-soa-design/ 引言 面向服务的体系结构(Service-Oriented Architecture,SOA)提供了支持业务灵活性的 IT 灵活性远景.在本文中,我们将重点讨论 IT 灵活性的两个特定方面:流程实现的分离和简化.如何说明和实现各个服务对 IT 灵活性的这些方面有很大的影响,因此也对业务灵活性有很大的影响.我们此处的目标是提供支持 SOA 远景的服务说明和实现指南.本文的

1. 索引设计原则 索引设计不合理或缺少索引都会对数据库的性能造成障碍,高效的索引对于获得良好的性能非常重要. 设计索引时的一些原则: ◊ 索引并不是越多越好,一个表中如果有大量的索引,不仅占用大量的磁盘空间,而且会影响INSERT.DELETE.UPDATE等语句的性能.当表中数据更改的同时,索引也会进行调整和更新. ◊ 避免对经常更新的表进行过多的索引,并且索引中的列尽可能少.而对经常用于查询的字段应该创建索引,但要避免添加不必要的字段. ◊ 数据量小的表最好不要使用索引,由于数据较少,查询

前言:有朋友问我,设计模式原则这些东西在园子里都讨论烂了,一搜一大把的资料,还花这么大力气去整这个干嘛.博主不得不承认,园子里确实很多这方面的文章,并且不乏出色的博文.博主的想法是,既然要完善知识体系,就不能半途而废.今天就来看看设计模式原则的另一个:接口隔离原则. 软件设计原则系列文章索引 C#软件设计——小话设计模式原则之:依赖倒置原则DIP C#软件设计——小话设计模式原则之:单一职责原则SRP C#软件设计——小话设计模式原则之:接口隔离原则ISP C#软件设计——小话设计模式原则之:开

软件的可维护性和可复用性 知名软件大师Robert C.Martin认为一个可维护性(Maintainability) 较低的软件设计,通常由于如下4个原因造成: 过于僵硬(Rigidity)  过于脆弱(Fragility)  复用率低(Immobility)  黏度过高(Viscosity) 软件工程和建模大师Peter Coad认为,一个好的系统设计应该具备如下三个性质: 可扩展性(Extensibility)  灵活性(Flexibility) 可插入性(Pluggabil

转载:http://space.itpub.net/17007506/viewspace-616852 腾讯QQGame游戏同时在线的玩家数量极其庞大,为了方便组织玩家组队游戏,腾讯设置了大量游戏室(房间),玩家可以选择进入属意的房间,并在此房间内找到可以加入的游戏组(牌桌.棋盘等).玩家选择进入某个房间时,必须确保此房间当前人数未满(通常上限为400),否则进入步骤将会失败.玩家在登入QQGame后,会从服务器端获取某类游戏下所有房间的当前人数数据,玩家可以据此找到未满的房间以便进入.    

[S] Single Responsibility Principle (单一职责原则) 认为一个对象应该仅只有一个单一的职责 namespace SingleResponsibilityPrinciple { class DataAccess { void InsertData() { Console.WriteLine("数据插入成功"); } // 错误的设计,不符合 单一职责原则 //void WriteLog() //{ // Console.WriteLine("

一   类的设计原则   1 依赖倒置原则-Dependency Inversion Principle (DIP) 2 里氏替换原则-Liskov Substitution Principle (LSP) 3 接口分隔原则-Interface Segregation Principle (ISP) 4 单一职责原则-Single Responsibility Principle (SRP) 5 开闭原则-The Open-Closed Principle (OCP) 二  包的设计原则   6

从今年的七月份开始学习设计模式到9月底,设计模式全部学完了,在学习期间,总共过了两篇:第一篇看完设计模式后,感觉只是脑子里面有印象但无法言语.于是决定在看一篇,到9月份第二篇设计模式总于看完了,这一篇看完,脑子里面已经能够对绝大多数的设计模式能够说出其核心思想且可以画出类图也知道应用场景,算是一个进步,但可能还不能够特别熟练的使用,可能需要多多巩固和强化使用才能够完全理解设计模式的精髓所在.学习期间收获还是不少的: 1.从只听过设计模式到学习了所有的设计模式,并写了不少设计模式的博客,在公司期间

1  概述 本章叙述面向向对象设计的七大原则,七大原则分为:单一职责原则.开闭原则.里氏替换原则.依赖倒置原则.接口隔离原则.合成/聚合复用原则.迪米特法则. 2  七大OO面向对象设计 2.1 单一职责原则SRP(Simple Responsibility Principle) 单一职责原则,就是一个设计元素只做一件事.什么是“只做一件事”?就是少管闲事.现实中也是如此,如果让一个人认真的去做一件事,那么任何人都有信心可以做到很出色.就一个类而言,应该仅有一个引起它变化的原因,如果你能想到两个

单一职责原则 (Single Responsibility Principle, SRP) 单一职责原则在设计模式中常被定义为“一个类应该只有一个发生变化的原因”,若我们有两个动机去改写一个方法,那这个方法就有两个职责.实际开发过程,修改代码本身就存在风险,特别是两个职责耦合在一起有依赖关系的时候,一个职责的变化可能对整个逻辑造成意想不到的破坏,这种耦合性得到的是低内聚和脆弱的设计. SRP原则体现为:一个对象(方法)只做一件事 何时应该分离职责 SRP 原则是所有原则中最简单也是最难正确运用的

内容总览 六大设计原则都有哪些 一.单一职责原则 二.里氏替换原则 三.依赖倒置原则 四.接口隔离原则 五.迪米特法则 六.开放封闭原则 内容详解 一.单一职责原则 单一职责原则:英文名称是Single Responsiblity Principle,简称是SRP.定义:应该有且仅有一个原因引起类的变更. 单一职责原则要求:一个接口或类只有一个原因引起变化,也就是一个接口或类只有一个职责,它就负责一件事情. 单一职责原则的好处: 类的复杂性降低,实现什么职责都有清晰明确的定义: 可读性提高,复杂