2007/03/26

大一 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

Labels:

Blogger Fall3/27/2007 12:33 am 說:

XD

「我覺得這堂課學不到啥OOP的精神」

 
Anonymous 哈密瓜3/27/2007 5:57 pm 說:

大一下OO的課真的是個痛Orz

 

<< 回到主頁