你的問題，很難回答您。
因為只有不懂得設計、沒開發過大專案或是沒合作開發經驗的人
才會有這種的蠢問題。但你也說了你想要討論。

畢竟，從你後面的說明。我也有注意到說。你對於「物件導向」的名詞有自已的解釋。

任何程式語言，都可以寫成「物件導向」。
程式語言，都只是協助設計者做語意化的文字。
但實際電腦是看不懂C啊C++啊啥鬼的東東。
它只認識機器語言。

所以...「那為何作業系統不改用C++設計呢? 」這句話是真的看到有點....
其實你也可以用C++來寫一套作業系統看看。
包管你馬上了解為何要用「物件導向」及「作業系統」開發的問題點在哪。
但...是真的可以開發出來。能力夠強的話。

後續再看看其它人如何看待這樣的問題吧。

你來IT邦問這種問題就錯了

這邊都是技術含量較低的Web和應用資訊系統阿XD

去請教Linus 比較快

Q. 有沒有大型程式是用結構化設計會比物件導向設計更好的 ?
在一般情況下，物件導向設計 (OOD) 通常是比結構化設計 (SD) 更好的選擇。物件導向設計是一種軟體設計方法，它強調將系統分解為可重用的、相互協作的物件。這使得軟體更易於理解、擴展和維護。

結構化設計是一種軟體設計方法，它將系統分解為較小的、相互協作的模組。結構化設計通常使用流程圖或伺服器圖來解決問題，並強調數據流和控制流。

雖然結構化設計在某些情況下可能會更簡單或更易於理解，但物件導向設計通常是更為強大和靈活的選擇。物件導向設計更容易應用於複雜的系統，並且更容易擴展和維護。

然而，沒有一種軟體設計方法是絕對的最佳選擇，因此決定使用哪種方法取決於您的需求和目標。在決定使用哪種軟體設計方法時，您需要考慮系統的複雜度、可重用性、擴展性和維護性。

Q. 如果要用結構化程式來表達汽車，會如何做 ?
如果要使用結構化程式設計來表達汽車，可以先定義一些模組來表示汽車的不同部分。例如，可以定義一個模組表示发动机，另一個模組表示车轮，以及其他模組表示汽車的其他部分。

然后，可以使用流程圖或伺服器圖來描述如何將這些模組協議在一起，以便汽車可以正常运行。例如，可以使用流程圖來描述发动机如何将能量转化为运动，以及如何使用油门和刹车控制汽車的速度。

此外，还可以使用函數或程序來表示汽車的各种功能，例如启动发动机、打开窗户、打开天窗等。

總的來說，使用結構化程式設計來表達汽車可能會較為困難，因為汽車是一種複雜的系統，它由許多相互協作的部分組成。然而，通過將系統分解為較小的模組，然后使用流程圖或伺服器圖來表示如何將它們協議在一起，可以在一定程度上使用結構化程式設計來表達汽車。

Q. 為何作業系統不改用C++設計呢 ?
作業系統是一種複雜的軟體，它負責管理計算機的硬件和軟件資源，並提供用戶和其他軟件使用這些資源的接口。作業系統需要高效地運行，並且必須對各種硬件和軟件環境進行優化。

雖然 C++ 是一種功能強大的程式語言，但它並不是最適合用於作業系統開發的語言。這是因為 C++ 的設計重點主要是高效率、低級別控制和可移植性，而不是簡單性和易用性。

作業系統開發通常需要對系統的底層細節進行精確控制，並需要對硬件和軟件進行優化。因此，許多作業系統都使用低級別的程式語言，例如 C 或汇编語言，來實現這些功能。

此外，作業系統需要與各種不同的硬件和軟件環境相容，因此需要具有較高的可移植性。雖然 C++ 也具有較高的可移植性，但它比較複雜，並且在某些情況下可能無法實現所需的精確度和性能。

總的來說，C++ 可能不是最適合用於作業系統開發的程式語言。但這並不意味著 C++ 在作業系統開發中沒有用處。 C++ 可能會用於某些特定的作業系統功能的開發，例如驅動程序或其他低級別系統軟件。

作業系統開發是一項複雜的任務，它需要考慮許多因素，包括硬件和軟件環境、性能和效率、可移植性和易用性。因此，選擇用於作業系統開發的程式語言是一個複雜的問題，需要考慮許多不同的因素。

Q. 我在想是因為 OS kernel 不需要這種多物件導向設計嗎? (比方說多了抽象化導致難以維護、多了OO特性會變得沒那麼"簡單")

是的，一個主要原因是操作系统内核通常不需要使用物件導向設計 (OOD) 的複雜功能，因為内核的主要任務是管理計算機的硬件和軟件資源，並提供給用戶和其他軟件使用這些資源的接口。

因此，操作系统内核通常需要具有較高的性能和效率，並需要對系統的底層細節進行精確控制。這些要求可能會使用物件導向設計中的複雜功能造成額外的負擔。

此外，操作系统内核需要與各種不同的硬件和軟件環境相容，因此需要具有較高的可移植性。物件導向設計中的複雜功能可能會降低可移植性。

另一個原因是，操作系统内核通常需要在系統的底層運行，因此它們必須保持較小的尺寸和較低的記憶體需求。使用物件導向設計中的複雜功能可能會使軟件的尺寸和記憶體需求增加。

雖然物件導向設計可以提高軟件的可重用性和可維護性，但在某些情況下，它們可能會增加軟件的複雜度，並導致軟件的性能和效率降低。在操作系统内核的情況下，這些因素可能會成為使用物件導向設計的重要考慮因素。

