Adobe Flex 3最有趣的特征之一 :Web设计者和开发者的相遇

 

著：Yakov Fain 译：叶进

Adobe将于2008年二月左右发布Flex 3.它有增加了一些新的改进和特色，尤其是它将使Flash设计者和Flex开发者结合在一起。CS3可以很容易的使Flex融入到Flash IDE的发布时间线上。Flash中的容器创建在Flex中将会得到足够多的发展。为了开发Flash CS3，你必须要有个一个Flex组件工具包。这就使得Flash艺术拥护者必须去学习至少一点点Flex的基础知识，那会使他们获得在接下来的几年中获得更多的市场。

在今年的早些时候，我看到MS发布了Sliver流。我对这种可以被一个对于Web设计一窍不通的人开发的绚丽的GUI应用印象非常深刻。他（用时间线）创建了一个绚丽的画面，并且为Sillverlight开发者增加了添加他们自己写代码的地方。现在，Flash设计者也可以非常简单地就整合Flex为他们的作品添加代码了。

只要看看这段5分钟的youtube视频，你就知道我在说什么了。新一代的用户体验专家将获得更好的工具和动机去获得、学习新的技能。但是，针对艺术家的编程介绍应该更优雅一点——他们是不一样的人群，同时如果你用编程术语的话，可能会把他们吓跑。我对于这个有切身的体会，因为我的儿子，一个接受过专业培训的漫画家和漫画创作者对Flash IDE非常精通，却拒绝对于编程做任何事情。在很多场合，我都试图使他确信通过学习一些编程知识赚取更多的钱是一件好事。但是，到现在位置，我还没有成功，当然我会继续劝说他的，特别是当Flex 3发布的时候。那些认识到Web设计和编程开发是未来的人将会有一个无边的发展（People who realize that knowing of Web design and programming is the future will have an edge.）！

漫谈C#之关键字（1）

    每一种语言都有非常多的关键字，而且这些关键字也都大同小异，不过毕竟还是有些许的不一样。有些关键字大家碰到的多了，自然就熟悉了，但是有些关键字用得不大多，或者是新引入的，所以就不大熟悉了。我平常在用的时候，就是会碰到一些关键字，感觉有点生疏，平常也会把这些我不懂的关键字的用法了解一下并记录下来。想到应该也有很多跟我同样的人，所以就把我的记录跟大家分享一下。请各位tx多多指正！
访问关键字
    base：用于派生类中访问基类的成员

• 调用基类上已被其他方法重写的方法

  1 public override void GetInfo()
  2 {
  3 base.GetInfo(); // 调用基类上的GetInfo方法
  4 }

• 指定创建派生类实例时应用的基类构造函数

  1 public MyDerived() : base() // 调用基类的构造函数
  2 {}

    从静态方法中使用base关键字是错误的。
转换关键字
explicit：用于声明用户定义的显式类型转换运算符

1 class MyType
2 {
3 public static explicit operator MyType(int i)
4     {
5 // 从int转换到MyType类型的代码
6     }
7 }

显式转换运算符必须通过类型转换调用

1 int i;
2 MyType x = (MyType)i; // int到MyType类型的转换需要进行类型转换

    如果转换操作可能导致异常或信息丢失，则应用explicit关键字标记它。
    implicit：用于声明用户定义的隐式转换运算符 

1 class MyType
2 {
3 public static implicit operator int(MyType m)
4     {
5 // 从MyType转换到int类型的代码
6     }
7 }

1 MyType x;
2 int i = x;  // 隐式地调用MyType的MyType到int类型的转换运算符

隐式转换可以通过消除不必要的类型转换来提高源代码的可读性。
    一般情况下，调用某一个隐式转换时，应当绝不会引发异常，并且不会造成信息丢失。否则，应将其标记为explicit。
方法参数关键字
    如果声明方法的参数时没有指明ref或out，该参数将具有与该方法相关的值。这个值在方法中能被更改，但是当程序返回到调用过程时，这种改动不会被保留。

    params：用于指定在参数数目可变时带有参数的方法参数
    在方法声明中的params关键字之后不允许引入任何其他参数，但在其前面可以有其他参数。而且在方法声明中只允许使用一个params关键字。

 1 public static void UseParams(params int[] list)
 2 {
 3 for(int i = 0; i < list.Length; i++)
 4     {
 5         Console.WriteLine(list[i]);
 6     }
 7 }
 8
 9 public static void Main()
