大一 OOP

每週計算機結構之前，都會聽到大一 OOP 的最後一小段。上星期聽到 argument passing，這星期聽到…好像是 expression vs. statement，沒很注意聽 XD。所以去年教學意見調查似乎沒有起太大效用（至於 IS 在學期初看到又是電話先生的時候就篤定沒起作用 XD）。我知道他所謂「學習第二個程式語言」所要強調的東西，基本上就是編程往編譯器的那段任脈，但課程名稱是 OOP，顯然重點應該是另一個方向 ─ 編程往軟體工程的那一段脈，特別是這段在資訊系其他必修課程再也不會成為焦點了。往下的那一段在這門課應是補充性質，主要該顧好往上的那一段。

寫那篇〈物件導向編程精要〉，多少有點賭氣，宣稱：「看，OOP 明明就有這些東西要講，不是說都沒東西可講只好往別的方向啊」XD。就算講得很快一下子講完了，那還有 OOD 可以講嘛，和 IS 從 OOA 下來剛好可以接上。我相信此篇作為「對於 OOP 核心理論熟悉與否」的 criterion 很合適：如果對裡面的名詞都不熟，那就該多看點書，因為裡面的名詞幾乎都是核心的定義和原則；如果理解認同我的脈絡，那當然沒問題（英雄所見略同 XD）；如果覺得我寫得一塌糊塗，有能力加以批判修改，那就是高手（當然我會想跟你辯論交流一番）XD。

除了核心理論以外，一個 OOPL 以哪些構件支援 OO 概念，這個 OOPL 的專門特性為何，有哪些慣用手法（idioms），這都很值得在這門課裡面傳授。而且很重要的一點：不要用編譯器理論去介紹那些構件！編譯器實作取決於語言設計，而後者又取決於思維模式，所以用編譯器理論去解釋「OO 構件設計」在邏輯上是用必要條件去解釋原因，方向錯誤！不過我不是說不要理編譯器那個方向的解釋，那個對於點脈也很重要，而且構件設計會有一些實作考量，有時候適度引入底層實作方面的解釋是對的。不過主要該用高階概念去詮釋。

或許請講師（或研究過這東西的年輕教授？XD）來開 OOP & IS 才是最好的方案，不然真的，不開也罷。相關評論在大一下學期的 blog 應該滿多，這裡不繼續說了 XD。不過最大的問題可能是：如果系上開了什麼課程安排的討論會議並邀請學生參加，我敢不敢舉手發言：「OOP & IS 請找適任的老師，不然乾脆拿掉」？XD

--
我寫這篇的動機會很明顯嗎？XD