什么是好的API？
·        完备（Be Complete）
对确定重点支持的用户场景具有完备的功能支持。就是说，用户通过对一组API的调用能够完成预期的功能。
·        不冗余（Be Minimal）
在完备的前提下，API只提供最小的功能集合。不缺少、不冗余。
·        简单清晰（Be Simple & Clear）
接口设计简单清晰。每个接口都有自己明确的语义，并只专注于尽量单一的功能。产品概念简单、关系清楚。
·        易于学习（Be Easy to Learn & Use）
符合用户的直觉；接口设计有统一的范式，用户可以举一反三。极致是没有文档用户也知道怎样调用接口。
·        可扩展（Be Extensible）
设计具有扩展性，能够在一定程序上适应变化，API在发展中具有“后向兼容性”（backward-compatibility）。

  
笔者阅读通用设计法则一书，从中精选了一些。


无障碍使用：无障碍使用的几大要素：易读性，易操作性，简易性和包容性。简单的说，就是让用户知晓如何做->方便操作->包容错误。
引导手册：引导手册有两种：说明型引导手册和比较型引导手册。
功能可见性：比如把门把手去掉来说明这个门是用来推的。
物品拟人型：物品拥有人型特别是女人的曲线线条(比如化妆品)通常能起到更好的效果。
面积对齐：有些时候居中对齐反而显得不齐，这个时候可以用面积对齐。
魅力偏见：人们通常认为有魅力的人会表现的更出色，这个原则可用于人像营销。另外，男人最佳腰臀比例为0.9，女生最佳腰臀比例为0.7。
亲近生命效应：比如把医院的走廊两侧的墙变成植物风景。
大教堂效应：人们在不同高低的房屋中，思考方式和认知类型是不同的，在比较高的房屋中通常能激发创造力。另外，人们不喜欢在比较低矮的地方长时间停留(比如速食餐厅)。
意元集组：把不同的信息归结成模块或者单位，可以让人们对信息更好的解读和记忆。
意向整合：人们倾向于把一组单一的元素，看成一个在一起的容易辨认的单一图案。但是还有一个原则是“共同命运”，即人们通常会把向着同一个方向行动的元素看作一组。
曲线偏见：棱角和尖锐特质可以引起注意，激发思考。曲线特质可以创造积极正面的印象。
深度处理：经过理解的记忆要比死记硬背的记忆好好几倍。
偏好路径：可以用热力图来显示网站用户的偏好路径。
预期效应： 
月晕效应：雇主对于特定雇员整体呈现正面评价，因此对他们的表现评价较其他雇员较高。
霍桑效应：基于环境改变增加生产力的信念，可以有效的增加生产力。
毕马龙效应：基于对老师的期待，学生会表现的更好或者更糟糕。
安慰剂效应：基于治疗会成功的信念，病人会有好的治疗效果。
罗森塔尔效应：老师基于对学生的表现预期，对学生会有不同的态度。
需求特性：在实验或者访谈中，参与者会为了迎合访谈着的预期，提供回答并且及时作出反应。
曝光效应：重复呈现刺激物的时候会发生曝光效应，刺激物的喜爱程度通常会因此增加，比如电视广告的作用。
面子主义比例：面子主义比例高，即说明人脸部占据了大部分空间，通常被认为更聪明，更有气魄和优势。
正负形关系：位于地平线以下的元素，通常倾向被认为是图形，位于地平线以上的元素，通常倾向被认为是背景。在设计中，最下方的元素可能被认为是图形，靠近上方的区域可能被认为是背景。
费兹定律：目标越小，距离越远，移动到目标地方的时间就越长。
框架：巧妙的呈现资料可以影响用户的决策，比如酸奶广告通常说95%的“无脂”，而不会说含脂肪5%。正面框架引起正面感受。
希克定律：人们所花费的时间，与选项数目的多少息息相关。
强调手法：在一个设计作品中，强调的内容不能超过10%。
恐惧留白和价值感知：留白到底是好还是不好，这是分情况讨论的，对习惯拥有多的人来讲，少才是多。所以在做商业广告的时候，对富裕和教育程度高的观众，多采用极简主义，增加价值感高的联想，而对于贫穷活着受教育程度低的用户，则可以强化恐惧留白。
布拉哥南斯定律：属于知觉完形法则，它主张：当人们眼前出现一组含糊不清的照片的时候，倾向于用最简单的办法诠释这些元素。
最平均面孔效应：一个民族的最平均面孔，就是该族美丑定义的标准。
推动力：一个有趣的例子是，在小便池的正中心放一个靶子，尿液的喷出量会减小很多。推动力因子：预设值：预设值可以改变用户倾向，反馈：比如你不系安全带反馈出声音，诱导：比如旧的iPhone换新，组织选项：化繁为简比如选择门类，让目标被看到：可以让你知道和目标的距离。
奥卡姆剃刀原则： 
如果不必要，不要增加实体的数目。
在其他条件相等的情况下，需求较少就是好的，有价值的。
自然是在最简单的情况下运作。
对于自然事物的成因，只要解释它们的现象便足矣充分现实。
每件东西都应该越简单越好，而不是简单一点就好。
定位感：主义30度这个神奇的数字，如果目标系统和背景线条相差30度或者30度及以上就很容易被判断出来。30度也是人眼能分别的一个量度。
刺激作用：在电影开幕前秀出某人喝水的情景，会诱导更多的人去买汽水。
 