10 {
11     UseParams（1,2,3）;
12 int[] myArray = new int[3] { 10,11,12 };
13     UseParams(myArray);
14 }

    ref、out  使方法可以引用传递到该方法的那一个变量，当程序转至调用方法时，在方法中对参数所做的任何改动都将传给该变量。
    ref参数的值将被传递到ref参数，故必须首先初始化；而out参数不然，它的值不会被传递到该out参数，故不必首先初始化，但它必须在方法返回以前为out参数赋值。
    属性不是变量，不能作为ref/out参数。

《.NET设计规范》——学习笔记（2.5）框架设计基础

这篇文章在一定程度上是对前面几篇文章的一个总结。

一个成功的通用框架必须是为广大具有不同的需求、技能和背景的开发人员而设计的。框架设计师面临的最大挑战是为这些多样化的用户群提供即简单又功能强大的框架。

• 要设计即功能强大又易于使用的框架。
  80/20原则。 要把精力集中在框架中使用最为频繁的部分（20%）
• 要明确地为具有不同编程风格、需求、技能以及使用不同编程语言的开发人员设计框架。
• 要了解哪些使用多语言框架的广大开发人员。
  我们往往会只为自己设计API，而没有清楚地考虑用户的真正需求。

渐进框架

针对不同的使用场景，为不同的开发团体提供不同的产品，这种多框架的方法在某种程度上说是成功的，比如MS有Visual Basic程序库，有Win32程序库，也有MFC和ATL，但它也存在严重的缺点：多框架使得使用某个框架的开发人员难以将他们的知识转移到下一个技能等级或使用场景（这通常需要另一个框架）。

• .NET框架所做的是把VB、MFC、ATL、ASP等这些模型统一起来。无论开发人员使用何种编程语言或者选择何种编程模型，可供使用的API始终都是一致的。
  一个更好的方法是提供渐进框架（Progresive framework）。  从无到有，慢慢积累知识，并应用到以后更高级的使用场景中去。
• .NET框架就是一个渐进框架。
  渐进框架的目标是覆盖广大的开发人员，但并不是所有可能的开发人员。
  这也应了没有十全十美这句话：不可能满足每一个开发人员的需求。

框架设计的基本原则：

对用户而言，真正的开发效率来自能够轻易地创造非凡的产品，而并非来自能够轻易地创造垃圾。

1. 场景驱动设计原则
2. 低门栏原则
3. 自说明对象原则
4. 分层架构原则

《.NET设计规范》——学习笔记（2.4）分层架构原则

分层设计使得在单个框架中同时提供强大的功能和易用性成为可能。

• 考虑对框架进行分层，使高层API能提供最佳的开发效率，低层API能提供最强大的功能和最丰富的表现力。
  通俗地讲，象我这样的菜鸟只能用高层API，太低层都不懂，而牛人们都是想用也更愿意用低层API的强大功能的（个人意见）。ps：这边的高层跟低层不是指高深的意思。而是从易用性方面考虑的！
• 避免把低层API和高层API混在同一名字空间中，如果低层API非常复杂的话（即包含了许多类型）。
• 要确保单个特性域中不同的层能很好的集成在一起。

《.NET设计规范》——学习笔记（2.3）自说明对象原则

在简单的使用场景中，一定要让框架无需文档就能使用。

• 要确保API是直观的，无需查阅参考文档就能用于基本场景
  你总不希望写个“Hello World”都去查阅API文档吧。
• 要为所有的API提供优秀的文档。
  一方面，并非所有的API都能自说明。不同的人会认为不同的API是自说明的；
  另一方面，有些人想在开始使用API之前完全理解它们。

设计自说明API时最重要的一些考虑因素：

1. 命名
   要在规范检查中重视标识符名称的选择；
   不要担心标识符的名字太冗长；
          一眼就能看出相应的方法是做什么的，类型和参数是表示什么意思。
          而且类型的名字如果足够好，那么用到这些类型的代码会更易于立即和维护。
   要在设计过程的初期就让用户教育专家参与；
   考虑把最好的名字留给最常用的类型。
