Through the Looking Glass

原创 2001年09月28日 12:06:00

因本人能力有限,无法翻译出其原汁原味来,所以就没有翻译了。望大家见谅:)

Through the Looking Glass

 

 

July 2001 <!--Date Default Font Bold -->

<!-- ENTER DECK HERE Arial Size: +1 Color: 666666 -->Subtle signs point to a marked transformation, a disruptive technology on the horizon.

<!--Author Default Font Italic -->by Grady Booch

<!-- IMPORT ARTICLE TEXT HERE -->Visualize, for a moment, the most recent application you've developed. Focus on an interesting code fragment, a particularly elegant script or method, or something in the main line of a primary use case realization. Imagine seeing that code, just as you created it, in your IDE or editor. Now, pop up one level of abstraction and consider the neighboring classes that provide the context for your code along with the instances of those classes that collaborate as your code runs. Line by line, walk through your code and imagine how its execution progresses, touching and manipulating the state of each instance. Finally, pop down one level of abstraction and visualize your compiler's mapping of that code to the raw instructions that ultimately direct your system's underlying hardware.

The existence of this one-to-one mapping of code (as seen in your IDE) to execution (on your target hardware) is a primary conceptual model that millions of programmers have in their heads every day as they code. It's also a primary model that generations of programmers over the past several decades have used. All in all, this von Neumann model of the world is wonderfully simple yet powerful, for it helps us build complex systems that are ultimately grounded in useful, executable artifacts.

It's also a complete illusion.

Galaxies of Abstractions
As I've said in my earlier writings, the task of the software development team is to create an illusion of simplicity. We build abstractions to help us create this illusion; these abstractions are an essential way we mitigate the intellectual complexity that lurks within our systems. Indeed, the entire history of software engineering can be traced by studying the manner in which our programming languages and methods have tried to raise the level of abstraction in our systems. That's why structured programming was effective in its time—those methods provided guidance in helping us manage the complexity of algorithmic decomposition. That's also why the object-oriented movement has been effective in its time—these methods help us organize our systems around societies of collaborating objects.

Visualize again the system architecture you considered earlier. If it's non-trivial, you'll see a universe of classes, some clumped closely together, some more distant, depending upon their degree of semantic relation. If you've used patterns to direct your design, you'll see common structures and behaviors that cut across these galaxies of abstractions.

Yet, at runtime, all of this beautiful structure evaporates. We raise our systems from the ground up, place a scaffolding of abstractions around them as they grow—and tear down that scaffolding once we're done. We might keep some scaffolding around or we could simply make it easy to reassemble if we need to extend, repair or preserve the system we've built. Ultimately, however, all of these abstractions are irrelevant to the system itself once it's in use.

Three Subtle Signs
There came a time when I'd reached "nerdvana," that state in which I was able to peer beneath the covers of the programming universe and witness the brilliant simplicity of its underlying machinery. The first time I really grasped the wonderful power of object-oriented abstractions, I thought I'd seen the ultimate model on which all kinds of complex systems could be grown. I also thought I'd encountered the most elemental structures of development—similar to the physicist's elemental model of protons, electrons and neutrons that described phenomena at the atomic level.

However, I was wrong: There's something deeper, something that's truly beyond objects.

Admittedly, this isn't a concept that's easy to explain, because I'm still so steeped in an object-oriented view of the world. However, just as a sailor can sense a changing sea, I note subtle signs that point to a marked transformation, a disruptive technology, on the horizon.

From where I stand, I see three such signs.

First, there's the patterns movement. (The seminal work in patterns is Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides [the Gang of Four], published by Addison-Wesley in 1995, which has been followed by a veritable flood of pattern books over the past several years.) At the time—and I still believe it—I declared patterns to be the one really refreshing idea since objects entered the scene. Object-oriented abstractions are great, but patterns are something subtly different, something from a truly alternative dimension of programming reality. Although classes help us organize our systems, patterns help us organize our classes, giving us guidance in extracting and exploiting common structures and behaviors. Whereas the mapping of classes to executables is only a modest conceptual leap, the mapping of patterns to classes and then to executables is a bit deeper, but well worth the effort for the complexity-management capacity that they provide. Patterns are indeed a sign of a break from the traditional von Neumann model of computation, because they name things that are somewhat orthogonal to the basic mappings of code to executables we have in our heads.

