Ruby for Rails 與 物件導向工程

Robert C. Martin 在UML FOR JAVA 指明物件導向本質就是人與人之間的互動
而在Martin Fowler 的分析模式中domin drive develop說明domin來源由user
分析正確性來的高。而在蔡學鏞在說過教一個三歲小孩物件導向比程式員來的
的容易多了。

Robert C. Martin認為物件導向本質就是人與人之間的互動更詳細一
點就是人事物互動工程也就是生活工程,我一直以認為物件導向=生活
化工程,也以生活化工程來思考軟體工程,但事實並非如此。

答案可能有2種

一.如果Robert C. Martin說的物件導向本質就是人與人之間那現在大部份
軟體工程人員對物件導向的認知是錯的,這是第一種可能。

二.第二種可能,軟體工程人員對物件導向的認知是對的,軟體工程應該是
物件導向工程-->生活工程-->現實世界


如果在物件繼承體系中

                      
                           動物   
                             /  \   
                            /    \    
                           猴子  人

如果有人穿猴子衣服,模仿猴子,那人就具有猴子的屬性,還爬樹的行為,當你聽到
說話聲,你會認為是人在說話還是九官鳥在說話,孫悟空有七十二變可以變石頭,那
孫悟空又是什類呢?當然舉孫悟空的例子有點誇張,但論點正好府合Programming Ruby
書中的類不是類,為什麼呢?,在java要如何才能將人轉換成猴子呢?

因為類的實例具有模仿跟掩飾的能力,現實中也如同

但不管具有模仿跟掩飾的能力,人依然是人,鳥依然是鳥所以對照現實世界歸類,人事物依然
是單一繼承,可是怎麼實現模仿跟掩飾的能力,是C++多重繼承嗎?還是Ruby的include呢?我
想這都不是完整的實現,為什麼提到Ruby for Rails一書,因為書中第一部份講的是Ruby的
精神,第一部份講的是我們要將Ruby編程推向現實世界在努力,我認這是書中最精華的部份
這樣是否在宣告物件導向目前的狀態是處在第二種答案,看了書中第一部份讓我想起java
己死的帖子,我只有看到標題,沒有看到內容因為可能又是口水帖,現在想起,我的感覺不是
指java沒前途,也不是指開始衰退,而是指的是java模式思想是錯的是反模式的,我承認java
在底層跟API和Framework做的很好,但是不去改良C++多重繼承,保留優點,去除缺點,而是完
全否定,到現在我還不明白interface的意義在做是什麼。


Java經過長久的進步它的思維已經將它的能力揮到極限。
可以發現Java現在做的只是一直在做外掛模式設計。

我看了robbin的關係模型和對象模型的究竟匹配還是不匹配？
有一句話:

關係模型和對象模型存在概念上的阻抗不匹配，但是在關係數據庫的存儲模型上是一致的，無論你從關係模型的三大範式理論出發，還是從對象模型的ORM理論出發，最終一定會得到一致的數據庫表設計。


有人認同,有人反對,我的感覺是robbin想要以技術解釋意義,意境,
可是卻很多人以技術反駁,重點不是說明技術,而是意境的道理

我推斷robbin是在脫離Java思維之後所發現的想法,如果錯了還請robbin原諒。

我們在做軟體時必須考慮User習慣與輕便因為人不是CPU,同樣發明軟體工程也要考慮到人性
因為程式人員同樣不是CPU。

科技紿終來自人性

這是說明心思維的帖子,技術口水帖不要來
方向永遠比道路重要,用再好的技術陳鋪好的道路,走錯方向也無用武地,而方向來自真意

很多程序员的"面向对象"观念是从学习象C++之类的强类型静态语言慢慢培养起来的（包括我自己），因此思维被限定在透过“类”模板来描述世界。而向Ruby的“duck typing”从另一个角度来阐述“对象”－－用行为来归纳，这也许更符合现实世界。跨越物种的人和猴子都会爬树，那么当分析一个对象是否具备从树上摘果子这个能力问题时，无需太计较是人还是猴子。
或许这种“面向行为”的方法在解决特定问题的时候会有很大便利？

也許我表逹的不夠清楚。

Robert C. Martin 在UML FOR JAVA 指明物件導向本質就是人與人之間的互動所指的物
件導向跟學習軟體工程所學到的物件導向是不同的。

