翻译文献Chapter 2. Architecture.docVIP

大连交通大学2016届本科生毕业设计（论文）外文翻译  PAGE - 12 - 外文原文 Chapter 2. Architecture In theory there is no difference between theory and practice. But, in practice, there is. —Jan L.A. van de Snepscheut Architecture—its that level above design where we get our first glimpse of what the system will ultimately resemble, how it will be built, the vision of the application and system as a whole. By keeping the advice contained in the items that follow in mind when laying out the basic flow and design of your enterprise applications and systems, youll make progress toward a noble goal: establishing an architecture that enables a high-performance, high-scalability enterprise system. Item 1: Prefer components as the key element of development, deployment, and reuse One of the difficulties many Java developers face when attempting their first J2EE-based project is that J2EE applications are built differently than traditional Java applications: rather than building applications, J2EE mandates the construction of components that plug in to an already-existing application, that being the J2EE container itself. This may not seem like a large difference at first, but its implications are huge, in two different directions. First of all, this means that developers arent really interested in constructing objects per se but in creating strongly encapsulated components that (in the case of J2EE) are made up of tightly coupled constituent objects. Second, it means that there are a set of stringent rules that must be obeyed over which we, as the component builder, have little to no influence. Developers studying the object-oriented paradigm have, since the very early days, been repeatedly taught to promote encapsulation and data hiding. Weve all memorized nuggets of wisdom handed down from on high, such as Never use public fields; instead always create accessor and mutator methods (getters and setters, in JavaBeans lingo), for example, or Hide your implementation from client view, and so on. As a r