教學用的代碼使用面向對象技術合適嗎？

01-22

截圖是Frank.D.Luna的《Introduction To 3D Game Programming With DirectX12》中第四章的示例代碼。
書的作者在前言中說過要有中等水平的C++才適合讀這本書，所以作者這樣寫代碼也沒有錯，而且可能現在業內流行的代碼就是這樣的（本人還是學生，只做過一點小程序）。
但作為一名讀者、學習者，我覺得這樣的代碼很難學習，因為你想在代碼中找到自己真正需要學習的部分（第四章知識是如何初始化Direct3D）很麻煩，需要不斷的轉到定義，並且還要去理解作者的代碼風格（個人感覺他的類繼承關係過於複雜了，沒有必要）。
那麼，用於教學的代碼到底是該注重所謂的「規範」（類、封裝、繼承、框架balabala），還是應該儘力將知識呈現出來（面向過程的、直截了當的代碼），使程序更易讀呢？

或者說，哪怕是教學用的代碼，也一定要強調「面向對象」嗎？
附：我之前通過《逐夢旅程：Windows遊戲編程之從零開始》學習過Direct3D 9的一些知識，最後做了一個簡單的第一人稱地圖漫遊DEMO（電腦壞了後沒了/(ㄒoㄒ)/~~），感覺學習的時候比較輕鬆，可以專註於要學習的知識點，封裝完全可以在學會後自己來。而現在學這本書感覺一看到代碼就沒有學習的慾望……

面向對象就是為了讓教學更加容易啊。面向對象省略了不必要的實現細節，讓你可以直接接觸到高級API和數據結構，直接開始基礎內容的學習，這是正確的方法啊。

比如你這個程序，我作為一個從未接觸過 DirectX 的人，都看懂了他在幹什麼。我不知道 InitDirect3DApp 到底是啥，但是我知道這大概是個app的類，我也不知道 hInstance 是啥，但是我知道它大概是某個基類。然後app initialize一下就可以run了，代碼還能比這更簡明么？

難道要把hInstance里的東西都給你在函數里定義了，然後再把 InitDirect3DApp 的東西給你定義了，再把 initialize 和 run 寫開，你才覺得好理解么？

我覺得你的問題應該是對面向對象編程接觸的太少，上來就有畏難心理。因為單就這一段代碼來說，已經清晰得不能再清晰了。而「封裝」的本意，就是可以讓你不去考慮實現細節。我對 DirectX 並不熟悉，hInstance 和 InitDirect3DApp 都是庫里的內容么？如果是的話，他的庫實現就是這個樣子的，並沒有辦法用別的方式教給你啊。就像你去入門C++的時候，學vector，你說這vector面向對象太麻煩了，我想要面向過程。可他本身就是個對象，他沒有面向過程的能力啊。你就是要用他的各種內建的函數……

另外，一個好的 debugger ，應該有非常方便的跳轉功能。點一下類名稱，就跳到類的定義。我從來不用 VS ，所以不知道現在他們做的怎麼樣了。但是我司的 debugger ，在這種既需要寫業務代碼，又需要理解庫函數的情況下，簡直不要太方便。

我只想說一句：你每天都在用的各種軟體，大部份都是用面向對象方法開發出來的……

需要改變的是你而不是代碼——純粹的面向過程式編程，幾乎無法解決任何現實中的問題。舉個簡單的例子，你學數據結構，哪怕用C語言實現，也是在面向對象編程。如果你連這個都不能適應，那就意味著你在軟體開發的道路上寸步難行

可以是肯定的吧。但是前提還是學生能理解，因材施教才是最好的。我覺得最好的老師就是講基礎，講方法、講理解，讓學生知道如何去前進就可以。

每本書都有各自的受眾，同樣每個階段看的書都不同的。問題不是出在書上，而是題主選錯書而已，說不定還有人吐槽這本書太簡單了呢。學習要一步一步來，既然題主現在覺得缺了oop看不懂，那麼就去學oop唄，反正又繞不過

該面向過程就面向過程

該面向對象就面向對象

該面向活下去就面向活下去

手機強答一下。封裝，繼承等面相對象編程思想被開發出來的目的可不是為了方便教學，而是在實際工作中方便抽象遇到的對象，極大提高擴展改良的效率，降低模塊耦合性，並且後期具備高重構性。面向過程編程就好比用多米諾骨牌搭建屋子，如果沒有任何變動那也不錯，可如果你想裝個窗戶，那麼必須付出拆掉半個屋子的代價去用各種工具想各種辦法支撐柱之前的力學結構，然後才能裝窗戶。當第二個第三個窗戶，門得需求被提出時，你會覺得md還不如重新蓋一間屋子省事。但面向對象，無非是給牆壁留一個窗戶介面，使用窗戶對象實現介面罷了，成本小到忽略不計。

