一区二区三区中文字幕精品精品,高清免费观看在线,懂色aⅴ精品一区二区三区蜜月

Tue, 30 May 2006 02:46:00 GMT

The history of software development is a history of raising the level of abstraction. Our industry used to build systems by soldering wires together to form hard-wired programs. Machine code let us store programs by manipulating switches to enter each instruction. Data was stored on drums whose rotation time had to be taken into account so that the head would be able to read the next instruction at exactly the right time. Later, assemblers took on the tedious task of generating sequences of ones and zeroes from a set of mnemonics designed for each hardware platform.

软�g开发的历史是抽象层�ơ不断提高的历史�Q�我们的工业以前是通过��电(sh��)路焊接在一起以形成��g�l�成的程序，�q�样来进行系�l�的搭徏。机器码使得我们可以通过操作开��x��输入每条指��o(h��)�Q�数据保持在×××××。。。，后来�Q�汇�~�程序通过为每�U�硬件��^台定义相应助记符的�Ş式，帮我们把�q�种�J�琐�?/1操作中解攑և�来�?br />
At some point, programming languages, such as FORTRAN, were born and "formula translation" became a reality. Standards for COBOL and C enabled portability among hardware platforms, and the profession developed techniques for structuring programs so that they were easier to write, understand, and maintain. We now have languages like Smalltalk, C++, Eiffel, and Java, each with the notion of object-orientation, an approach for structuring data and behavior together into classes and objects.
��C��后来�Q�编�E�语�a�诸如FORTRAN的出玎ͼ�使得“公式翻译”成为现实，COBOL和C标准使得不同��g�q�_��之间的移植成为可能，后来发展��Z��l�构化的�E�序设计方式�Q��得编�E�语�a�更容易编写、理解和�l�护。我们现在拥有像smalltalk、C++、Eiffel和Java�Q�它们运用了面向对象技术，一�U�把数据和行为封装到�c�d��对象的方法�?/p>

As we moved from one language to another, generally we increased the level of abstraction at which the developer operates, which required the developer to learn a new, higher-level language that could then be mapped into lower-level ones, from C++ to C to assembly code to machine code and the hardware. At first, each higher layer of abstraction was introduced only as a concept. The first assembly languages were no doubt invented without the benefit of an (automated) assembler to turn mnemonics into bits, and developers were grouping functions together with the data they encapsulated long before there was any automatic enforcement of the concept. Similarly, the concepts of structured programming were taught before there were structured programming languages in widespread industrial use (for instance, Pascal).

当我们从一�U�语�a�发展到另一�U�语�a�的时候，通常我们提高了开发者进行开发所处的抽象层次�Q�这需要开发者学�?f��n)新的、更高层�ơ的能够映射��C��层次的语�a��Q�如C++到C到汇�~�代码到机器码和��g。最初，每一个更高层�ơ的抽象只是作�ؓ(f��)一个概念被引入。最初的汇编语言被发明的时候，作�ؓ(f��)把助记符转换到字节码的汇�~�器�q�没有体�p�d��什么明昄��又是。。。。，�c�M��的，�l�构化程序设计的概念也显得很不�ؓ(f��)人接受直到结构化�~�程语言在工业界�q��ؓ(f��)使用�?br />
Over time, however, the new layers of abstraction became formalized, and tools such as assemblers, preprocessors, and compilers were constructed to support the concepts. This had the effect of hiding the details of the lower layers so that only a few experts (compiler writers, for example) needed to concern themselves with the details of how those layers work. In turn, this raises concerns about the loss of control induced by, for example, eliminating the GOTO statement or writing in a high-level language at a distance from the "real machine." Indeed, sometimes the next level of abstraction has been too big a reach for the profession as a whole, only of interest to academics and purists, and the concepts did not take a large enough mindshare to survive. (ALGOL-68 springs to mind. So does Eiffel, but it has too many living supporters to be a safe choice of example.)

随着旉��的过去，然而，新的抽象层次也开始正式�Ş成，相应的工具如汇编器、预处理器和�~�译器开始出��C��支持�q�些概念。它们把低抽象层�ơ的�l�节隐藏�Q��得只有少数的专家�Q�如�~�译器的�~�写者）需要关心这些细节如何工作。。。。�?br />
As the profession has raised the level of abstraction at which developers work, we have developed tools to map from one layer to the next automatically. Developers now write in a high-level language that can be mapped to a lower-level language automatically, instead of writing in the lower-level language that can be mapped to assembly language, just as our predecessors wrote in assembly language and had that translated automatically into machine language.

