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

[ripple0129 (perry tsai)]

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
推 CoNsTaR: 看起來是在避免多重繼承造成的問題吧 還有你那樣的用法
→ CoNsTaR: 不會產生一堆意義不明的免洗 classes 嗎 @@
事實上我也只是猜測而已，相關的設計思維似乎是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
→ wesley234: 要喇賽了嗎？
→ manaup: 看起來像是限制比較多的OOP。所以結論還是OOP？
→ manaup: 有種c++爛掉了，所以做一個限制比較多的java的即視感。
→ manaup: 不過那也得COP有那麼好才行。 要改誰都行，改好就很難說。
其實不算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
→ manaup: 其實每個OOP語言應該都蠻容易去實現OOP這種程式設計風格:)
個人覺得應該是不止這樣，上面寫的其實也是我的猜測，有可能有誤解。可能還是要讀原
文免得被我誤導XD
※ 編輯: ripple0129 (223.140.224.5), 08/07/2016 19:47:06
推 brucetu: 我覺得就是用組合而不用繼承
推 CoNsTaR: 剛剛去看了你的網址 其實我覺得它只是在做 c++ 原本就在
→ CoNsTaR: 做的事而已…
→ CoNsTaR: Java is not my native language 覺得我亂講請見諒
→ CoNsTaR: interface 就像是在模擬 c++ 的 header 一樣
→ CoNsTaR: 我不懂 Java，但就我的認知，你一樣要在 interface 裡面
→ CoNsTaR: 宣告 prototype 才能 mixin 對應的實作是嗎@@
→ CoNsTaR: 如果是的話 那其實講白了不就只是原型實作分離 然後用比
→ CoNsTaR: 較酷炫的方式動態的合併？
→ CoNsTaR: 就算不需要在 interface 裡預先宣告好可能被 mixin 的東
→ CoNsTaR: 西的 prototype
→ CoNsTaR: 它其實也只是讓 Generic 的東西可以像 member 一樣被操作
→ CoNsTaR: 而已
→ CoNsTaR: 如果是這樣的話 c++ 的 friend 就是這個功用，只是需要在
→ CoNsTaR:  class 裡面宣告這個 Generic function 為 friend
→ CoNsTaR: 如果要說機動性，可以隨時 mixin 來用的話，interface
→ CoNsTaR:  的 extends 組合看樣子是固定的，c++ 則可以用 template
→ CoNsTaR:  編譯期動態決定繼承組合(police-based design)，也是一
→ CoNsTaR: 樣效果，而且 c++ 還比較滿足高聚合這點，低耦合則差不多
C++不熟，原生就支援多重繼承的語言能輕鬆做到相同效果不意外。對C++的使用者來說，
不過就是提供了另一種coding style的想法吧。除了ios android這類語言綁定的之外，
還真想不到有什麼是C++辦不到的XD。
※ 編輯: ripple0129 (223.140.224.5), 08/08/2016 04:25:06
→ CoNsTaR: 不是在比較 Java 和 c++，而是拿我比較熟悉的語言來看所
→ CoNsTaR: 謂的 COP 帶來了什麼特性
推 CoNsTaR: 看到你在 Java 版的文了 那這其實就是 C 語言 .h 宣告 .c
→ CoNsTaR:  實作的概念啊 XDD
推 CoNsTaR: 那這應該是不會成為未來語言的設計考量啦 (被毆 XDD
用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
推 CoNsTaR: Java 沒有原型這種東西 這裡就是用 interface 模擬原型，
→ CoNsTaR: class 實作
→ CoNsTaR: C 和 C++ 通常原型宣告在 header，實作定義在 source，
→ CoNsTaR: 我上面只是想表達這個而已
→ CoNsTaR: 如果你真的喜歡這樣的設計，推薦你鑽研 c++，它提的東西
→ CoNsTaR: 很多都和 c++ 預設風格不謀而合，不過它倒是給了這些平常
→ CoNsTaR: 在用的東西一個全新的解釋，原來還可以這樣解讀啊 XD