所以我的結論是，最初學習編程時，可以看面向過程的老資料，毫無問題。但是請注意，面向對象是現代軟體行業最重要的開發思想，當你把一門語言的基礎用面向過程方法打牢時，一定要有意識去學習面向對象思想，你會發現面向對象的難度根本不在於代碼本身或者封裝，它的關鍵之處就像《三體》中被人類所發現的黑暗森林法則，一旦你理解這種規則，你的代碼就可以直達宇宙的最深之處，完成以前想也不敢想的精度，隨意變換形態依附以適應設備和項目需求。

另外一個心法，學習時求深度不求效率，儘可能可以造輪子實現需求，所以無論是那種編程思想的書，只要被時間證明是經典，盡可拿來一看。開發時求效率和安全穩定，不到萬不得已絕不用陌生未經驗證的代碼。

祝我們都學有所成。

那不如先學一點面向對象再來學這些知識點？畢竟專門的知識會在專門的書里出現，而面向對象到處都有啊。

你可能還是習慣所以代碼都懟在一個文件里，而龍書居然搞了三個類理解不能了，這可能是最簡單的一個win32程序了，還是得學習一個。

更重要的是語言能否承載初學者的想像力和創造力。

我才不管你有沒有對象，哼唧。

龍書的話，首先能來看dx12這一版的人，大部分都是有點基礎的，如果是一個從未了解過圖形學的人，那不管這本書怎麼寫他都很難輕易的看懂裡面的東西。所以你看之前吧，得先知道一點渲染的知識，比如紋理啊，光照啊，shader啊，幾何體啊這些的，我想你之前寫過dx9估計也沒啥大的問題。

然後，不管你有沒有基礎，你學的時候吧，看的是書而不是他給你的樣例工程代碼。我看過整本書，書里附帶的必要代碼都是特別清晰的，並沒有出現樣例代碼里過度封裝的情況，各種演算法每一步該幹什麼書里也說的很清楚，你不能說他的樣例面向對象封裝的很多就說他的書里知識也是以此為基礎的，書里的知識和代碼很清晰，不存在你說的那種情況。

最後，面向對象很重要，因為龍書雖說是入門書籍吧，你要整本書都一個個的實現下來最少也是有好幾萬行代碼，如果你不想照抄龍書的框架的話就自己實現一個框架就好了，這樣繼學習了圖形學，又學會了很多面向對象的知識有啥不好的～(￣▽￣～)~

最後，我個人認為啊，你覺得書不友好吧，可能不是因為他面向對象，主要是dx9到dx12跨度太大，你還不能敏銳的從他的代碼裡面找到你想要的東西，只能一點點的先學，如果換作一個在dx11或者vulkan下有熟練開發經驗的人的話，我估計也不用仔細看書，一個星期就能把這本書的所有樣例全都看明白了(?ω?) .........

class D3DBOOK，成員有c++，面向對象編程，DirectX不是很正常的嗎？

你要學會面向對象的思維！覺得這本書不行，就換一本唄

面向對象只是把過程進行了隱藏

你想看過程就直接進去看好了

如果真的把代碼堆一起，有人估計就抱怨了：幾百行代碼，超長的函數名，看一眼就暈了，這還怎麼學？

面向過程和面向對象，貌似可以統一的。就算在面向對象的編程實踐中「過程」無處不在。

但如果在教學中使用，應該要把這個淵源講清楚。

沒講清楚也沒關係，學生自己真有興趣，拿著面對對象的思想再回去理解面對過程，也不會有太大的問題。

結論：這個看我可以.....

讓還沒有對象的你情何以堪~~@

怎麼不合適？教學不就是教人寫更好地去寫代碼

面向對象也可以簡單理解嘛。

你可以強行從屬性(數據)出發。比如，想想java的 Object 必須有什麼屬性。然後有了這些以後才讓Object支持了哪些方法(用到了那些屬性的函數)。

然後繼承就是用著那些屬性，再加上一些新的屬性。然後看著現有這些屬性再定義新的方法。

然後越是繼承，就得到一個更強的斷言。得到了更具體更不通用的類型。

我理解的面向對象大概就是這些。。。