Second, there's the growing understanding of the importance of multiple views in the science and practice of software architecture. In "The 4+1 View Model of Software Architecture" (IEEE Software, Nov. 1995), Philippe Kruchten observes that there is no single, elementary view of a system sufficient to describe its architecture; rather, different stakeholders best view a complex system from different perspectives. Kruchten goes on to suggest a set of necessary and potentially sufficient views (using his more recent terminology, the design, process, implementation, deployment and use case views) that individually represent a point of entry for different sets of stakeholders and which collectively form the executable system. Perhaps Kruchten's most interesting observation is that it is reasonable—indeed, almost necessary—to grow a system by advancing each view somewhat simultaneously. As in any engineering endeavor, that process will reveal tensions among the competing interests of each stakeholder, but in turn offers a mechanism whereby progress can be made in resolving those tensions to yield a quality system.

Third, there's the emerging area of aspect-oriented programming (AOP). According to the aspect-oriented programming homepage hosted by the Xerox PARC Software Design Area (www.parc.xerox.com/csl/projects/aop/), AOP is "a new programming methodology that enables the modularization of crosscutting concerns. Experience has shown that in using standard procedural or object-oriented programming languages it can be difficult to modularize." AOP is subtly different than OOP, but it appears to complement—not replace—traditional OOP. AOP, in a manner similar to classic patterns and Kruchten's architectural views, recognizes that there are abstractions on a plane different than object-oriented abstractions, which in turn are on a plane different than our executable systems. Some of the seminal AOP papers include "Aspect Oriented Programming: A Position Paper from the Xerox PARC Aspect Oriented Program Project" (Xerox PARC, 1996), by Gregor Kiczales and others, and "Aspect Oriented Programming" (ECOOP 97 [European Conference for Object-Oriented Programming 1997]), by Gregor Kiczales, John Lamping, Anurag Medbeker, Chris Maeda, Cristina Videira Lopes, Jean-Marc Loingtier and John Irving. (See the sidebar, "What Is Aspect-Oriented Programming?" for more information.)

It's a Bird, It's a Plane, It's …
Collectively, Gregor Kiczales (formerly with Xerox PARC), John Vlissides (who works for IBM), Charles Simonyi (who works for Microsoft) and I've named this coming sea change "multifaceted software" because it represents a means of attacking development's complexity by approaching it from multiple fronts.

We aren't alone in identifying this coming change. For example, IBM Research has been working on a concept called Hyperspaces that addresses building systems through what they call multidimensional separation of concerns (see www.research.ibm.com/hyperspace/). The UML community's work to bring deeper executable semantics to the language pushes the world subtly in this direction, as well.

As software practice advances, we reach out to solve problems of increasing complexity. Most of the time, our methods fall short of our reach, but as experience grows, we can codify best practices to construct a higher, stable platform from which we can reach even higher. Structured programming represented one such platform; object-oriented technology represents yet another; and multifaceted software may be our next launchpad.

What is Aspect-Oriented Programming?
The latest methodology supports a new unit of software modularity that crosscuts traditional boundaries.

From their earliest days, programming languages have stressed various units of modularity, including subroutines, functions, procedures, modules and objects. Aspect-oriented programming (AOP) is the latest methodology to support a new unit of software modularity: aspects. Aspects are elements such as security policies and synchronization, optimization, communication or integrity rules that crosscut traditional module boundaries. At design time, a typical AOP scenario separates aspects from the classes and methods that make up application components. A code weaver (either an interpreter, compiler or pre-processor) then produces the extended classes in which aspect functionality intertwines with application components in a specific target programming language.

AspectJ from Xerox PARC is an aspect-oriented extension to the Java programming language that enables the modularization or separation of Java concerns related to error checking, design patterns, resource sharing and distribution policies. As documentation at www.aspectj.org points out, AspectJ allows Java developers to apply the "Design by Contract" style of programming popularized by the Eiffel language (www.eiffel.com) and implement pre- and postcondition testing in modular form. For example, the following code implements the bounds-checking aspect of precondition testing for point-moving operations:

