网站代码设计原则 第1篇
一些字体服务商会经常做出一些有趣的字体来供大家选择，但值得注意的是，虽然这些字体在一定程度上可以让用户产生新鲜的感觉，但是并不是每一位访客都会为此买账。事实上，一些字体确实会在某些字的辨认上给人带来困难，甚至可能会因为使用设备的不同导致一些字符无法正常的显示，如果真的出现这种问题的话，后果是十分严重的。
所以，为了保证每一位用户都能够得到良好的阅读体验，我们建议大家在进行网站建设时还是以标准字体为主，而选用哪一种标准字体，就可以按照目标群体的阅读习惯来决定了。
网站代码设计原则 第2篇
里氏替换原则(Liskov Substitution Principle，LSP)由麻省理工学院计算机科学实验室的里斯科夫(Liskov)女士在 1987 年的“面向对象技术的高峰会议”(OOPSLA)上发表的一篇文章《数据抽象和层次》(Data Abstraction and Hierarchy)里提出来的
她提出：继承必须确保超类所拥有的性质在子类中仍然成立(Inheritance should ensure that any property proved about supertype objects also holds for subtype objects)
里氏替换原则主要阐述了有关继承的一些原则
也就是什么时候应该使用继承，什么时候不应该使用继承以及其中蕴含的原理
里氏替换原是继承复用的基础，它反映了基类与子类之间的关系
是对开闭原则的补充，是对实现抽象化的具体步骤的规范
通俗来讲就是
子类可以扩展父类的功能，但不能改变父类原有的功能
也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法
如果程序违背了里氏替换原则，则继承类的对象在基类出现的地方会出现运行错误
这时其修正方法是：取消原来的继承关系，重新设计它们之间的关系
子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法，子类中可以增加自己特有的方法
当子类的方法重载父类的方法时，方法的前置条件(即方法的输入/入参)要比父类方法的输入参数更宽松
当子类的方法实现父类的方法时(重写/重载或实现抽象方法)，方法的后置条件(即方法的输出/返回值)要比父类更严格或相等
比如鸟一般都会飞行
如燕子的飞行速度大概是每小时 120 千米
但是几维鸟由于翅膀退化无法飞行
假如要设计一个实例，计算这两种鸟飞行 300 千米要花费的时间
由于几维鸟不会飞，子类修改了父类的speed方法，写死为0
拿燕子来测试这段代码，结果正确，能计算出所需要的时间
拿几维鸟来测试，结果会发生“除零异常”或是“无穷大”
这段代码的问题就在于直接修改了父类的方法
怎么解决这个问题呢，最好的办法的就是取消这种集成关系的设计
可以这么设计
网站代码设计原则 第3篇
最少知识原则（Least Knowledge Principle，简称 LKP），也叫迪米特法则（LOD）：一个对象应该对其他对象有最少的了解，说白了就是，只关联自己需要的。
我们来看个 Demo，又是那个音乐播放器，原本应该是这样的：
可以看到，播放时，只需要一个path即可。但是直接把Song给他传过去不行吗？这样后面万一需要Song里面的其他变量，比如name啥的，也不用改函数了！
其实，播放器需要的只是一个播放的路径，至于其他的，它根本不关心。如果真的需要，你再提供，但也只需要提供它需要的，不要有任何附加内容。否则，一旦那些附加内容变化了，也间接导致播放器自身的变化，这是不应该的。
我们应该只关联自己直接用到的，而不关联那些不需要的，如此一来，那些发生在我们关联范围外的事，就不会引起我们的任何改变，这样就大大提升了代码的健壮性。
开放闭合原则（Open Close Principle，简称 OCP）：一个类应该对扩展开放，对修改关闭。换句话说就是：应该多扩展代码，少修改代码。
开闭原则是最理想的原则，是所有设计模式的最终目标，基本不可能实现。它要求我们的任何改动都不修改老代码，而只添加新代码，这样就不会对老逻辑有任何影响，从而使得代码更加安全。
有人说，我们的代码不是一次性的，肯定是要修改的，怎么可能不修改呢？没错，肯定是需要修改的，但是合理运用开闭原则可以做到少修改，改得越少风险越小。
举个例子，要手写一个计算器，只需要支持简单的加减法就行，如下：
代码简单粗暴，直接使用if判断就完事。但是，如果将来要支持其他运算呢？嗯，继续添加if分支？可以，但是不太好，谁能保证你下次添加别的运算符的时候，不会手残改了别的运算呢？那么，我们能不能将新的运算不放在这个类里面呢？可以！
我们可以将每个运算定义成一个单独的类型，后面新增其他运算，只需要新加一个类就可以了。我们知道，基本的数学运算都是需要两个操作数和一个运算符的，我们可以定义一个公有的父类，来保存操作数和运算符。
定义公共父类：
加法器：
减法器：
这里我们为不同的运算符提供了不同的实现类，每个类只负责自己的计算逻辑，如果将来有其他新运算加入，我们直接再添加一个新的类即可，完全不需要修改其他类的代码。
而且我们可以看到，开闭原则中用到了单一职责（每个类只做自己的运算），还用到了最少知识（每个类只关心自己的操作数和运算符），其实就是一句话：越单纯，越干净，越好！ 因为这样自己的责任就越少，就越不容易被牵连，也就越稳定，越安全。
我们从宏观层面讲解了六大设计原则，这是 23 种设计模式的祖宗，或者说：设计模式就是这六大设计原则的具体实现，六大设计原则就是设计模式的抽象。
对于设计模式，我认为正确的学习顺序是：
学习设计原则，这是对设计思想的宏观认识。
学习设计模式，这是对设计思想的具体认识。
再学习设计原则，这是对设计思想的自我抽象
网站代码设计原则 第4篇
要使你的页面平衡，当页面有了平衡感，用户浏览这个页面的时候就会感觉它们是一个整体，看得时候目光的跳转也会更自然。但是在看起来像一个整体的同时，构成页面的元素仍然是彼此独立的，你不需要用线用颜色将它们直接地串接起来，这是为什么呢?因为它们彼此之间是平衡的。这就好比跷跷板，即便你看不到连接两端的人的木板，你也能感觉到他们是一个整体，就是因为这个“平衡”感!
1、平衡对称是最常见、最自然的平衡手段，这种方式通常用来设计比较正式的页面，不过也还需要和下面介绍的多种方式结合起来使用。
2、非对称平衡非对称其实并不是真正的“不对称”，而是一种层次更高的“对称”，如果把握不好页面就会显得乱，因此使用起来要慎重，更不可用的过滥。
3、辐射平衡页面中的元素以某一个点为中心展开就可以构成辐射平衡。
网站代码设计原则 第5篇
接口隔离原则(Interface Segregation Principle，ISP)要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法
2002 年罗伯特·C.马丁给“接口隔离原则”的定义是
客户端不应该被迫依赖于它不使用的方法(Clients should not be forced to depend on methods they do not use)
该原则还有另外一个定义
一个类对另一个类的依赖应该建立在最小的接口上(The dependency of one class to another one should depend on the smallest possible interface)
以上两个定义的含义是：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用
接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：
单一职责原则注重的是职责
而接口隔离原则注重的是对接口依赖的隔离
单一职责原则主要是约束类，它针对的是程序中的实现和细节
接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建
使用多个专门的接口，而不是使用单一的总接口
这个原则跟单一设计原则有些类似
比如我们为了在设置动物接口的时候
可以直接将动物的吃、飞、游的属性都定义到接口中
然后具体的鸟和狗都实现这个动物接口
类图如下图所示
但是这样会导致一个问题
就是小鸟一般不会游泳，但是它也会实现这个方法
狗不会飞，但是也会实现飞的方法
这样给代码的维护和使用都会造成一定的障碍
如果我们按照接口隔离原则设计
将游泳、吃、飞的方法分别用三个动物接口实现
狗和鸟分别实现其中对中的多个接口
则不仅代码结构清晰，维护起来也会非常方便
网站代码设计原则 第6篇
单一职责原则(Single Responsibility Principle，SRP)又称单一功能原则
由罗伯特·C.马丁(Robert C. Martin)于《敏捷软件开发：原则、模式和实践》一书中提出的
这里的职责是指类变化的原因
单一职责原则规定一个类应该有且仅有一个引起它变化的原因
否则类应该被拆分
该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：
一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力
当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。
网站代码设计原则 第7篇
虽然正文和标题很多时候不会使用同样的字体，但是我们仍然不建议大家在建设网站时使用三种或是更多的字体，因为如果使用字体过多的话就会使网站的结构显得非常混乱，这样会给用户的阅读带来极大地困扰。所以站长在建站时通常不会选择使用太多的字体。
如果可以的话，使用同一种字体也不会显得不好，只要通过字号的调整就可以很好的区分出每个结构间的区别。如果同一种字体真的无法满足网站的需求的话，那么我们建议不同的字体之间也不要太过跳跃，最好是较为相近，而又能够进行区分的字体。因为如果字体间的差距过大，也会严重的影响页面的美观。
网站代码设计原则 第8篇
迪米特法则(Law of Demeter，LoD)又叫作最少知识原则(Least Knowledge Principle，LKP)
产生于 1987 年美国东北大学(Northeastern University)的一个名为迪米特(Demeter)的研究项目
由伊恩·荷兰(Ian Holland)提出，被 UML 创始者之一的布奇(Booch)普及
后来又因为在经典著作《程序员修炼之道》(The Pragmatic Programmer)提及而广为人知
迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话(Talk only to your immediate friends and not to strangers)
其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用
可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性
迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法
但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性
使模块之间的通信效率降低
所以，在釆用迪米特法则时需要反复权衡
确保高内聚和低耦合的同时，保证系统的结构清晰
比如校园招聘工作
这里边应该包含学生、HR、用人部门三个角色
但是用人部门不会直接招聘
是通过向HR提交人才需求
通过HR作为中转与学生进行沟通
类图如图所示
具体用人的部门根本不需要直接跟学生接触
所有招聘工作都是通过HR完成
网站代码设计原则 第9篇
当然，在注意了行高的问题之后，每一行文本的字符数也是需要用心设计的。如果文本太短，就需要用户来回扫视，对阅读造成影响;而如果文本过长，又容易让用户无法集中注意力。
关于每一行文本的长度，也有具体的数据可供参考，针对PC端网站来说，每一行中文字符控制在35-45个字，英文字符控制在60左右是最为合适的。而对于移动端来说，由于屏幕较小，所以文本长度也应该相应的缩短。
可能很多人在浏览网站时，会发现这样一个问题：有非常多的网站都选择使用蓝色作为他们的logo或者UI的颜色，并且蓝色的出现频率要远远高于其他的任何一种颜色，那为什么大部分设计师和网站都对蓝色偏爱有加?
网站代码设计原则 第10篇
开闭原则(Open Closed Principle，OCP)由勃兰特·梅耶(Bertrand Meyer)在 1988 年的著作《面向对象软件构造》(Object Oriented Software Construction)中提出
软件实体应当对扩展开放，对修改关闭(Software entities should be open for extension，but closed for modification)
这里的软件实体包括以下几个部分：
项目中划分出的模块
类与接口
简单来说就是尽量实现在新增功能的时候不修改已经写好的代码
举个例子
实现一个商品的对象
可以先定义一个接口
其中实现一个商品的一些属性
编号、名称和价钱
具体的商品类则实现这个接口
比如实现一个食品的商品类
但是在食物商品有个问题，就是容易过期
在快过期的时候为了促销，会打折
为了能够让商品的价格发生打折
我们可以直接在修改FoodCommodity里边的代码
新增一个成员变量或者直接改返回价格的代码
但是这样其实是有风险的
有可能会导致已经写好的代码出问题
那个更好的办法就是下边这个
新实现一个DiscountFoodCommodity 打折食物的类
并继承FoodCommodity
类图是这样的
这样我们就可以在不更改FoodCommodity任何代码的情况下实现一个打折的商品
网站代码设计原则 第11篇
国画中“画鱼不画水”的妙处就是留白的妙处。留白可以让访问者有更大的想象空间，就好像就如一个没有过多摆设的房间一样。上上下下、里里外外都塞得满满当当就是很糟糕的设计。留白的原则包括：
1、元素之间的留白不能太大 这是基本的原则，留白过多，叶面会变得零碎。
2、文本中间的间隔不能太大 文本应当紧凑，尤其汉字文本，如果字与字之间或者行与行之间空白太大页面就会非常难看。总的来说平衡、对比、连贯和留白设四条原则是在网页设计中必须始终牢记，但绝不是教条，应当结合自己的实际需要灵活的应用。
从多个设计中吸收灵感
设计的基本原则
重点：选出重点最有效的做法就是列举页面所有的要素并按照重要性编号，可以重点突出最新的一片文章、表明网站用途的大字号标题或按照从上到下的顺序设置重点内容
对比 ：对比起到突出强调的作用，可以有颜色上的对比，排版上的对比(一般来说越往下文本越密集)
平衡：平衡指的是使网页左右两部分的视觉重量相当，实现方式可以通过对称平衡或不对称平衡，对称平衡几乎就是中轴对称图形，非常传统，而不对称平衡，也能够达到视觉重量平衡，但是通过中轴左右双方的不同元素来相互抵销效果来达成，也可以两种方式并用，但只有一个目的，那就是保证网页浏览的视觉稳定性
对齐： 对齐更多地体现了网页要素在视觉上的统一性，可以有多种方式，比如说logo设计与内容设计宽度一致等
重复：重复我们注重将同样的元素以不同的形式表现出来，具体可以通过颜色、形状、线条、字体、图像以及整体的风格等
流：流主要解决人们在浏览网页时候的顺序问题，在浏览过程中，人的视线会本能地分散开来，如果有合适的流来引导用户的话，就能让用户按照既定的一个通道来浏览网页，一般会形成一个回路，让用户感到很舒适
对于网站来说，其最核心的部分无疑就是网站中的内容，也就是以文字呈现给用户并供其提取信息的文本。所以在设计网站的装饰、图片、图标、按钮等部分的同时，也一定不能忽视文本的排版设计问题。清晰的排版和合适的字体、字号等都可以提升阅读体验，这也是保证用户粘度和用户使用体验的一个重要的办法。那网站在建设时文本该如何排版?
网站代码设计原则 第12篇
依赖倒置原则（Dipendence Inversion Principle，简称 DIP）：面向接口编程或面向抽象编程。
依赖倒置的官方定义：高层不应该依赖底层，两者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。其实狭义的说就是：面向接口编程，广义的说就是：面向抽象编程。也就是说，我们在使用类的时候，优先考虑使用抽象类或接口。具体一点就是：成员变量、函数参数和返回值都尽量定义成接口。
为什么要这么干呢？这么干有什么好处呢？
我们知道，接口都是抽象的，抽象的就是不确定的，不确定的就是可变的。而我们的大部分代码都是“非一次性的”，也都是需要改变的，所以，接口正合适。
换句话说，接口就是具有某种功能的某种东西，是什么我不管，只要具有这种功能就行，而我们需要的，也就是具有这种功能的东西。
比如，我需要给手机充个电，我需要的是一个“能充电的东西”，而你却对外说：“我需要个充电宝！”如果有人没有充电宝，只有电源呢，他就不认你了。在这里，你把我需要的东西具象化了，也就是把范围缩小了，范围越小越精确，就越不容易改变，这明显是不对的。
再比如，现在我要提供一个音乐播放器，我直接使用移动端的 MediaPlayer，很容易就写出了如下代码：
三分钟就写完了，使用方直接调用：
完事之后某一天，主管又问：“咱们的播放器不好用，能用那个开源的吗？”
当然可以，于是就去改，但是发现，要改的地方太多了，我不但要改MedidPlayer这个类，甚至调用我播放器的人也需要改他的User类！
这时候就应该反思了，其实User这个类，不在乎你的播放器是怎么写的，它只关心能不能播放、停止、暂停、恢复，说白了，它要的是一个具有这种功能的某种东西，而不是具有这种功能的这种东西。
用接口！
User使用：
此时User只依赖于IPlayer，而不依赖具体的实现。不管你是啥，只要具有播放器的功能就行，后面不管你怎么改变IPlayer的实现，User都不需要改变。
所以，我们可以看到面向接口的好处：低耦合，易拓展。因为接口是抽象的，依赖接口就是依赖抽象，不依赖细节，所以实现的细节怎么改都对我无影响，所以耦合就低；又因为接口是顶层的，就更容易拓展下层的细节实现。
网站代码设计原则 第13篇
单一职责原则（Single Responsibility Principle，简称 SRP）： 一个类只干一件事。
可以看到，单一职责的核心就是：只做一件事。不过，关键点就是这个“事”的范围不好定义。
比如，写一个音乐播放器，一个类负责播放，一个类负责停止，这也满足单一职责。但是，这个职责太小了。那么，如果把播放、停止、甚至下载歌曲，都塞进一个类里面呢，那就太大了。所以，职责的范围很重要，只要确定好了这个范围，那这个原则就已经实现了 90%。
那么，这个范围怎么确定呢？我们可以这么理解：一些相关的、关联性比较强的，就把它们当作同一种职责，放到一个单独的类（文件）里。
那么，怎么确定是否相关呢？看需求！这个只能看需求，没有别的方法。如果需求没有明确，那么我们就要联系现实来决定，毕竟程序的本质就是模拟现实。
比如，我在 2015 年实习的时候，IBM 公司有个考勤系统，需要添加一个指纹打卡功能。需求是这样的：部门主管以下的员工可以用指纹来打卡。
那么，这个“打卡功能”是属于员工的，是属于打卡器的？换句话说，这个打卡的函数，是写在员工类里面呢，还是写在打卡器类里面呢？需求没说啊。
那么，我们就联系现实来决定。
在现实生活中，应该是一个打卡器放在门口，员工向打卡器录入指纹，来进行打卡，说白了就是：“员工使用打卡器来打卡”，也就是：“员工使用打卡器”“打卡器打卡”，所以，打卡功能是打卡器的，员工只是使用它的这个功能。所以，这个函数应该定义在打卡器里面，员工调用打卡器的这个函数来进行打卡。
单一职责不仅可以用在类（文件）里面，也可以用在函数里面。
比如，现在需要写一个校验函数，校验用户的性别和年龄，必须是 18 岁及以上的男性才有资格，很简单的我们可以这么写：
使用：
这里有人有意见了，说这样写不太好，因为每个校验的地方都要自己弹出提示，这样就是很多重复的代码，所以提示这个逻辑应该放在checkSexAndAge()这个函数里面去，也就是下面这样：
这样就好多了，任何时候只要直接调checkSexAndAge()就行，判断了还自带提示。这在目前当然是完美的，虽然方法名不太合适。
如果有一天，我们的需求变成了：年龄不满足就开启未成年人保护模式，不需要弹出提示。我们直接删除tips()这个调用吗？这样不太好，如果别的地方也调用了这个方法，并且需要提示，就完了。所以我们应该有两个方法：方法 A 只检测，方法 B 使用 A 的检测结果并弹出提示。代码如下所示：
这里我们只抽离了一个方法，但是却反映出了单一职责的好处：职责越单一，因为修改而引起的问题就越少。换句话说就是：需求的粒度跟单一职责的优势成正比，需求越详细，越能看出单一职责的好处。所以我们要尽量避免大方法、大类、大模块，因为一个类越大，涉及的东西就越多，用到它的地方就越多，那么这个类就不能轻易修改，因为一旦修改，涉及的地方就越多，就越危险，所以我们一定要尽量避免。其实 MVC 就是一个宏观的、大的单一职责思想。
单一职责不仅适用于类和文件，还适用于函数、模块等，这是一种思想，一定要掌握。
网站代码设计原则 第14篇
前面谈到了对比，对比离不开变化，然而如果对比太多，变化也会太多，页面就会显得零乱，因此我们现在来谈“连贯”。在一个成功的页面设计中，有很多要素是必须保持一致的，这些要素通常包括：
1、布局页面的上下、左右，页面与页面中间要保持布局一致。比如如果页面上方的表格居中对齐而页面下方的表格却左对齐，那么整个页面就会很难看。
2、字体字体的大小、颜色应当基本保持一致。
3、导航栏导航栏应当保持完全一样，通常应单单独为导航栏建立一个框架页，这样就可以保证更新导航栏的时候，所有网页都会被自动更新。
网站代码设计原则 第15篇
虽然人们通常会认为绿色代表自然，绿色也是各种官方活动在宣传自然时使用的最多的颜色。但不可否认的是，看到蓝色，人们很难不会联想起蓝天或者是大海——地球的绝大部分都是蓝色的。所以蓝色本身就拥有一种潜在的亲和感，这也大致可以解释为什么大部分人都对蓝色如此偏爱。
蓝色对于色盲人群非常友好
为了使更多的人能够良好的使用产品，所以就要照顾到一些特殊人群的使用体验，如色盲群体。在色盲群体中，最为常见的是红绿色盲，而绝大部分色盲的人对于蓝色都有很高的辨识度。
以上是
网站代码设计原则 第16篇
页面排版中一个比较重要的概念就是要控制行高。行高代表文字的行间距，这个距离如何能够做到最好需要站长通过经验来进行调整，不过在一般情况下，行间距大致等于文本高度的30%，这样的设置在大部分情况下都会给用户带来最为舒适的阅读体验。
如果行高过小，就会使文本十分拥挤，阅读时很容易产生眼花的感觉;而如果行高过大，会使页面显得非常空荡，十分影响整体的美观。还有一项研究数据表明，良好的行高设置会使网站的阅读效率提高20%，这意味着用户可以从你的文章中提取到更多有用的信息。
网站代码设计原则 第17篇
依赖倒置原则(Dependence Inversion Principle，DIP)是 Object Mentor 公司总裁罗伯特·马丁(Robert )于 1996 年在 C++ Report 上发表的文章
依赖倒置原则的原始定义为：高层模块不应该依赖低层模块，两者都应该依赖其抽象
抽象不应该依赖细节，细节应该依赖抽象
其核心思想是：要面向接口编程，不要面向实现编程
依赖倒置原则是实现开闭原则的重要途径之一
它降低了客户与实现模块之间的耦合
由于在软件设计中，细节具有多变性，而抽象层则相对稳定
因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多
这里的抽象指的是接口或者抽象类，而细节是指具体的实现类
使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成
比如我们想实现一个售货员卖商品的功能
首先定义一个售货员类
然后写一个方法，他可以卖香皂
但是这么设计有一个问题
如果想让他可以卖香蕉
则需要再在上边的类中新加一个售卖香蕉的方法
如果要卖苹果，还要再加一个卖苹果的方法
这样修改代码容易造成意想不到的风险
如果采取依赖倒置的思想
将商品售卖的功能放到商品中
售货员只实现一个售卖东西(任何商品)的方法就可以了
首先定义一个商品接口
然后实现一个肥皂商品
这样在新增商品的时候
只需要将商品交给售货员就行
不需要修改任何底层代码
实际上这是一种大家非常熟悉的方式，叫依赖注入
通过方法传参的方式实现的