然而，這並不意味著操作系统内核不能使用物件導向設計的任何功能。在某些情況下，使用物件導向設計可能有助於提高軟件的可重用性和可維護性，並且可能會更容易理解和維護。然而，在操作系统内核的情況下，這些因素可能會被性能和效率的要求所抵消。

總的來說，選擇使用哪種軟體設計方法取決於軟體的目標和需求。如果軟體需要高效率和精確控制，並且需要與各種不同的硬件和軟件環境相容，則可能會選擇使用結構化設計或其他非物件導向設計方法。如果軟體需要高度的可重用性和可維護性，則可能會選擇使用物件導向設計。

在操作系统内核的情況下，由於需要高效率和精確控制，以及需要與各種不同的硬件和軟件環境相容，因此通常會選擇使用低級別的程式語言，例如 C 或汇编語言，而不是使用物件導向設計。

Q. 沒有物件導向，一定會更不方便嗎 ?
在某些情況下，使用物件導向設計可以提高軟件的可重用性和可維護性，並且可能會使軟件的設計和開發更容易理解和維護。

然而，這並不意味著使用非物件導向設計方法就一定會使軟件開發變得不方便。在某些情況下，使用非物件導向設計方法可能會使軟件的設計更簡單且更容易實現，並且可能會提高軟件的性能和效率。

因此，選擇使用哪種軟體設計方法取決於軟體的目標和需求。如果軟體需要高度的可重用性和可維護性，則可能會選擇使用物件導向設計。如果軟體需要高效率和精確控制，則可能會選擇使用非物件導向設計方法。

Q. 是否有使用 c++ 撰寫完整作業系統的範例？
是的，有一些作業系統是使用 C++ 撰寫的。例如，Genode 是一個使用 C++ 撰寫的作業系統框架，它提供了用於構建定制作業系統的工具和技術。 Genode 可以在各種硬件平台上運行，包括 x86、ARM 和 RISC-V 等。

此外，Redox 是另一個使用 C++ 撰寫的作業系統，它旨在提供一個簡單、安全和可擴展的作業系統平台。 Redox 可以在 x86 和 ARM 硬件平台上運行，並提供了一個模塊化的架構，可以通過添加或刪除模塊來定制作業系統的功能。

以上是 chatGPT 的回應，如果你覺得這裡的回應不是很友善的話，或許可以考慮跟 AI 對談看看，希望以上的回答對你有一些幫助

總結來說，結構化設計和物件導向都是程式語言的一種面向、風格，通常會根據開發需求選擇，比較少人會直接對這兩種風格進行討論。
你提到的作業系統算是蠻大的題目，討論起來難免會有點理論、不夠落地，建議可以再把範圍縮小一點，或許回應你的人會比較多，討論也會比較良性。

最後一個答案，Genode, Redox 這兩個經過確認都是實際存在的作業系統，也都是開源的，有興趣可以研究看看
唯一小小凸槌的地方，Redox 是 rust 寫的

補充一下
物件導向分成二個派別
現代 OOP = 封裝+繼承+多態
古典 OOP(演員模型) = 消息傳遞 + 隔離 + 多態

參考
如何看待Erlang之父Joe Armstrong觉得OO编程很烂？
演員模型
物件導向程式設計

個人認為物件導向是一種程式碼的管理方式。

現在RD的分工都很細，在開發或維護大型系統(或應用程式)的過程中，每個人可能只負責一個小部分功能，而且需求經常會因應市場環境(或老闆的喜好)不斷的變更(甚至變更到發布的前一天晚上還在變更)，如果沒有用物件導向的方式來組織各個模組，那在工作的協同上勢必會遇到一大堆bug。

抽象化的過程是讓程式碼更貼近人的思維，並不會讓程式碼變複雜，反而是變得更容易理解且更好維護才是，如果你的物件導向會讓你的程式碼變複雜，那應該好好思考一下你寫的code真的是物件導向嗎？

作業系統的開發我不懂，但我不認為作業系統會像一般的應用程式需要去適應當前環境而不斷的調整業務邏輯，因此可能也不需要物件導向來處理大型協做上可能會遇到的問題吧？更何況物件導向的設計還會使效能下降，在作業系統這種理論性極強，拚效能的開發環境中，系統效能上的考量可能會大於降低管理難度上的考量。

最後是我覺得 【為何作業系統不用C++寫】 的這個問題，就好比從台北到高雄，你也可以用倒立的方式抵達，只要你辦得到有何不可呢，只是為何沒有這麼做，必然有其原因(或市場因素或歷史背景)，因此與其去探究為何不用ABC去完成，為何不直接探討問題的根本，去探究 【為何作業系統要用C寫】 呢?

說到作業系統，也不懂，很多人都說C++是C的超級(superset)
那為何作業系統不改用C++設計呢?

作業系統核心一般不會使用C++進行設計，因為C++的額外特性，如動態記憶體分配，可能會增加運算的開銷，並且造成效能的減慢。另外，C++有許多的特性，如虛擬函數，多重繼承等，對於作業系統核心沒有必要。C++提供了一些特性，如類別、封裝、繼承和多型等，使得代碼更加清晰，更易於維護和修改，造成物件導向程式設計通常需要更多的運算資源，因此對於作業系統核心，物件導向程式設計可能不是一種很好的選擇。

我在想是因為OS kernel不需要這種多物件導向設計嗎?(比方說多了抽象化導致難以維護、多了OO特性會變得沒那麼"簡單") (原來優點變成缺點了?)
註:此"簡單"非難易度上的簡單

高效能和吃較少資源 VS 可重用性和可維護性 的取捨