最重要的设计指导原则

作者:Scott Meyers

“设计”这项工作包括很多东西,不过当然最重要的方面之一是接口规范。接口决定了一个组件的哪些方面对哪些人是可以查阅的;它们因此决定了封装。 接口指名什么功能(数据,属性,方法等)对客户来说是可用的。接口反映了一个系统是怎样被分解成它所定制的组件的。

接口遍地都是。它们是GUI和API中的"I",但是它们比那个更加无孔不入。类和结构都有接口;函数和方法有接口;模版和名称空间有接口;子系统和模块有接口;库和应用程序有接口。不论你在软件系统开发中扮演什么角色,都会或多或少设计一些接口的设计,所以,了解一些启发式,它们暗示什么时候你做的不错,什么时候你做的糟糕,这样对你是有帮助的。随着时间的推移,我总结了一些最重要的通用接口设计指导原则如下:

使接口容易被正确地使用并且难于被错误地使用。

这条准则导致一个结论就是有些开发人员觉得不安。

接口设计者必须负责

让我们做一个合理的假设,你的客户-使用你的接口的人-正试图完成一个好的项目。他们聪明,很热情,并且有责任心。他们愿意阅读一些有助于理解正在使用的系统的文档。他们想让一切都正确的工作。

既然如此,如果他们使用你的接口时犯了一个错误,那这就是你的错误。我们假设他们尽全力而为-他们想要获得成功。如果他们失败了,原因在于你。因此,如果某个人错误地使用你的接口,不管他们是很努力地去做(很少这样)还是你的接口允许他们去做一些简单但不正确(经常是这样)的事情。这就像把鞋穿在并不合适的脚上:这意味着接口使用错误的责任在于接口设计者,而不是接口使用者。

在一个完美的世界中,坚持这条原则将保证程序正确地执行。在这样的世界中,做一些不正确的事情的程序将不会被编译,而通过编译的程序几乎做的都是正确的事情。在人机接口层,错误的命令将被拒绝,而被接受的命令则几乎当然执行做正确的事情,但是在大多数软件系统中使用的接口只要稍作努力就能得倒显著的改善。

 改善你的接口

考虑一个表示日期的(C++)类,它的构造函数可能像这样声明:

  class Date { 
public:
explicit Date(int month, int day, int year);
};
这是一个接口容易被错误使用的经典例子。因为3个参数都是一个类型的,调用者很容易将顺序搞混。按照作者的意思我们应该这样做(不过这似乎有点麻烦,没办法,老美就是牛,听他的吧):
#include <iostream>

struct Day { // thin wrapper for Day
explicit Day(int day): d(day) {}
int d;
};

struct Year { // thin wrapper for Year
explicit Year(int year): y(year) {}
int y;
};

class Month {
public:
static const Month Jan; // a fixed set of immutable
static const Month Feb; // Month objects
//...
static const Month Dec;

int number() const { return m; }

private:
explicit Month(int month): m(month) {}
int m;
};

const Month Month::Jan(1);
const Month Month::Feb(2);
//...
const Month Month::Dec(12);

class Date {
public:
explicit Date(Month m, Day d, Year y); // revised (safer,
explicit Date(Year y, Month m, Day d); // more flexible)
explicit Date(Day d, Month m, Year y) // interface
: dNum(d.d), mNum(m.number()), yNum(y.y)
{
std::cout << "D.M.Y = "
<< dNum << '.' << mNum << '.' << yNum << '/n';
}

private:
int dNum, mNum, yNum;
};


