範式混合的粒度

Question

當使用諸如Python，C++，D或Ruby等多範式語言時，您在單個應用程序中混合了範例多少？在單個模塊內？你認爲以細粒度混合功能性，過程性和麪向對象的範例會產生更清晰，更簡潔的代碼，因爲你對每個子問題使用正確的工具，或者因爲你在做類似的事情有3種不同的方式？

Answer 1

不同的範例以不同的方式混合。例如，使用OOP不會消除來自外部庫的子例程和過程代碼的使用。它只是將程序移到不同的地方。

單純以一種範式編程是不可能的。當你編程時，你可能會認爲你有一個單一的想法，但那是你的幻想。您的結果代碼將沿着邊界落地並在許多範例的範圍內。

Answer 2

我不確定我是否曾經這樣想過。

一旦你開始「在Ruby中思考」，多範式就會融入...... Ruby。

Ruby是面向對象的，但我發現，其他的東西，如功能方面往往意味着目前存在的一些面嚮對象語言的「傳統」設計patters都只是單純的不相關的。迭代器是一個經典的例子...迭代是在Ruby中優雅地處理的東西，重量級的OO迭代模式不再適用。這在整個語言中似乎都是真實的。

Answer 3

混合模式的優勢在於讓您以最自然和最自然的方式表達解決方案。當它幫助保持你的程序邏輯更小時，這是非常好的事情。例如，與傳統循環相比，按照某些標準篩選列表比用功能性解決方案表達要簡單幾倍。另一方面，爲了從混合兩個或多個範例中獲益，程序員應該對所有這些範例合理流利。所以這是應該小心使用的強大工具。

Answer 4

不同的問題需要不同的解決方案，但如果您在同一圖層中以相同的方式解決問題，則會有所幫助。瘋狂地變化會混淆你和項目中的其他人。對於C++，我發現靜態類型的OOP（在Python中使用zope.interface）適用於更高級別的部分（連接，更新，信號等）和功能性的東西，可以解決許多較低級別的問題（解析，堅果'螺栓數據處理等）更好地。

通常，動態類型的腳本系統對於選擇和配置特定的應用程序，遊戲級別以及其他類型都是很好的選擇。這可能是語言本身（即Python）或其他東西（xml腳本引擎+ C++中的動態鏈接所必需的系統）。