2012-04-17 62 views
5

今天我有一個想法,也許一些JavaScript老年人可以回答。Instanciating多個Mootools類的性能開銷

在Mootools中創建多個類時,估計的DOM開銷是多少?

良好的OO設計規定任何可重用的代碼位都應該放在類中。但是由於每個創建的mootools類都明確地繼承了「Class」,它當然會獲得很多額外的實例化。

所以我的 - 或多或少的哲學問題是,這會影響瀏覽器的性能,因爲所有代碼都是在onload上實例化的,例如在數組中使用數百或數千個類的DTO模式,簡單的物體。

笨重, 邁克爾

+0

什麼DOM開銷?一個類是一個對象,如果它不在DOM中創建任何東西,那麼足跡將不會去那裏。對象也通過引用傳遞,並且繼承不會從其他對象複製(除非「實現」,此時它將複製對象鍵)。你的用例是什麼?成千上萬的類似乎是一種反模式。最大的足跡將是創建/處理時間以及發生的所有方法包裝...請詳細說明您的需求 – 2012-04-17 11:32:32

+0

感謝您的評論。我想象的用例是將來自服務器的數據集映射到DTO對象。此列表可以是任意長度。所以我在想,不是有一個{}風格的對象數組,然後爲每個對象創建一個例如PostCodeDTO的實例,並將其放入數組中。基本上使用屬性mixin for Class將返回項目包裝在DTO對象中,並用getter和setter創建探測器DTO等。 – 2012-04-17 11:45:40

+0

聽起來像您可以採用[shipyard]之類的東西(https://github.com/seanmonstar/船廠)或[神經](https://github.com/GCheung55/Neuro),甚至Ember或Backbone - 一個模型 - >集合結構,只需定義你的模型,然後讓它們在任何目的的集合和收穫事件中處理/ view。 – 2012-04-17 13:39:09

回答

1

權。這是我如何看到這一點。首先,從@keeto報價:

保持優雅

'最後一部分是很重要的。雖然類是實現模塊化代碼的好方法,但它們並不是唯一的方法。我發現現在有些開發人員使用類來處理所有事情是一種令人不快的傾向。就像衆所周知的錘子一樣,每個編碼都會使用類,這是不幸的,因爲不是所有的東西都應該是類。

類適用於創建可跨項目使用的可重用代碼,我個人堅持這一標準。除非我確定我正在構建的東西會被多次使用,否則我不會把它變成一個班級。如果你沒有注意到,你可以使用MooTools而不必定義一個自定義類。畢竟,只是因爲MooTools有類並不意味着你將不得不用JavaScript代碼,就像它的Java。 *「」


來源:http://keetology.com/blog/2010/10/01/modules-and-callbacks-going-hollywood-with-mootools

這是非常主觀的,因爲它在很大程度上取決於你如何編寫類和JavaScript一般。

使用類不是沒有懲罰和開銷。取決於您實例化的類的類型,這將有所不同。例如,如果您的類是一個簡單的數據抽象,不會觸及其他對象或輸出到DOM,那麼創建實例相對便宜。成本將圍繞處理選項對象和(有時)將屬性複製到實例構造函數中。

在類定義本身,MooTools的做遍歷所有構造函數對象的屬性,並試圖處理所有的特殊的人與存取器(例如,initializeImplementsExtendsbinds(從 - 更多)等)。雖然這是一次性的。一旦創建了構造函數,就可以快速使用它。

它也會做別的事情 - 它會包裝所有具有函數值的屬性,以便您可以將它們裝飾爲私有的(通過當前API中的.protect()),因此您運行的任何函數都會被粘貼。此外,您經常傾向於使用.bind()作爲方法裝飾器,這意味着運行實際代碼的2個包裝器。

你的課程越複雜(從不同的課程原型擴展和實施),創建課程實例所涉及的工作就越多。實際上,你需要創建一個絕對怪物來開始將其視爲內存分配以外的任何內容(啓動或垃圾收集時的延遲)。當然,構造函數中cpu-heavy或異步/阻塞的東西也不會很好,如果你做了很多...

事件,事件監聽器等也可以疊加起來。 保存對象的引用會隨着時間的推移而堆積起來。

然後,有綁定到DOM元素,添加事件,監聽事件,輸出自己的事件類...

把它放在一起,它可以變得有些昂貴。您正在創建從許多地方繼承(希望通過原型鏈參考)的對象。即使如此,您的類構造函數本身的定義也很快,直到您創建1000個實例纔會開始變得有趣,並將現代瀏覽器引入測試。