随着开发者开发的抽象层次的提高，我们开发出从一个层�ơ自动映��到另一个层�ơ的工具。开发者现在只需�~�写高层�ơ的�~�程语言�Q�之后的转换��是自动�q�行的�?br />
Clearly, this forms a pattern: We formalize our knowledge of an application in as high a level a language as we can. Over time, we learn how to use this language and apply a set of conventions for its use. These conventions become formalized and a higher-level language is born that is mapped automatically into the lower-level language. In turn, this next-higher-level language is perceived as low level, and we develop a set of conventions for its use. These newer conventions are then formalized and mapped into the next level down, and so forth.

昄��Q�这形成了一�U�模式：(x��)我们不断地提高抽象的层次的概念，随着旉��的过去，我们学会(x��)了如何��用这�U�语�a�以及(qi��ng)应用一�p�d��的��用约束。这些约束变成正式后一�U�新的语�a�诞生了，而这�U�下一代的语言是从低层�ơ被感知的，当我们定义一�p�d��的��用约束之后，�q�些新的�U�束又被正式化，来推动下一阶段的发展。不断地循环�?br />
The next level of abstraction is the move, shown in Figure 1-1, to model-based development, in which we build software-platform-independent models.
下一阶段的抽象层�ơ在发展�Q�如图所�C�。它是基于模型的开发，在这里我们徏立的是和软�g�q�_��无关的模型�?br />

Figure 1-1. Raising the level of abstraction

Software-platform independence is analogous to hardware-platform independence. A hardware-platform-independent language, such as C or Java, enables the writing of a specification that can execute on a variety of hardware platforms with no change. Similarly, a software-platform-independent language enables the writing of a specification that can execute on a variety of software platforms, or software architecture designs, with no change. So, a software-platform-independent specification could be mapped to a multiprocessor/multitasking CORBA environment, or a client-server relational database environment, with no change to the model.
软�g�q�_��无关是和��g�q�_��无关�c�M��的概��c(di��n)��一个硬件��^台无关的语言�Q�如C或者Java�Q�可以��得一个规范的�~�写能够在不同的��g�q�_��上运行而不需要更攏V��类似地�Q�一个��Y件��^台无关的语言可以使得一个规范的�~�写可以在不同的软�g�q�_��上运行，或者在不同的��Y件架构中�q�行�Q�而不需要更攏V��因此，一个��Y件��^台无关的规范可以映射到多处理�?多�Q务CORBA环境�Q�或者一个C-S关系数据库环境，而不需要更�Ҏ(gu��)��型�?br />

In general, the organization of the data and processing implied by a conceptual model may not be the same as the organization of the data and processing in implementation. If we consider two concepts, those of "customer" and "account," modeling them as classes using the UML suggests that the software solution should be expressed in terms of software classes named Customer and Account. However, there are many possible software designs that can meet these requirements, many of which are not even object-oriented. Between concept and implementation, an attribute may become a reference; a class may be divided into sets of object instances according to some sorting criteria; classes may be merged or split; statecharts may be flattened, merged, or separated; and so on. A modeling language that enables such mappings is software-platform independent.
�ȝ��而言�Q�由概念模型所驱动的数据的�l�成和处理也许和实际的数据组成和处理不完全相同。如果我们考虑两个概念�Q�比如“customer”和“Account”，��他们徏模程UML的类图以期望能够被用�?/p>

�?/a> 2006-05-30 10:46 发表评论

the Single Choice Principle

Sun, 21 May 2006 03:55:00 GMT

一直不是很理解单点选择�Q�今天找��C��一点关于它的资料：(x��)

The Single Choice principle:
whenever a software system must support a set of variants, clients using objects from this set should not have knowledge of all the elements in the set. A violation of this principle can be illustrated with the variants of Pascal or the unions of C (as long as the union is placed inside a struct and there is a field that acts as a type descriptor). Code written that acts upon one of these “multiple personality entities�? must be queried for its actual type, and we must program accordingly. This will produce multiple selection constructs in any module that uses these variant types.

Such constructs will become a hindrance to software change and evolution. Any addition of a new type to the variant set will force modifications in all modules that have to query the type to act accordingly. This multiple choices spread around many modules of a system is exactly the opposite to the single choice principle.

