Perl代碼主要是面向對象設計嗎？

由於幾乎所有模塊都存在，所以我們反覆說我們不應該重新發明輪子，因爲我不爲CPAN編寫模塊，所以我不需要使用OO。但我的問題是，專業的Perl代碼主要是用OO風格編寫的嗎？Perl代碼主要是面向對象設計嗎？

2010-05-04 sid_com

我認爲「專業」在這裏非常主觀。也許使用例如小規模和大規模的例子來定義在這種情況下的每一個詞會更有意義。 – kbenson 2010-05-04 16:57:52

請記住選擇一個最佳答案。 – amphetamachine 2010-08-13 07:47:38

總之，只有你想要代碼可重用性和可讀性;爲了編寫簡單的系統腳本或代碼來執行一項任務，那麼這太浪費了，特別是如果這種事情不會被記錄在案。例如，編寫複雜的程序時，通過編寫一系列好的模塊，組織好自己的想法和模塊化問題確實有幫助。在使用多個開發人員的項目上工作時，使用面向對象的好處將呈指數增長。

來源

2010-05-04 13:21:40 amphetamachine

什麼是OO風格的蘊涵代碼可重用性和可讀性？ OO風格用於數據抽象和建模。它不能解決可讀性和/或可重用性問題。這是關於建築和設計。我看到很多糟糕的OO風格的代碼，它絕對不可讀，不可重複使用。使用面向對象進行數據抽象，建模和函數式功能是我的最佳建議。 OO風格對於C，Java，C＃等不良表達語言是必需的。 Perl不適用。 – 2010-05-04 15:49:00

@Hynek -Pichi- Vychodil我認爲OO技術提供的代碼的劃分是另一個使代碼更具表現力的工具，它增加了可讀性，可維護性和可重用性。如果表現力導致這些屬性在正確的手中，並且面向對象技術提供了表達性，那麼OO技術在正確使用時可以提供這些屬性。如果我還沒有足夠多的打擊所有人，這當然都取決於程序員。 – kbenson 2010-05-04 16:55:58

我寫的大多數Perl代碼都是小尺寸的腳本，我從不使用OOP，即使它們使用的是OOP設計的CPAN模塊。對於大型代碼項目，我傾向於大約70％的時間使用OOP，但這取決於：代碼是否會被使用很長時間？如果它可能繼續存在並且許多用戶將會在他們的組合中浸泡勺子，OOP可能是更好的設計。

來源

2010-05-04 13:24:08

OO-設計不是「銀彈」。編寫不是OO的代碼沒有什麼壞處。這只是「流行」的選擇。正如有人曾經說過（我意譯）：

OO-design simply had a better marketing group

這只是一個事實，即人們相信詞幹法「大多數代碼」應該是OO。當然，你可以跟蹤狀態「在一個對象內部」，但它也會讓人們在對象內部做一些愚蠢的事情，使事情變得更加複雜。

我的問題是「用OO編寫的大多數代碼」。我相信在物體和功能之間應該有一個健康的平衡。函數可以在對象上運行。

有很多東西不適合物體。

來源

2010-05-04 14:17:27 dlamotte

我不同意; OOP不只是一種不同的風格，它是一個根本不同的範例。對於複雜的體系結構，它可以在代碼的組織和可維護性方面產生很大的差異。 – 2010-05-04 14:23:04

是的面向對象的設計不是銀子彈，但說它只是有一個更好的營銷組意味着你錯過了。一些問題自然適用於OO解決方案。其他功能解決方案。這就是爲什麼Perl非常好，因爲你可以根據情況需要做或者兩者兼而有之。 – mpeters 2010-05-04 14:31:16

如果你正在編寫一個簡單的腳本來做一些相對簡單的處理，文件修改等，它可以去與非OO設計，但以我的經驗，如果你的腳本將會變得更長，並且可能做的事情您有一天可能希望在另一個腳本中使用，或者在與您計劃採用面向對象方法的最佳方式不同的環境中重用。總的來說，它更容易擴展和增強基於OO的設計。

特別是涉及到任何類型數據的表示。一旦你寫了一個類來表示這些數據，那麼爲這個數據類添加有用的方法（例如顯示，檢查，分析，重置，寫入文件，從文件加載等）非常方便。

這也有一個積極的副作用，使您的腳本更簡潔，易於閱讀和維護，因爲很多數據操作的細節都留給了類方法。如果你正在處理大量的數據，處理對象數組更容易，而不是使用哈希，如果你沒有OO設計，你可能會使用很多。

將來，如果您必須編寫腳本以不同方式處理相同數據，則可以簡單地在不同腳本中重用數據類。如果你的數據碰巧有點不同，那麼你需要添加更多的字段或更多的方法。沒問題簡單地擴展原始數據類。

學習OO Perl的最佳參考資料我發現的是：面向對象的Perl：由Damian Conway編寫的概念和編程技術綜合指南。我開始做OO Perl時遇到的一件事是，有很多不同的方法可以做到這一點。最終，我剛剛解決了這個問題，並且多年來一直堅持下去。

來源

2010-05-04 16:12:36 yahya

我看到OOP主要是作爲綁定行爲和設置數據結構的一種方式。任何時候，我的數據結構看起來會變得複雜，我編寫對象。

這有助於集中和抽象與操縱數據相關的代碼。這又減少了重複代碼並簡化了重構。使用純程序代碼可以達到同樣的目的。我發現面向對象使得這種關係更直觀，更容易以直觀的方式進行概念化。

考慮這樣的結構：

my $foo = { 
    meezle => [qw(a d g e l z)], 
    twill => { 
     prat => 'qua', 
     nolk => 'roo', 
    }, 
    chaw => 7, 
    mubb => [ 123, 423,756, 432 ], 
    ertet => 'geflet', 
};

當我風與這樣的（嵌套和非均勻的）一個結構，我開始思考「對象」。當我發現自己編寫大量代碼來訪問，修改和驗證結構中的數據時，我確定無疑。

由於大多數不平凡的項目都需要非平凡的數據操作，因此我至少在大部分作業的某些部分使用對象。

我可能會也可能不會在我的OOP中全力以赴。通常有幾件事情不是對象。可能有也可能沒有應用程序基類。一些元素可以作爲正常的程序代碼來處理。有些可能包括功能方法。這一切都取決於考慮到項目要求的有意義。

要記住的最重要的事情是，你的代碼必須清楚可憐的schmuck負責維護它。（這可能是你6個月內最早從凌晨4點起牀睡覺，老闆的老闆老闆在你公司破產之前尖叫着修復該死的軟件。）

來源

2010-05-04 17:04:21 daotoad

Perl代碼主要是面向對象設計嗎？

回答

相關問題