逐级展开：通过逐级展开增加人的耐心，比如现代主题公园的入口，采用逐级展开的法则，将队伍分成好几段，每一段都有不同的娱乐转移注意力。
命题密度： PD=Pd/Ps  PD 命题密度 Pd深层命题数目 Ps表层命题数。
接近法则：知觉完形法则中的一项，主张距离比较近的元素会被认为是一组。
辨认记忆：辨认记忆通常比回想记忆更为重要并且更为简单。
红色效应：红色效应法则适用于广告和产品设计，利用穿红色衣服的女性来吸引注意力，增加产品与质感的联想，而男性穿戴合适的红色衣物则可以象征力量和权威。
三分定律：一种构图的技巧。三分法。
规模缩放谬误：系统在不同的比例规模中表现是不同的，不能认为把蚂蚁放大还能够举起50倍的东西，因为小的蚂蚁受到的地心引力非常小。
序列效应：排在开头和结尾的元素会更多的被记忆，开头的元素对应“初始效应”，结尾的元素对应“时近效应”。
相似性：相似性也属于知觉完形法则，我们认为外形相似的元素是一个组。
对称：人们倾向于把对称看做成图形影像而不是背景。
光源偏见：人们的光源偏见表现为：由下到上的光源会让人觉得恐怖。
凡勃伦效应：价格和需求量呈正比的物体：容易被他人看到，和地位以及影响力有所关系并且不容易被仿造的物品。
范雷斯托夫效应：如果某元素和周围一组元素明显不同，大家会倾向于记住这个元素，比如一串字母中的数字。

hibernate作为一款优秀的数据库持久化框架，在现实的运用中是非常广泛的。它的出现让不熟悉sql语法的程序员能开发数据库连接层成为一种可能，但是理想与现实永远是有差距的。开发过程中如果只使用hql进行操作，并且表之间的关联配置很复杂的话，这将成为一种噩梦。还好我们伟大的hibernate支持原生的sql操作，这也大大的增加了hibernate的灵活性。下面我们探讨一下hibernate的dao层的通用设计。
首先阐明一下显示情况中遇到的问题。假设数据库中有一张表，表名叫tbl_user,项目中对应的实体User，根据MVC的分层设计，我们会有UerDao的接口层，以及UserDaoImpl的接口实现层。对数据库最多的操作就是增删改查，我们的UserDao和UserDaoImpl中会有增删改查的方法。如果有多张表的时候，我们会发现Dao的接口层以及实现层充斥着大量的增删改查的代码，而且大部分情况这些代码都是类似的，那我们能不能将这些代码进行封装呢？答案是肯定的。
下面进入正题，数据库使用mysql,创建一张名为tbl_user的表。

CREATE TABLE `tbl_user` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(30) COLLATE utf8_unicode_ci DEFAULT NULL,
  `login_name` varchar(30) COLLATE utf8_unicode_ci DEFAULT NULL,
  `pass_word` char(32) COLLATE utf8_unicode_ci DEFAULT NULL,
  `role_id` bigint(20) DEFAULT NULL,
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `last_login_time` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `del_flag` enum('0','1') COLLATE utf8_unicode_ci DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci COMMENT='用户表';


然后我们创建一个实体User对应这张表。


@Entity
@Table(name = "tbl_user")
public class User extends IdEntity implements Serializable {
	private static final long serialVersionUID = 1L;

	// 创建时间
	private Date createTime;

	// 删除标记
	private String delFlag;

