[討論] 關於COP混合導向語言

看板Soft_Job作者 (perry tsai)時間9年前 (2016/08/07 02:09), 9年前編輯推噓6(6推 0噓 32→)
留言38則, 4人參與, 最新討論串1/1
Composite Oriented Programmint 對比OOP似乎是更適合描述現實世界狀態 我在Apache Zest Project中看到這個觀念 Zest是由Qi4j納入Apache後改的名稱 而Qi4j原先提倡觀念如下： 1.Behavior depends on Context 2.Decoupling is a virtue 3.Business Rules matters more. 4.Classes are dead, long live interfaces. 有人對COP程式設計有研究嗎？ 會是未來新的語言的設計考量嗎？ 目前Zest是屬於將Java轉化為COP思考模式的做開發的一個框架 https://zest.apache.org/java/2.1/two-minutes-intro.html Hello world範例如連結 我理解的觀念是 將Interface看成是一個Role class是實作方法的地方 一個Role可能會有早上當程式設計師晚上下班兼職做網路賣家 所以可以寫 Developer.class實作coding() ,debug() Seller.class 實作sell(), shipping() 隨時想要讓這個Role處理什麼事情 只要Role跟class混合(mixin) 就可以使用該方法。 所以Role去mixin Develope.class 會產生一個Instance 就可以用coding() debug() 不知道理解有沒有錯。 感覺這樣的設計思想還不錯， 估計可以提升class的重用機率， 比起不斷的繼承造成肥大的體系似乎來的好的多？ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.137.57.11 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1470506956.A.DDA.html ※ 編輯: ripple0129 (223.137.57.11), 08/07/2016 02:53:09
推
08/07 05:45, , 1F
看起來是在避免多重繼承造成的問題吧 還有你那樣的用法
08/07 05:45, 1F
→
08/07 05:45, , 2F
不會產生一堆意義不明的免洗 classes 嗎 @@
08/07 05:45, 2F
事實上我也只是猜測而已，相關的設計思維似乎是Domain Drive Design。我的理解是Int erface做為一個Domain物件，在該Domain物件下它能結合不同的class(可以說是方法庫了 ），面對不同的狀況下能透過混合產生不同的能力來處理。所以在需要時就生成instance ，用完就毀滅。至於classes會不會產生一堆免洗classes，我覺得可能還是會有個misc c lass來處理那種不常用方法吧。一切純猜測，待有經驗的高手分享。 ※ 編輯: ripple0129 (223.137.57.11), 08/07/2016 06:21:13
→
08/07 09:26, , 3F
要喇賽了嗎？
08/07 09:26, 3F
→
08/07 18:54, , 4F
看起來像是限制比較多的OOP。所以結論還是OOP？
08/07 18:54, 4F
→
08/07 18:55, , 5F
有種c++爛掉了，所以做一個限制比較多的java的即視感。
08/07 18:55, 5F
→
08/07 18:57, , 6F
不過那也得COP有那麼好才行。 要改誰都行，改好就很難說。
08/07 18:57, 6F
其實不算OOP，真的要說算IOP(interface)。我（Role)是一個接口，當我是程式設計師時 ，我要有與developer class的能力。我是賣家時要有seller class的能力。唯一對外面 向的都是我（Role)。如果以OOP的觀念設計，我白天是developer晚上變seller，會是兩 種物件，就無法充分描敘現實狀況。 其實每個OOP且帶有interface的語言應該都蠻容易去實現這一種程式設計風格。 ※ 編輯: ripple0129 (223.140.224.5), 08/07/2016 19:23:17 ※ 編輯: ripple0129 (223.140.224.5), 08/07/2016 19:25:13
→
08/07 19:38, , 7F
其實每個OOP語言應該都蠻容易去實現OOP這種程式設計風格:)
08/07 19:38, 7F
個人覺得應該是不止這樣，上面寫的其實也是我的猜測，有可能有誤解。可能還是要讀原 文免得被我誤導XD ※ 編輯: ripple0129 (223.140.224.5), 08/07/2016 19:47:06
推
08/08 01:27, , 8F
我覺得就是用組合而不用繼承
08/08 01:27, 8F
推
08/08 03:41, , 9F
剛剛去看了你的網址 其實我覺得它只是在做 c++ 原本就在
08/08 03:41, 9F
→
08/08 03:41, , 10F
做的事而已…
08/08 03:41, 10F
→
08/08 03:42, , 11F
Java is not my native language 覺得我亂講請見諒
08/08 03:42, 11F
→
08/08 03:45, , 12F
interface 就像是在模擬 c++ 的 header 一樣
08/08 03:45, 12F
→
08/08 03:49, , 13F
我不懂 Java，但就我的認知，你一樣要在 interface 裡面
08/08 03:49, 13F
→
08/08 03:49, , 14F
宣告 prototype 才能 mixin 對應的實作是嗎@@
08/08 03:49, 14F
→
08/08 03:53, , 15F
如果是的話 那其實講白了不就只是原型實作分離 然後用比
08/08 03:53, 15F
→
08/08 03:53, , 16F
較酷炫的方式動態的合併？
08/08 03:53, 16F
→
08/08 03:58, , 17F
就算不需要在 interface 裡預先宣告好可能被 mixin 的東
08/08 03:58, 17F
→
08/08 03:58, , 18F
西的 prototype
08/08 03:58, 18F
→
08/08 03:58, , 19F
它其實也只是讓 Generic 的東西可以像 member 一樣被操作
08/08 03:58, 19F
→
08/08 03:58, , 20F
而已
08/08 03:58, 20F
→
08/08 04:00, , 21F
如果是這樣的話 c++ 的 friend 就是這個功用，只是需要在
08/08 04:00, 21F
→
08/08 04:00, , 22F
class 裡面宣告這個 Generic function 為 friend
08/08 04:00, 22F
→
08/08 04:14, , 23F
如果要說機動性，可以隨時 mixin 來用的話，interface
08/08 04:14, 23F
→
08/08 04:14, , 24F
的 extends 組合看樣子是固定的，c++ 則可以用 template
08/08 04:14, 24F
→
08/08 04:14, , 25F
編譯期動態決定繼承組合(police-based design)，也是一
08/08 04:14, 25F
→
08/08 04:14, , 26F
樣效果，而且 c++ 還比較滿足高聚合這點，低耦合則差不多
08/08 04:14, 26F
C++不熟，原生就支援多重繼承的語言能輕鬆做到相同效果不意外。對C++的使用者來說， 不過就是提供了另一種coding style的想法吧。除了ios android這類語言綁定的之外， 還真想不到有什麼是C++辦不到的XD。 ※ 編輯: ripple0129 (223.140.224.5), 08/08/2016 04:25:06
→
08/08 04:25, , 27F
不是在比較 Java 和 c++，而是拿我比較熟悉的語言來看所
08/08 04:25, 27F
→
08/08 04:25, , 28F
謂的 COP 帶來了什麼特性
08/08 04:25, 28F
推
08/08 04:37, , 29F
看到你在 Java 版的文了 那這其實就是 C 語言 .h 宣告 .c
08/08 04:37, 29F
→
08/08 04:37, , 30F
實作的概念啊 XDD
08/08 04:37, 30F
推
08/08 04:39, , 31F
那這應該是不會成為未來語言的設計考量啦 (被毆 XDD
08/08 04:39, 31F
用C比好像怪怪的，非OOP語言，#include跟interface差距還是很大吧。倒比較像Java im port。其實說起來語言要限制住這樣的思考模式來設計也反而有點死，可能這種方式還是 適合框架來實現比較實在。 ※ 編輯: ripple0129 (223.140.224.5), 08/08/2016 04:50:52 也可以參考Zest在設計Application的思維， https://zest.apache.org/java/2.1/howto-assemble-application.html 組合service entity成module, module組合成layer,layer堆疊成application. ※ 編輯: ripple0129 (223.140.224.5), 08/08/2016 04:54:23
推
08/08 05:11, , 32F
Java 沒有原型這種東西 這裡就是用 interface 模擬原型，
08/08 05:11, 32F
→
08/08 05:11, , 33F
class 實作
08/08 05:11, 33F
→
08/08 05:11, , 34F
C 和 C++ 通常原型宣告在 header，實作定義在 source，
08/08 05:11, 34F
→
08/08 05:12, , 35F
我上面只是想表達這個而已
08/08 05:12, 35F
→
08/08 05:12, , 36F
如果你真的喜歡這樣的設計，推薦你鑽研 c++，它提的東西
08/08 05:12, 36F
→
08/08 05:12, , 37F
很多都和 c++ 預設風格不謀而合，不過它倒是給了這些平常
08/08 05:12, 37F
→
08/08 05:12, , 38F
在用的東西一個全新的解釋，原來還可以這樣解讀啊 XD
08/08 05:12, 38F
‣ 更多 ripple0129 的文章
文章代碼(AID): #1NfYVCtQ (Soft_Job)