寫給大家看的面向對象編程書(第3版)
Bear在這裡買的
amazon的參考
-----------------------------------------------------------
作者：(美)韋森菲爾德|譯者:張雷生//劉曉兵
出版社：人民郵電
ISBN：9787115197764
出版日期：2009/05/01
頁數：266
人民幣：RMB 45 元
-----------------------------------------------------------
P.9
要解釋類和方法，舉一個關系數據庫的例子會很有幫助。在一個數據庫表中，表自身的定義(定段、描述和所用的數據類型)就是一個類(元數據)，對象則是表中的行(數據)。
原文.P.15
To explain classes and methods, it’s helpful to use an example from the relational database world. In a database table, the definition of the table itself (fields, description, and data types used) would be a class (metadata), and the objects would be the rows of the table (data).
P.13
要實現數據隱藏，所有屬性都應當聲明為private。因此，屬性不是接口的一部份，只有public方法才屬於接口。將屬性聲明為public會破壞數據隱藏的概念。
原文.P.19
For data hiding to work, all attributes should be declared as private. Thus, attributes are never part of the interface. Only the public methods are part of the class interface. Declaring an attribute as public breaks the concept of data hiding.
P.31
盡管可能有些極端，但是要確定最小接口，一種方法就是開始時不向用戶提供任何公共接口。當然，這樣的類沒有用處；不過，這就要求用戶回過來找你，告訴你"嘿，我需要這個功能"。然後你們可以協商，這樣一來，就可以做到只在需要的情況下才增加接口。千萬不要假想用戶需要某個功能。
原文.P.42
Although perhaps extreme, one way to determine the minimalist interface is to initially provide the user no public interfaces. Of course, the class will be useless; however, this forces the user to come back to you and say, “Hey, I need this functionality.” Then you can negotiate. Thus, you add interfaces only when it is requested. Never assume that the user needs something.
P.42
在Java和C#，返回類型不是簽名的一部份。例如，儘管返回類型不同，以下方法仍會衝突：
public void getCab(string cabbieName);
public int getCab(string cabbieName);
原文.P.56
Depending on the language, the signature may or may not include the return type. In Java and C#, the return type is not part of the signature. For example, the following methods would conflict even though the return types are different:
public void getCab (String cabbieName);
public int getCab (String cabbieName);
儘管這裡顯示了兩個構造函數，但由於沒有參數列表，所以無法區分這兩個構造函數。
原文.P.57
Figure 3.2 shows a class diagram for the DataBaseReader class. Note that the diagram lists two constructors for the class.Although the diagram shows the two constructors, without the parameter list, there is no way to know which constructor is which.
P.44
設計時，好的實踐是明確所有屬性的一個穩定狀態，再在構造函數中把它們初始化為這種穩定狀態。
原文.P.60
During the design, it is good practice to identify a stable state for all attributes and then initialize them to this stable state in the constructor.
P.128
繼承和接口都能構成一種 is-a 關係。
原文.P.162
This code works fine. So,we can safely say that a dog is a nameable entity.This is a simple but effective proof that both inheritance and interfaces constitute an is-a relationship.
P.146
一般來講，組合有兩種型，關聯和聚集。
原文.P.183
Generally, there are two types of composition: association and aggregation. In both cases, these relationships represent collaborations between the objects.The stereo example we just used to explain one of the primary advantages of composition actually represents an association.
有些文章稱組合是一種關聯，而有些文章則指出關聯是組合的一種形式。在這本書中，我們認為繼承和組合是構建類的兩種主要途徑。所以，這本書中認為關聯是組合的一種形式。
Composition is another area in OO technologies where there is a question of which came first, the chicken or the egg. Some texts say that composition is a form of association, and some say that an association is a form of composition. In any event, in this book, we consider inheritance and composition the two primary ways to build classes. Thus, in this book, an association is a form of composition.
P.151
處理關聯時最重要的一個問題是，要確保應用中已經設計為會檢查可選關聯。這說明，你的代碼必須查看關聯是否為null。
原文.P.190
One of the most important issues when dealing with associations is to make sure that your application is designed to check for optional associations.This means that your code must check to see whether the association is null.
關鍵是，代碼必須檢查一種null條件，而且必須作為一種合法條件加以處理。
Suppose in the previous example, your code assumes that every employee has a spouse. However, if one employee is not married, the code will have a problem (see Figure 9.8). If your code does indeed expect a spouse to exist, it may well fail and leave the system in an unstable state.The bottom line is that the code must check for a null condition, and must handle this as a valid condition.
P.166
HTML表示數據，而XML描述數據。
原文.P.209
Soon after XML emerged, there was speculation that XML would replace HTML. Many believed that because they were both descendants of SGML, XML was an upgrade. In reality, HTML and XML are designed for different purposes. HTML presents data, and XML describes the data. Both HTML and XML are important tools in the development of Web-based systems.
P.184
這種策略增加了有意思的一點，屬性本身可以有特性。儘管這樣可能會多加幾行代碼，相應地帶來一些複雜性；但好處是類的封裝性更好。
原文.P.232
The interesting addition to this strategy is the fact that the attributes themselves have specific properties.While this may add more lines of code, and thus some complexity, the benefit is that the encapsulation of the class is much tighter.
P.224
再次說明，這個類定義最有意思的一點是：類包含必要的屬性和方法，此外，屬性本身還包含對應屬性的XML定義的特性。
原文.P.279
Again, the really interesting issue with this class definition is that, while the class contains the requisite attributes and methods, the attributes also contain properties that correspond to the XML definitions of the attributes.
P.235
要記住，最重要的OO原則之一是對象應當自行負責。這說明與類生存周期有關的問題應當在類內部處理，而不要依賴於類似 static 等語言構造。
原文.P.291
Remember, one of the most important OO rules is that an object should take care of itself. This means that issues regarding the life cycle of a class should be handled in the class, not delegated to language constructs like static, and so on.
P.237
單例對象可能會有多個引用。如果在應用中創建了多個引用，且每個引用都指向同一個單例對象，就必須對多個引用加以管理。
原文.P.293
There may well be more than one reference to the singleton. If you create references in the application and each reference is referring to the singleton, you will have to manage the multiple references.
P.242
設計模式來自於正面的經驗，而反模式(antipattern)可以認為是失敗教訓的集合。
原文.P.299
Although a design pattern evolves from experiences in a positive manner, antipatterns can be thought of as collections of experiences that have gone awry.
很多人都認為反模式實際上比設計模式更有用。這是因為，反模式就是設計用來解決已經出現的問題。這就引出了"根由分析"的概念。可以用具體的數據完成一個研究，從而可能指出為什麼原來的設計(也許原本是一個設計模式)未能成功。可以說反模式是由先前解決方案的失敗提煉而成。所以，可以認為反模式具有"後見之明"。
原文.P.300
Many people believe that antipatterns are actually more useful than design patterns.This is because antipatterns are designed to solve problems that have already occurred.This boils down to the concept of root-cause analysis.A study can be conducted with actual data that might indicate why the original design, perhaps an actual design pattern, did not succeed. It might be said that antipatterns emerge from the failure of previous solutions. Thus, antipatterns have the benefit of hindsight.