	// 最后登录时间
	private Date lastLoginTime;

	// 登录名
	private String loginName;

	// 姓名
	private String name;

	// 密码
	private String passWord;

	// 角色id
	private Long roleId;

	@Temporal(TemporalType.TIMESTAMP)
	@Column(name = "create_time")
	public Date getCreateTime() {
		return createTime;
	}

	public void setCreateTime(Date createTime) {
		this.createTime = createTime;
	}

	@Column(name = "del_flag")
	public String getDelFlag() {
		return delFlag;
	}

	public void setDelFlag(String delFlag) {
		this.delFlag = delFlag;
	}

	@Temporal(TemporalType.TIMESTAMP)
	@Column(name = "last_login_time")
	public Date getLastLoginTime() {
		return lastLoginTime;
	}

	public void setLastLoginTime(Date lastLoginTime) {
		this.lastLoginTime = lastLoginTime;
	}

	@Column(name = "login_name")
	public String getLoginName() {
		return loginName;
	}

	public void setLoginName(String loginName) {
		this.loginName = loginName;
	}

	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}

	@Column(name = "pass_word")
	public String getPassWord() {
		return passWord;
	}

	public void setPassWord(String passWord) {
		this.passWord = passWord;
	}

	@Column(name = "role_id")
	public Long getRoleId() {
		return roleId;
	}

	public void setRoleId(Long roleId) {
		this.roleId = roleId;
	}

}
好了，下一步我们要进行要进行dao层代码的编写。但是现在不能写，我们的解决方案还没有理出来。首先我们可以肯定的是常规的CRUD代码不能写在UserDao和UserDaoImpl中了，那写在哪里呢。遇到这种情况首先想到的就是继承，如果有一个父类具有这种能力的话，再去继承这个父类，问题就迎刃而解了。好，方案确定，动手操作吧。我们先创建一个接口，命名为BaseDao，这里用到了接口泛型的概念。


public interface BaseDao<T> {
	
	/*
	 * 持久化对象的方法
	 */
	public long add(T t);
	
	/*
	 * 修改对象
	 */
	public void update(T t);
	
	/*
	 *  删除对象
	 */
	public int delete(long id);
	
	/*
	 *  查找所有对象的方法
	 */
	public List<T> getAll();
	
	
	/*
	 * 根据id查找对象
	 */
	public T getById(long id);
	
	/*
	 * 根据map条件查找对象
	 */
	public List<T> getByMap(Map<String,Object> map);
	
	
	/*
	 * 查询条数
	 */
	public int countBySql(String sql);
	
	/*
	 * 执行hql语句
	 */
	public int executeHql(String hql);
	
	/*
	 * 执行sql语句
	 */
	public int executeSql(String sql);
	
		
	/*
	 *根据sql语句查询map集合
	 */
	public List<Map<String,Object>> getMapListBySql(String sql);
}


上面的顶层接口BaseDao定义了一些常用的dao层操作。我们在接口层再定义一个实体User对应的dao接口UserDao。




public interface UserDao extends BaseDao<User> {
	
}
接口UserDao中什么方法都没有定义，只是去继承了BaseDao。接下来我们要编写dao实现层的代码了，首先我们编写dao实现层整个父类的BaseDaoImpl的代码，这个时候我们停一下整理一下思路。父类BaseDaoImpl要具有CRUD的操作，并且要是动态的，就是不同的操作要相应的操作不同的表，在hibernate中我们也可以说是操作不同的实体。如何实现这种想法呢？答案还是泛型，在继承父类BaseDaoImpl的时候注入自己的真实类型。下面就是BaseDaoImpl的代码，这也是最核心的地方。



public class BaseDaoImpl<T> implements BaseDao<T>{
	

	@Autowired
	private SessionFactory sessionFactory;
	
	protected Class<T> clazz;
	
	
	
	/**
	 * 构造方法自动注入真实的对象类型
	 */
	public BaseDaoImpl() {
		ParameterizedType type = (ParameterizedType) this.getClass().getGenericSuperclass();
		clazz = (Class<T>) type.getActualTypeArguments()[0];
	}

	public Session getCurrentSession() {
		return this.sessionFactory.getCurrentSession();
	}
	
	@Override
	public long add(T t){
		if (t!=null) {
			return (Long) this.getCurrentSession().save(t);
		}
		return 0;
	}
	
	

