我正在開發一個包含對象Car的類庫。是否使用has-a（組合）或is-a（繼承）對汽車對象（及其零件，如引擎）進行建模？
進退兩難的是，汽車本身將是一個類，如註冊號等字段和汽車上的其他一般信息。
但汽車有引擎，底盤等。這些對象也需要建模。他們應該是嵌入車內的課程嗎？如果不是，嵌入式類的使用場景是什麼？
我瞭解到，組成「的一部分」，所以你可以模擬單獨的類和利用發動機類型，例如，在汽車領域的水平來實現這一點。然而，「聚合」（也就是「汽車」具有「引擎」）與「在ctor中傳遞的類型具有」具有「關係」。
我該走哪條路？
編輯：我目前正在做作業，因此缺乏來自我的回覆。該類庫適用於基於汽車的Web應用程序。我是一名專業開發人員（我是以.NET開發的，但是作爲初級），所以這不是一個家庭作業問題。
謝謝
這真的取決於您的應用程序。
例如，你可以實現車輪作爲單獨的類，包含什麼輪胎就可以了，怎麼穿的，等等。但如果你的應用程序甚至不關心車輪那麼整個類是信息浪費代碼。
我可以看到三個用例組成：
總結：使用組合作爲封裝複雜性或消除重複的工具。如果它沒有達到這些目的之一，那麼這可能不值得爲新課程做出貢獻。
我第二。儘管將汽車的每一部分都作爲一個單獨的課程進行寫作是很有吸引力的，但它可能是在進行這種過程。 – Gordon 2009-12-16 07:57:39
非常不贊同。許多小而簡單的課程促進了責任分離和目的明確，可讀性，穩定性，鬆散耦合的代碼。幾乎所有的面向對象的文獻都是通過繼承來促進構圖，並減少對類的責任。 – 2009-12-16 15:45:03
如果班級只有50行，那麼它已經足夠清晰了。將其分成額外的類別不會產生清晰度，會造成複雜性。如果代碼不斷增長，您可以隨時將這些部分重構爲單獨的類。 – 2009-12-16 21:07:09
汽車將是一個頂級的層次結構對象。包括簡單的字段，如數字，ID或描述。 而且會有像引擎這樣的複雜領域，它本身就是一個對象。
讓車子看起來像：
class Car{
String ID;
Engine engine;
}
一個具有-的關係。
我認爲他已經知道這一點，並正在尋找相對於其他優點的情況的指導。 – 2009-12-16 22:02:43
一個標準，你可以決定類引擎是否底盤等
需要存在作爲一個內部類（嵌入式類）是否
這些類的實例可以在應用程序中的其他地方使用。在這種情況下，決定是簡單的，它是使這些類別單獨存在
（不作爲內部類別）。
即使這些類未在您的應用程序的其他地方使用，那麼其他
條件也可以測試。將這些類嵌入到內部並與您的設計一起使用，可以進行單元測試，以便適當地測試您提供良好覆蓋範圍的代碼。
例如說，如果你做了一個實例變量它引用的
引擎對象，這個變量是在Car.And
的構造函數初始化 你的引擎類有一些方法，這需要進行測試。那麼你怎麼可以添加單元測試來檢查Engine類中的代碼？可能你會在Car類中有一些暴露行爲或引擎類的方法，它們允許你編寫單元測試。那麼問題是，如果需要暴露
引擎類的行爲不是更好的引擎類
站在它自己的？
或者可能沒有必要進行明確的測試中
Engine類和單位的方法測試方法在汽車覆蓋發動機類代碼
爲好。然後它反映了引擎類與Car類
的緊密整合，並且意味着它可以保持爲內部類。
鑑於這是家庭作業，並且根據您的導師/教授/老師的傾向，您最好還是沿着爲發動機，輪子等編寫單獨課程的路線走下去。儘管它可能是完全過度設計，並且應用程序可能不關心他們，有可能是你的家庭作業將由標準，如標明：
「他們識別引擎類」
「是否有合理的方法，如開始（）」
‘記下來了結塊在一個大的類，它實際上是簡單的一切，因爲他們不瞭解清楚組成’
或什麼的，而不是種的標準，在這個線程中更務實的人適用於他們自己的設計。
一個類應儘可能少的責任，並將其他功能封裝並委託給其他類。許多做一件事的小型簡單類是可讀，穩定代碼庫的標誌。
是的，一輛汽車將「擁有」一個引擎，但我建議使用一個接口爲此和類似的「有」關係。此外，根據不同的教授，你可能會得到加分有工廠創建不同的汽車（適當的，不是嗎？）：
public class Car
{
private Engine engine;
public Car(Engine engine)
{
this.engine = engine;
}
public void accelerate()
{
this.engine.goFaster();
}
public void decelerate()
{
this.engine.goSlower();
}
}
public interface Engine
{
public void goFaster();
public void goSlower();
}
public class ReallyFastEngine implements Engine
{
public void goFaster()
{
// some code that goes really fast
}
public void goSlower()
{
// some code that goes slower
}
}
public class NotAsFastEngine implements Engine
{
public void goFaster()
{
// some code that goes not as fast
}
public void goSlower()
{
// some code that goes slower
}
}
public class CarFactory()
{
public static Car createFastCar()
{
return new Car(new ReallyFastEngine());
}
public static Car createNotAsFastCar()
{
return new Car(new NotAsFastEngine());
}
}
只有打破汽車的模型成將被暴露作爲獨立的實體件汽車的範圍之外。另一種思考的方式是，你真的瞭解你開車時如何開始駕駛汽車？就典型的駕駛員而言，引擎蓋下的所有東西都是一個大的（嘈雜的）黑匣子。汽車工程師知道汽車所有者需要維修的通用部件，並明確地爲不同級別的用戶交互設計了這些部件，例如油尺或冷卻液儲液器補充蓋。
你可以模型的每一輛車？當然。模擬單個火花塞有幫助嗎？可能不會。
您是否需要具有顏色或尺寸等不同屬性的汽車？您是否需要具有乘客或牽引能力等不同功能的汽車？一個不同的地方是如果你需要不同行爲的汽車。這是您真正需要考慮建模具有屬性的Driver對象的地方，從反應時間等簡單的對象到侵略性等複雜的對象。
將車輛建模爲面向對象或繼承的示例是有問題的，因爲這些示例沒有真正解釋定義類的基本屬性之間的真正區別。這對StackOverflow並不新鮮，但是這個問題也不是重複的，see this SO thread。我和我的一位朋友進行了同樣的討論，併發布了log of it on my blog。閱讀FAA認可的不同類型飛機，以及每種類型的規章如何細分。有很多不同類型的飛機，最大的區別在於動力和無動力。
檢查出definitions used by the FAA：
飛機意味着用於 或擬用於 空氣飛行的裝置。
飛機指由發動機驅動的 固定翼飛機大於在飛行通過空氣的針對 其翅膀 動態反應所支持的空氣， 重。
飛艇指由發動機驅動的 比空氣輕的飛行器，可以是 轉向。
還有比空氣輕且比空氣重的空氣。熱氣球沒有動力，比空氣輕。一個飛艇是動力和輕於空氣。滑翔機沒有動力，比空氣重。波音757動力強勁，比空中重，但增加了另一類「固定翼」，這與直升機不同，它的動力和重量都比空氣強，但是是「旋轉翼」。
這裏是一個表的形式前四：
| Powered | Unpowered
---------------------------------------------------
Lighter-than-air | Blimp | Hot-air balloon
Heavier-than-air | 737 | Glider
你得到的圖片。
你不能只是說你會與汽車分開建模發動機，因爲沒有發動機的汽車可能是一個完全不同的動物。沒有引擎的汽車就像一輛拖車，它也沒有引擎，但從來不會。在這些情況下，既不是'是'也不是'具有'符合我們建造物體的具體方式。你不會宣稱一架飛艇是一架「比空氣輕的飛機」，熱氣球也是如此。事實上，他們都比空氣輕，除了他們利用的物理外，並沒有以任何方式使它們相關。區別很重要，因爲適用的規則和條例是不同的。從另一個角度來說，我們並沒有把一個軟式飛艇描述成一個具有'引擎'的熱氣球。這架飛機沒有身體上的關係，這種關係是他們應該如何處理的。
如果您不需要將對象定義爲該細節級別，則可能不需要將它們建模到該細節級別。
這取決於你想要做什麼。試圖在沒有使用案例的情況下設計'汽車'類（或任何其他類）是徒勞的。
根據您嘗試啓用的用例，您將設計類和它們的關係以及交互方式非常不同。
如果你解釋這個類庫的目的，可能會提供更多有用的建議。它打算使用哪種類型的應用程序？ – 2009-12-16 08:01:26
聽起來像「學術興趣」又名作業 – Kimvais 2009-12-16 08:34:56
爲什麼他們需要建模？你是否計劃對造成它們的原子進行建模？ – 2009-12-16 12:54:51