Traditional languages and paradigms do not provide a solution. On the other hand, object orientation, via polymorphism and dynamic binding present an elegant and complete implementation of this principle.

This concludes our consideration of the properties necessary for good modular structures. It will be seen that Abstract Data Types provide an adequate specification for modules that are consistent with the properties developed in this section. Eventually, we will cross the bridge into the software world and introduce the class as a potentially partial implementation of an Abstract Data Type.

�?/a> 2006-05-21 11:55 发表评论

the Joy of Pattern ��M��W�记

Sat, 20 May 2006 09:48:00 GMT

著名建筑大师Alexander�Ҏ(gu��)��式的定义是：(x��)模式�Q�简单而言�Q�是出现在世界上的一个事物以�?qi��ng)对应的规则�Q�这�U�规则告诉我们如何去建立该事物，什么时候应该徏立该事物。它是一个过�E�，也是一件事物，是对一个事物的描述以及(qi��ng)对一个��生该事物的过�E�的描述。就是说�Q�模式是一�U�规则之余，它还是一�U�现象、现状和事物�?br />
�W�二�?an Introduction to Patterns
一开始通过一个例子引入Observer Pattern�Q�在�q�本书中�Q�对模式的描�q�是用以下格式来�q�行的：(x��)

Observer

在第三章�Q�介�l�了OO相关技术包括UML�Q�其中提��C��一个概念：(x��)在一个��承体�p�M��Q�良好的做法是越往上放��多的Code�Q�而Data则放到越下层�Q�子�c�or实现�c�）��好。文章是�q�样解释的：(x��)��公�׃��码尽可能地放到��承层�ơ的上方�q�样它可以被重用�Q�和数据不同�Q�在�l�承的过�E�中�Q�当子类实例不需要��用的时候，代码也不�?x��)有额外的cost�Q�，而数据元素则应该攑ֈ��低��好�Q�这样你不会(x��)��Z��需使用的数据成员付��Z��仗��如下图�Q?br />

�W�四章讲的是一个电(sh��)脑公司的销售系�l�，寚w��件的零售和各�U�搭配销售，要求�pȝ��能够�l�一对待�Q�这里引入了Composite模式�Q�这里不详述�Q�因��是比较简单的�?br />
�W�五章讲的是Decorator模式�Q�首先引入了一个汉堡店的系�l�，介绍了组合爆炸的设计�Q��ƈ引入Decorator�Q�解决了�q�种问题�?br />
�W�六章讲的是不同�~�程语言�Ҏ(gu��)��式的实现问题�Q�设计模式和�?f��n)惯用法�Q�idiom�Q�比较�v来，后者是与特定语�a�相关的，而设计模式则是与语言无关的，�q�指的是支持OO的语�a�都支持设计模式，只不�q�实现�v来的复杂�E�度各有不同�Q�文章�D了一个例子用VB来实现State模式�Q�再用Java来实玎ͼ�得出上述�l�论�?br />
�W�七章第八章我就没详�l�看了，一是觉得这里的囄��的不是标准UML图，看�v来不太顺��|��另一个则是内容似乎没什么特别的。书的最后三分之一都是附录�Q�代码�?br />
�ȝ��而言�Q�这本书不算一本经典的书，�׃��在图书馆借的�Q�在�q�书之前��M��一下。下�ơ打��看的模式书是《Head First Design Pattern》。不�q�得�{�辩之后才有旉��了�?/p>

�?/a> 2006-05-20 17:48 发表评论

Mon, 24 Apr 2006 08:37:00 GMT

Operation中文译作操作�Q�是指类所定义的行为的声明部分�Q�一般是名称、参数和�q�回�c�d��。通常也叫对象的接口（Interface�Q�，该信息用于告诉对象需要它做什么�?br />Method译�ؓ(f��)�Ҏ(gu��)��Q�是指上诉操作的实施�Q�即当调用接口时被执行的代码�?br />两者的区别�Q�简单地来说�Q�一个是声明�Q�一个是实现。不澄清的话很容易�؜淆�?img src ="http://www.aygfsteel.com/shawn/aggbug/42847.html" width = "1" height = "1" />

�?/a> 2006-04-24 16:37 发表评论

一区二区三区中文字幕精品精品,高清免费观看在线,懂色aⅴ精品一区二区三区蜜月

Figure 1-1. Raising the level of abstraction

the Single Choice Principle

the Joy of Pattern ��M���W�记

the Joy of Pattern ��M��W�记