大规模视频网站的计费与流量管理
本次分享将会就大规模视频网站的计费与流量管理这个话题，从操作层面细细进行讲解和分析，为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”，让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
Qi4j提出面向组合编程思想
作者 Rob Thornton 译者 王军 发布于 2007年11月20日
本周Rickard Oberg在oredev上宣布推出Qi4j，并宣称“类已死，接口万岁”。Qi4j带来了面向组合编程的新思想，提出类中不再放有任何的行为，取而代之的是，类成为混入（mixins）的‘组合’，并在类中使用标注定义接口。
Qi4j本身是一个提供给所有java开发者使用的面向组合编程的Java框架。尽管面向组合编程需要较大的思想转变，但是面向组合编程不需要单独的工具、语言或XML。Qi4j的应用程序可以在Spring应用软件、Web应用容器、OSGi和其他地方运行。Qi4j大量使用了标注，以此摆脱框架特定的知识，让开发者更关注业务规则。项目创始人Rickard Öberg和Niclas Hedhman在新闻稿中这样描述：
Niclas Hedhman说：“Qi4j是一个以领域为中心的应用开发框架，融入了从面向方面编程、依赖注入和领域驱动设计演化而来的思想，利用了Java 5平台和其生态系统”。Niclas Hedhman是长期从事于Java框架的开发者，并且现在是Apache的活跃成员。
Rickard Öberg说：“我需要一个能使领域模型和业务规则再度成为关注焦点、让领域专家和开发者能够清晰沟通的系统” 。Rickard Öberg是以前JBoss、Webwork和XDoclet的创始人。
由于这仅仅只是框架和范型最初的展示，文档和例子还比较少。但是，面向组合编程的目标是完成从对象思考到组合思考的转变。组合由可复用的片段（fragments）组成。片段是Qi4j的组成块 。片段携带组合成员的状态（在mixins（混入）中）、验证和约束它们的使用（在约束（constraints）中）、处理横切点（在关注点（concerns）中）、并提供通知、缓存和撤销管理，以及其他异步需求（在副作用中）。编程范型的转变并不是件容易的事情。Oberg这样描述对面向组合编程的反应：
人们一贯有两种反应：一是试图从脑海中扫除源于旧有经验的坏主意而头疼欲裂，一是理解我们所提思想的潜力而发出心领神会的微笑。
Qi4j仍在更新，并且不稳定。此时，他们仍在致力于稳定框架，同时将面向组合编程思想推介给社区,希望借此获得继续发展。他们也承认目前还没有充分准备好让大家深入到这个框架中，并建议大家在未来数个月中先侧重于概念理解。
查看英文原文：Qi4j introduces Composite Oriented Programming译者简介：王军，长期从事软件开发工作，实际项目偏重于JBOSS平台上构建网管软件。对于性能测试工具有较多的关注，关心软件技术和相关工具的动态，将其中相对成熟的技术和工具应用到实际的项目之中。长期担任技术管理和项目管理工作，一直关心开源软件的发展动态以及软件过程和敏捷开发的实践探索。参与InfoQ中文站内容建设，请邮件至china-editorial@infoq.com。
呵呵
发表人
Lai Mead
发表于
Oberg闭关多年，再次出手，值得关注
发表人
刘江 图灵
发表于
I dont think so
发表人
huang splash
发表于
Re: I dont think so
发表人
Ming Jin
发表于
Re: I dont think so
发表人
田 乐
发表于
Re: I dont think so
发表人
huang splash
发表于
谨慎怀疑
发表人
曾 帅
发表于
语义生涩的抽象难有前景：可以有更易理解的编程思想
发表人
Wang Jason
发表于
-
思想挺新的，理解有点困难
-
好像是在AOP上更进一步？
-
我认为"类已死，接口万岁"是片面的。
在我看来，类的设计——继承，多态是纵向思维模式。
接口设计——组合、责任链、command是横向思维模式是模块解耦过程。往往大家都比较关注解耦的设计，成功的解耦模块系统确实为我们建立一套可快速变换的系统。
但一个系统应该有纵向和横向的考虑。继承、多态的设计是对系统概念的高度抽象，提炼本质的过程。良好的继承多态的设计是对事物本质的描述，是不变的、深远的一种思想表现。只有把握了本质才能把所有"变化"玩弄在掌股之中。当然这是很难办到的。
另一方面，接口设计是一种责任体验、一种划分过程，责任明确划分得当系统是健壮的，可快速变化的虽然缺少深层考虑但非常符合我们平时分而治之的思维。但如果系统从本质上就出现缺陷，我觉得无论如何组合都无法得已解决，起码对于我来说是这样的。
所以我认为类设计，接口的设计应该两手抓。 -
接口偏向于动态的设计
类则偏向于静态的设计
觉得现在对动态的过分强调，忽视了亘古不变的静态东西 -
说的不是一回事嘛。接口不过是为了解决多继承带来的弊端而产生的面相契约编程的东西。但是这个掩盖不了Java在继承行为而不是语义的能力上的弱势。所以O（还有两个点）berg大师说的是用mixin重新修改非常受限制的单根继承和接口的方式，这种扩展的确是划时代的。
Bruce Tate的Beyond Java里面就提到过这样的限制，没想到还是Oberg弄出来了。不过这样不如去用其它直接支持mixin的语言了？ -
To 乐 田:
希望我没有对本文没理解错,要不然就太糗了。接口在编程语言角度来说是一种解决多继承的办法。但我想本文所说的不是针对编程语言而言，而是采用组合编程的思想对系统建模的思路和方法。"提出类中不再放有任何的行为，取而代之的是，类成为混入（mixins）的'组合'..."。
接口，脱离编程语言方面的考虑，比如说，一家做MP3的公司有两类人员：开发人员和客服人员。客服人员是对外的窗口（接口）责任是沟通和明确与客户的关系，开发人员就是做内部研发工作，其中分为总工、高工、工程师、助理等等个个都要干活的，可能级别不一样，干的活就不一样。不知这样比喻合适不？
本文的意思似乎强调行为建模，而废弃结构建模。所以我觉得"类已死，接口万岁"这句太离谱。 -
我觉得类和接口相辅相成的
-
我以为面向组合这个概念本身就生涩，对象是什么：很好理解，组合是什么：很不好理解。
我倒是觉得，在现有的面向对象思想的基础上，引入对象的“状态”和“事件驱动”的思想可以进一步简化和规范我们的编程工作:
“状态”，一个对象在任何时候都处于某种状态，而状态的具体表现形式可以是对象的各种属性的当前值；
“事件”，事件是对象状态变化的驱动因素，一个对象在某种状态下发生某种事件，经过一系列动作（对事件的反应）而使对象的状态发生变化。
“动作”，对象本身可以执行的一些操作。
引入这样一些概念，我们可以设想编程将变成一个按步就班的过程：
1）在原面向对象的思想指导下，定义类以及类的各种基本属性；
2）定义类的状态集；
3）定义类可以接收的事件集；
4）定义每种状态下每种事件发生时的反应过程
当然这只是形成了一种编程的大致框架，还需要更细致的一些定义，我先抛一块砖吧。
8 条回复
关注此讨论 回复