2. 异常
   要通过异常消息来清楚地告诉开发人员对框架的误用。
3. 强类型
   很明显，调用Customer.Name要比调用Customer.Properties["Name"]容易。
   要尽可能提供强类型API。
          如果必须使用属性包，那么应该为包中最常用的属性提供相应的强类型属性。
4. 一致性
   要确保与.NET框架以及客户可能会使用的其他框架保持一致。
5. 限制抽象的数量
   标准面向对象设计方法会产生大量抽象。其目的是使代码易于维护。然而如果框架中存在太多的抽象，则会要求用户对框架的架构有深入的了解，不易于用户使用。
   避免在主要场景的API中使用太多的抽象。

做礼拜

又是一周过去了，星期一又来了！早上，在公司里偷个空，写点东东：

昨天是星期日：基督徒做礼拜的日子！

自从呆子去年去了英国，也有一年多没见到她了。昨天我们越好见面的，还有冲哥和晓丹！昨天也是她要做礼拜的日子：她在英国受洗了！我以前也从来没有见识过基督教做礼拜的场景，所以跟呆子说，也想看看。我到富阳的时候他们的仪式已经开始了，我到的时候，上面是长老在做报告类似的，因为讲得是富阳话，我不大听得懂；不过这个很快也就结束了（大概是在我来之前已经讲了很久了:-P）。然后，他们就开始唱圣歌，唱了很多，我个人感觉那个旋律还不错，也很容易上口，也跟着唱了几首。圣歌中都是些赞颂耶稣，赞颂主的，也有一些是说希望主不要摒弃他们的，还有就是希望主收留他们。呆子，一直都在非常虔诚的唱，而且每次低头祷告的时候都非常虔诚（我作为外人，自然体会不到其中的滋味）。唱完圣歌，过后是讲了一段圣经上的内容，我们四个人，除了呆子，其他的都没有认真的在听，所以也不知道具体地讲了些什么。不过我听到一个故事印象非常深刻：有一对夫妻，妻子是基督徒。故事就讲到那个丈夫，如果打他妻子，她绝对不会还手，而且还是笑脸相迎！ 这个也许就是常说的那个故事：如果有人打你左脸，你要把右脸让他打！这个礼拜好像还有圣餐，不过呆子说我们没有受洗过，不能接受的！

后来，也跟呆子聊了很多。也大致了解了基督教的一些东西。她也说她自己变了很多，在英国最重要的事就是找到了自己的主。在我看来她在英国最重要的的确是找到了自己的主，找到了自己一生的寄托。

我从来不会觉得因为有宗教信仰，呆子就是另类了。在我看来呆子还是呆子，唯独变的只是她找到了一个可以倾诉的对象！

《.NET设计规范》——学习笔记（2.2）低门栏原则

框架必须以易于使用的方式来为普通用户提供一个低门栏。

每个人在第一次接触一个新框架时，都希望其是简单而功能强大的。如果他一开始就感觉其很复杂，则会望而却步。

• 要确保每个特性域的名字空间只包含哪些用于最常见场景的类型。应该把用于更高级的场景的类型放在子名字空间中。
  例如：System.Net命名空间提供了有关网络的主要API，而更高级的socket API则位于System.Net.Socket子命名空间。
• 要为构造函数和方法提供简单的重载函数。参数少，且都是基本类型。
• 不要在为主要的使用场景而设计类型中包含用于高级场景（这里我个人感觉是不常用的意思）的方法。
  通过从框架中减少（或至少不增加）特性，能够使开发人员更有效率。因为需要处理的概念减少了。CLR把多重继承排除在外就是这个原因。
• 不要要求用户在最基本的场景中显示地实例化一个以上的类型。
• 不要要求用户在为基本使用场景编写代码之前就进行大量的初始化。
  如果一些初始化是必需的，那么当用户未执行初始化而引起异常时，应该在异常消息中清楚的告诉用户需要做些什么。
• 要尽可能地（用便利的重载函数）为所有的属性和参数提供合适的默认值。
  当然不要盲目采用，如果默认值会引起错误，自然不可取。
• 要通过异常来传达API的误用。
  显示错误的原因、如何修正等信息。