我們暫且稱Robert C. Martin的物件導向為 A
而從JAVA平台學到的物件導向暫且為 B

用Ruby的編程跟Java做比較是因為差異性較大,這樣的感覺會比較明顯。
順便替Ruby講一句話,Ruby在思維上至少肯向前進步,而java卻在物件導向上
一直停留,Java中的interface只是用來彌補技術上的缺點,在意義上是不存
在任何價值。


A 所指的意思是用一般人(User)的思維核心學習軟體工程

B 所指的意思在軟體工程中學習物件導向。

Martin Fowler跟Robert C. Martin一直致力於人的思考方式去創造軟體工程思維,
我們不應該用軟體工程的角度去思考軟體,而應該用一般人角度去思考探索。

如果了解 A 那大概就可了解robbin所說的

關係模型和對象模型存在概念上的阻抗不匹配，但是在關係數據庫的存儲模型上是一致的，無論你從關係模型的三大範式理論出發，還是從對象模型的ORM理論出發，最終一定會得到一致的數據庫表設計。

借用robbin的模式講一句話:

系統和現實世界存在概念上的阻抗不匹配,但是在方向上是一致的,系統只是現實生活下的影子,現實生活才是主體,在軟體系統最終一定會有現實生活例子的對照。

人是主宰軟體工程,而不是被軟體工程主宰,一部份人都會陷入軟體工程的迷失,
連看一部電影都可用設計模式來解釋,有一點走火入魔。

很難對物件導向的思維做一個說明,如果一定對物件導向給出一個方向的話,當你在思考
時必須忘記所有軟體知識,執行時必須把軟體工程的知識找回來。

有没有注意过《分析模式》的附录A，也许会对这个问题有所启发。

"到現在我還不明白interface的意義在做是什麼。"
---------------------------------------------
这个说法让我好惊讶!!

Java中的interface是用來彌補技術上的缺點,
是編程式的一種技術如Quake Wang在jert報表
中用來做權限,但在物件導向中類別與實例中都
有其意義存在,但在物件導向理論中卻未對interface
有做解釋其存在的想法,還是在物件導向中的意義中我
不知道可否解說?

你是以Ruby的編程方式來學習物件導向?
或者是以物件導向來思考Ruby編程技術的合理性?
而Ruby作者是以編程技術來創造Ruby,或者是以心的理念想法來創造Ruby?

一針見血

轉發《分析模式》的附錄A的幾句話:

對於這些技術至今都沒有標準,所以我不得不選擇那些我感覺正確並且不過於異常的東西

UML集中於實現建模而不是概念建模而--本書集中概念模式

我發現以三個視角來思考類型圖的建造是有用的,這三個視角是:概念層,規約層,實現層。
概念模型以人們思考世界的方法建模。它們完全是精神上的圖像,忽略任何技術問題。

首先,一個對象具有一個能够從多個超類型継承的獨類型,還是具有多個類型?多重分類和
多重継承是不同的。.......

在一個概念模型中所有子類型化都被看作動態的,除非用一個簡短的語意說明顯式地定義。
這不僅反映世界上可能可能發生的變化而且反映我們關於它們的不斷變化的知識。

而Ruby比Java更接近概念模型,這不是單靠編程技術的高超,而是以概念模型,更切確是以人們思考世界
方式為核心。

说一个有趣的小常识.在汉语里面,我们可以把周围的亲戚,分为爷爷奶奶，外公外婆，叔叔舅舅，婶婶舅妈。但是在英语里，中文里这一切繁琐的称呼统统归结为简单的grandpa,grandma,uncle,aunty。

英语还不分兄弟和姐妹呢，这个是建模的粒度问题吧。

英语语境下亲戚是属于爸爸这边的还是妈妈这边的，亲戚是爸爸妈妈的哥哥还是弟弟，这样的一些额外信息全部都丢掉了，亲戚对象少了父系母系，长幼之分这两个属性。
而中文语境下往往需要这些属性来区分这些亲戚的不同好来处理一些复杂的人情事故方面的事情吧。

分析模式说：不存在正确或错误的模型，只存在对手头的工作更适用的模型。
在中国，日本这种需要考虑父贵兄长的语境下，应该是这种附带额外信息的亲戚模型更适用些。