	@Override
	public void update(T t){
		if (t!=null) {
			this.getCurrentSession().update(t);
		}
	}
	
	
	@Override
	public int delete(long id){
		String hql = "delete "+clazz.getSimpleName()+" where id="+id;
		return this.getCurrentSession().createQuery(hql).executeUpdate();
	}
	
	
	@Override
	public List<T> getAll(){
		String hql = "from "+clazz.getSimpleName();
		return this.getCurrentSession().createQuery(hql).list();
	}
	
	
	
	@Override
	public T getById(long id){
		String hql = "from "+clazz.getSimpleName()+" where id="+id;
		return (T) this.getCurrentSession().createQuery(hql).uniqueResult();
	}
	
	
	@Override
	public List<T> getByMap(Map<String,Object> map){
		Set<String> set = map.keySet();
		if (set.size()>0) {
			List<String> list = new ArrayList<String>();
			for (String string : set) {
				list.add(string);
			}
			String hql = "from "+clazz.getSimpleName()+" where ";
			for(int i=0;i<=list.size()-1;i++){
				if (i==0) {
					hql += list.get(i)+"='"+map.get(list.get(i))+"'";
				}
				else{
					hql += " and "+list.get(i)+"='"+map.get(list.get(i))+"'";
				}
			}
			return this.getCurrentSession().createQuery(hql).list();
		}
		return null;
	}
	
	
	@Override
	public int countBySql(String sql){
		SQLQuery q = this.getCurrentSession().createSQLQuery(sql);
		return ((BigInteger) q.uniqueResult()).intValue();
	}
	
	@Override
	public int executeHql(String hql){
		Query q = this.getCurrentSession().createQuery(hql);
		return q.executeUpdate();
	}

	
	@Override
	public int executeSql(String sql){
		SQLQuery q = this.getCurrentSession().createSQLQuery(sql);
		return q.executeUpdate();
	}



	@Override
	public List<Map<String, Object>> getMapListBySql(String sql) {
		SQLQuery query = this.getCurrentSession().createSQLQuery(sql);
		query.setResultTransformer(Transformers.ALIAS_TO_ENTITY_MAP);
		return(List<Map<String, Object>>) query.list();
	}


}
BaseDao中的方法上已经写了注释，所以下面的实现类我就偷懒没有写注释了。我们重点研究其中一个方法






我们在BaseDaoImpl中定义了一个全局变量clazz,利用BaseDaoImpl的构造方法将通过泛型传进来的真是类型的Class传到此变量中。此时，在这里可能会产生一个疑问，如果使用了spring，所有的bean管理都是由spring来完成的话，此处的构造方法会得到调用吗？答案是肯定的，spring创建bean的时候也是通过调用构造方法创建bean实例的。得到此class后我们就可以利用反射机制得到实体的真实名称进行hql的拼接。好了，我们可以去实现UserDao这个接口了。


@Repository
public class UserDaoImpl extends BaseDaoImpl<User> implements UserDao {
		
}


我们只要在实现UserDao接口的同时同时继承BaseDaoImpl这个父类，把实体的真实类型传进去就行了。虽然UserDaoImpl中一个方法都没有，实际上它已经具有父类中的所有方法了。BaseDao代码中只是示例了几个常用的方法，现实中可以进行扩充，比如分页的方法之类的，在BaseDaoImpl去实现就可以了。如果UserDaoImpl需要的方法在父类中没有，并且方法具有特殊性的话，可以在UserDao定义此方法，在UserDaoImpl中去实现就可以了。其他实体所对应的Dao层操作也是一样。

[来 源] UIGarden　　[作 者] The Center for Universal Design　　[发表时间] 2005-11-18 8:27:56 
本文的作者， 一群架构设计师，产品设计师，工程师和环境设计研究人员，一起共同建立了以下一些通用设计的原则以引领广义设计学科，包括环境，产品和交流等。这七项原则可供应用于评估已有的设计， 引导设计过程以及使设计师和消费者都了解更可用的产品和环境的特征。

原则的陈列格式


原则的名称 （原则中包涵的关键核心概念的简短声明） 
原则的定义（原则对于设计的主要指示的简要描述） 
指导方针 （符合原则的设计应表现的关键元素的列表） 
图片（应用了原则的图片示例） 

通用的设计
对于产品的设计和环境的考虑应该是尽最大可能面向所有的使用者，而不应该为一些特别的情况而作出迁就和特定的和设计。

原则一：公平地使用

对具有不同能力的人，产品的设计应该是可以让所有人都公平使用的。

指导方针：