aspect PointBoundsChecking {
  pointcut setXs(int x):
        calls(void FigureElement.setXY(x, int)) ||
        calls(void Point.setX(x));
pointcut setYs(int y): ...;
before(int x): setXs(x) {
    if ( x < MIN_X || x > MAX_X ) )
      throw new IllegalArgumentException ("x is out of bounds.");
  }
before(int y): setYs(y) {
    ...
  }   
}

Similar to AspectJ, the AspectR project adds aspect-oriented programming concepts to Ruby, an open source, object-oriented scripting language from Japan that is used like Perl to process text files and to do system management tasks. As is the case with many or most programming topics, the Wiki Wiki Web is a good place to start your AOP research: www.c2.com/cgi/wiki?AspectOrientedProgramming.

—Roger Smith

Through The Looking Glass (Episode 119)

The Taelons introduced interdimensional travel for human customers. Jamie Si...
  • nethermit
  • nethermit
  • 2007年01月05日 13:38
  • 553

传统数据库没落,OLTP新型数据库发展火热

OLTP关系型数据库Transaction的吞吐量比传统数据库提高了至少20倍。 数据库系统的近期发展和分类 随着操作系统发展趋于稳定(不包括移动端OS),越来越的的研究集中在数据库系统的发展上,没...
  • jxchinaren
  • jxchinaren
  • 2014年08月05日 13:36
  • 5554

Win10实现窗口AeroGlass化

一直以来,我觉得Win8的优化设计做的非常好,唯一美中不足的是将原有的Aero效果去掉了,并且以一种非常简单粗暴的方式去掉了,毫无美感。庆幸的是,Win10中虽然没有恢复窗口Aero效果,但它的扁平化...
  • u013005687
  • u013005687
  • 2015年09月16日 01:06
  • 1433

安装Glass Box代理程序

安装玻璃盒代理程序 目前版本的玻璃代理程序主要支持主流 Java EE 应用程序服务器(如 JBoss,Tomcat,WebLogic 和 WebSphere)。玻璃盒代理程序可以自动化安装,但考...
  • KerryRuan
  • KerryRuan
  • 2016年03月23日 16:09
  • 1115

【Google Glass开发平台】谷歌眼镜开发工具包(GDK)快速...

在您开始使用谷歌眼镜开发工具包(GDK)之前,你需要对安卓开发有中等或者更深入的理解和认识。 这个快速入门教程将教你如何把GDK安装在你的系统环境上,以及教会你安装你的第一个谷歌眼镜应用。关于开...
  • yuzhongchun
  • yuzhongchun
  • 2014年04月21日 14:40
  • 4975

Google Glass不属于VR/AR团队,谷歌已确认

谷歌确认:Google Glass不属于Google VR/AR团队,也没有任何合作。
  • ARINCHINA
  • ARINCHINA
  • 2017年05月23日 10:03
  • 908

Shader 学习笔记 ---Looking Through a Filter 过滤器

    Expanding a dot product operation to its final equation    简单的点积计算颜色混合         Decomposition of ...
  • xmujojo
  • xmujojo
  • 2009年01月15日 16:37
  • 253

Google Glass开发初步体验

一、开发环境 操作系统:Windows7(64位) 开发工具:Android Studio 2.0 Android SDK:Glass Development Kit Preview(API Leve...
  • roadoneplus
  • roadoneplus
  • 2017年01月10日 17:02
  • 769

关于AppScan GlassBox的两篇文章

关于AppScan GlassBox的两篇文章:http://www.ibm.com/developerworks/cn/rational/r-cn-appscannewglassbox/http:/...
  • Testing_is_believing
  • Testing_is_believing
  • 2014年03月15日 00:03
  • 3252

Looking up through Array in Actionscript 3.0

TASK DESCRIPTION: I have a Company class, holding some data of a company, such as English name,...
  • zlxadhkust
  • zlxadhkust
  • 2011年10月05日 18:05
  • 260
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Through the Looking Glass
举报原因:
原因补充:

(最多只允许输入30个字)