int main()
{
Date today(Day(10), Month::Jan, Year(2005));
}
接下来干什么?不翻译了,发现这翻译文章还真是挺麻烦的,以后就自己看看就行了,也没那么多的时间啊。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
计算机软件用户界面设计的基本原则 摘要:目前,大部分软件应用程序和许多Web网站都是使用图形用户界面(GUI)开发工 具构建的。这些工具都提供了一组用于构建GUI的控件,也称为"窗口小部件(widget)。控 件包括文本和数字、复选框、单选按钮、流动条、按钮、调节器(knob)。刻度盘(dial) 、标尺(meter),以及各种类型的窗口。"然而,在软件界面设计的过程中,设计的基本原则 是必须遵守的。 关键词:软件 界面 基本原则 1 基本原则1:关注用户及其任务,而不是技术 这是最重要原则,是所有原则的根本所在,是其他所有用户界面设计原则的基础—— 关注用户及其任务,而不是技术。"关注用户及其任务",这句话太过概括而显得有点含混 不清,我们需要更加详细的原则设计的准则和错误的示例,还需要针对如何关注用户、 用户任务及其数据提供一些建议。这意味着可以将它分解为以下几个问题,由此作为一个 开发项目的开始:(1)这个软件是为谁设计的?谁是目标用户?谁是目标客户?(2)这个软 件是做什么的?它打算支持什么行为?它将帮助用户解决什么问题?它将提供什么价值 ?(3)现在目标用户有什么问题?对于他们现在的工作方式,他们喜欢什么,不喜欢什么? (4)目标用户掌握哪些技能和知识?是否存在具有不同技能、知识和动机的不同类型用户 ?如果在每个软件项目设计开始时,这些问题的答案都十分明确,那么基本原则一就已经 完美地符合了。虽然这需要付出时间和资金,但却非常重要,因为在开始设计之前不明确 回答这些问题带来的代价会远远地高于你所付出的。 2 基本原则2:首先考虑功能,然后才是表示 很多GUI开发人员,甚至是许多用户界面的设计人员,都会急于首先确定应用程序的界 面看上去怎么样。要坚决杜绝这种做法!这是本末倒置的做法,虽然很诱人,但几乎总会 产生错误,它会导致产品缺乏重要的功能而包含了不必要的功能,并且难于学习和使用。 原则2应该按这种方式来理解:软件应用程序体现了特定的概念以及概念之间的关系。设 计人员应该是在设计如何向用户呈现概念之前,完整地定义概念以及它们之间的关系,更 具体地讲,不要一开始就跳转到GUI布局中。开发人员应该首先下功夫回答原则1给出的那 些任务有关的问题,然后还要明确回答以下问题:(1)这个软件将向用户展示什么概念?它 们是用户要从任务领域认识到的概念吗?或者是新概念?如果是新概念,它们能够表示成 常见概念的扩充吗?或者它们是从计算机科学引入的外来概念吗?(2)用户会用这个软件 创建、查看或操作什么数据?用户会从数据中提炼出什么信息?如何提炼?他们会用哪 些步骤?用户输入到软件中的数据来自哪里,从软件生成的数据又在哪里使用?(3)这个 应用程序会提供什么选项、选择、设置和控件?这不是一个关于如何表示控件的问题,而 是关于它们在软件中的功能、目标和角色。这是关于这个软件提供什么选项的问题。 3 基本原则3:与用户对任务的看法保持一致 软件的用户界面应当从用户的角度设计。开发人员如果不知道用户的观点是什么,就 不能进行设计。发现用户观点的最佳途径是遵循基本原则1的方法:与具有代表性的用户 服务交谈,观察他们的工作,并与他们协作,从而完成任务分析。按照用户观点进行设计有 以下三条细则。 3.1 争取自然 任务分析是我们能够知道什么"自然地"属于某个领域,而什么活动是外来的、人为的 、"不自然的"。这里有两个方面是要注意的。第一,不要让用户做不自然的事。不自然的 行为是指导用户所执行的操作与他们的目标没有明显的联系。使用户执行不自然的操作 的软件对用户来说都比较专断、不直观、不专业,因为不自然的行为难于学习却易于忘记 、费时且令人生厌。第二,加强专断的限制。软件可能侵犯用户自然直观感觉的另一方面 是给用户强加专断的或表面上专断的限制。专断的限制和不自然的操作一样,用户都很难 学会并容易忘记。 3.2 使用用户的词汇,而不是自己的 为软件或其文档撰写文本时,要避免计算机行话。应创建一个项目词典,词典应当为 用户将会看到的每个概念(对象、操作、属性)命名。词典中的术语应该与任务领域中所 使用的惯用语匹配。一旦开发出词典,软件或文档中的文本就应当严格遵守词典的规定。 3.3 让程序内部内容在程序内部进行处理 软件用户并不对软件如何运行感兴趣,他们只想实现他们的目标。因此,软件内部的 工作细节应当保留在内部,让用户看不见也想不到。这听起来不合理,但事实上将软件内 部暴露给用户是一个非常常见的用户界面禁忌。应用程序的用户界面只显示那些支持目 标任务所必需的概念,而隐藏所有其他概念,包括一般的计算机术语概念和那些只属于实 现的概念。 4 基本原则4:设计要符合常见情况 在任何任务领域中,用户都有各种目标,从常用目标到很少发生的目标。应用程序应 当设
设计模式和原则的起源可以追溯到20世纪80年代和90年代的软件工程领域。在这个时期,软件系统变得越来越复杂,开发人员面临着许多设计和构建的挑战。为了提高软件系统的可维护性、可扩展性和重用性,人们开始寻找一种通用的解决方案。 在这个背景下,一些研究者和实践者开始总结和归纳出一些成功的设计方法和技巧,形成了一些被称为设计模式的经验法则。这些设计模式是对常见设计问题的解决方案的抽象化描述,通过将经验和最佳实践进行系统化总结,提供了一种可以在不同场景中重复应用的设计思想。 同时,一些设计原则也被提出来,用于指导设计模式的应用和软件系统的设计。这些原则包括开闭原则(Open-Closed Principle)、单一职责原则(Single Responsibility Principle)、依赖倒置原则(Dependency Inversion Principle)等。这些原则主要强调代码的可维护性、可扩展性以及组件之间的松耦合关系。 至于具体的起源人物和事件,设计模式的概念最早由Christopher Alexander在建筑领域中提出,并于1995年由Erich Gamma等人在《设计模式:可复用面向对象软件的基础》一书中引入到软件工程中。而设计原则则有许多不同的来源和贡献者,如Robert C. Martin、Grady Booch等。这些人和他们的作品对设计模式和原则的发展做出了重要的贡献。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值