所有用户使用该产品的使用方式应该是相同的：尽可能完全相同，其次求对等。 
避免隔离或甚至指责任何使用者 
提供所有使用者同样的私隐权，保障和安全 
使所有使用者对产品的设计的感兴趣、有使用愉快的感觉 

原则二：可以灵活地使用

设计要迎合广泛的个人喜好和能力

指导方针：


提供多种使用方法以供选择 
支持惯用右手或左手的处理或使用 
保证使用的精确性和明确性. 
能够适应使用者的进步并予之并驾齐驱 

原则三：简单而直观

设计出来的使用方法是容易理明白的，而不会受使用者的经验，知识，语言能力及当前的集中程度所影响

指导方针：


排除不必要的复杂性 
要尽量与使用者的期待和直观感觉一致 
适应一个大范围的语言能力和文化程度 
将信息按其重要性排列 
每当完成任务之后提供有效的实时反应和反馈能力 

原则四：能感觉到的信息

无论四周的情况或使用者是否有感官上的缺陷，都应该把必要得信息传递给到对使用者

指导方针：


使用不同的表达形式（例如：图形化的，语言化的，触觉性的），将必要的信息以多种形式展现出来 
必要信息和其周围环境应该有明显对比（即，突出必要信息） 
最大化基本信息的“可读性” 
把各个元素按照描述的方式分类，从而以更容易得方式给出使用说明 
提供对不同的技术和装置，从而满足感官上有缺陷的人士的需求 

原则五：容错能力

设计应该可以让误操作或意外动作所造成的反面结果或危险的影响减到最少

指导方针：


按排好元素，使其减少危险和错误：最常用的组件，应该最容易的可以使用；具有危险性的组件则要除去，隔离或屏蔽掉 
每当危险或错误出现的时候提供警告字句 
提供失败安全机制 
避免在操作中所作出的无意义的动作，尤其要避免具有危险性的动作 

原则六：尽可能的减少体力上的付出

设计应该尽可能得让使用者有效地和舒适地使用，而丝毫不费他们的气力

指导方针：


让使用者保持他们不偏不倚的身体位置 
采用合理的操作焦点 
减少重复的动作 
最小化所承受的体力上的付出 

原则七：提供足够的空间和尺寸，使使用者能够接近使用

提供适当的大小和空间，让使用者接近、够到、操作，并且不被其身型、姿势或行动障碍的影响

指导方针：


为一些重要的组件提供一个无论对坐或站的使用都清晰可见的提示 
务必使所有的组件都可以被坐或站的使用者都可以接解到 
对不同大小的手掌和紧握的大小提供不同的适应 
为使用那些辅助装置或使用这些装置的人提供足够的空间 

请注意，通用设计的原则仅仅关注通用的可用的设计，而设计实践包含的并不仅仅是可用性的考虑。设计师必须在他们的设计过程中同样引入其它的注意事项，例如经济，工程，文化，性别以及环境等等。这些原则为设计师提供了更好的整合迎合最多用户需求的特色的指导方针。

图例说明

出现在所有通用设计原则里的图例的说明。

原则一：公平地使用

图例说明
两个顾客，一个是推着购物车而另一个是使用轮椅的，他们都走过一扇开了的自动门。

原则二：可以灵活地使用

图例说明
左手使用的大把手在右边的剪刀，另一对大把手在左边的适用于右手使用。

原则三：简单而直观

图例说明
进口家具的安装说明，仅有图例，没有文字的描述。

原则四：能感觉到的信息

图例说明
一个有视觉障碍的人，在很靠近地操作一个很细辐度的恒温器。该恒温器的刻度不仅用很大的数字来表示、还有可以触碰的指针、和声音提示。

原则五：容错能力

图例说明
计算机的菜单，指针指向“取消（Undo）”功能。

原则六：减少体力上的付出

图例说明
一只握拳的手向下按动杠杆门把手来推开一扇门。 

原则七：提供足够的空间和尺寸，使使用者能够接近使用

图例说明
坐在电动轮椅上的妇女经过一个很宽的地铁检票口。

 

由通用设计的鼓吹者编辑。 姓名依字母顺序依次为： Bettye Rose Connell, Mike Jones, Ron Mace, Jim Mueller, Abir Mullick, Elaine Ostroff, Jon Sanford, Ed Steinfeld, Molly Story, 和Gregg Vanderheiden. 
 

主要研究资金提供者：国家残疾和恢复研究员，美国教育部。 

Copyright 1997 NC State University, The Center for Universal Design