2013-10-31 29 views
-3

所以我一直在建立一個應用程序一段時間,隨着時間的推移,我的一個類(一個UIViewController)已經變得相當大,做了很多東西與一個視圖。因此,我必須使其符合很多協議(現在有12個)。我現在開始擔心我符合一些太多。符合太多協議的類?

遵守一個類中的很多協議是否存在問題?會有性能問題或類似的情況嗎?我不是在尋找個人意見,而是在於可能出現的性能問題,或者是否違背了最佳實踐/風格指南文檔(例如Apple發佈的文檔)。

我的一些類符合協議(不包括一些自定義的協議)的:

UIAlertViewDelegate, UIActionSheetDelegate, MFMailComposeViewControllerDelegate, 
UITableViewDataSource, UITableViewDelegate, UITextFieldDelegate, 
UIPopoverControllerDelegate, UIBarPositioningDelegate, 
ABPeoplePickerNavigationControllerDelegate 

編輯: 正如一些答案指出,大部分協議都是UI相關 - 而且觀點本身並不混亂。 UIAlertViewDelegate,UIActionSheetDelegateMFMailComposeViewControllerDelegateABPeoplePickerNavigationControllerDelegate都單獨顯示(模態地在最後兩種情況下)。 UITableViewDataSourceUITableViewDelegate只是處理表格。 UITextFieldDelegate用於管理字段的搜索(以便讓我檢查輸入的文本是否「有效」)。外觀上,iOS7需要使用UIBarPositioningDelegate。 該類不是太大,只處理自己,沒有太多的耦合(至少在我看來)。

回答

-1

我不能告訴你關於性能,而無需實際看到的代碼,但它可能是,如果以某種方式在兩個或兩個以上的協議聲明同名方法(它發生在我身上),那麼你會得到意想不到的行爲,其中可能包括性能下降。假設兩個協議定義了一個基本方法,例如- (void)update,現在你只實現了一個更新方法,但是這兩個協議都希望使用它,所以充其量你需要調用更多的調用(性能下降)。如果其中一個協議將該方法定義爲@optional,那麼它並不總是立即顯而易見的。

我可以告訴你的是,這種單一設計被普遍認爲是差的。這聽起來像你有一個大的ball of mud正在進行。

+0

哇一個downvote說幾乎完全是什麼其他答案說:) –

+0

(我沒有downvote,但)我不認爲如果一個類聲明「意外行爲」或「多線程」將是一個問題符合許多協議。 –

+0

@MartinR感謝,這是有道理的,我想我不夠清楚,我的意思是如果兩個協議定義相同的方法,你可以看到問題。 –

1

從蘋果官方文檔:

提示:如果您發現自己採用的 類大量的協議,它可能是你需要重構一個過於複雜的 類的標誌通過將必要的行爲分成多個較小的類別,每個類別都有明確定義的職責。對於新的OS X和iOS開發人員而言,一個相對較爲常見的缺陷是使用單個應用程序委託類來包含應用程序的大部分功能(管理底層數據結構,爲多個用戶界面元素提供數據 ,以及響應以手勢 和其他用戶交互)。隨着複雜性的增加,類別 變得更難以維護。

所以,答案是在性能方面做得不錯,但這不是一個好的做法。

https://developer.apple.com/library/ios/documentation/cocoa/conceptual/ProgrammingWithObjectiveC/WorkingwithProtocols/WorkingwithProtocols.html

1

沒有罰中有一類符合的改變許多協議 - 除了微不足道的更高的編譯時間/空間(由於有該類更大編譯表,但是這的確是沒有意義的,國際海事組織)和可能的類可讀性問題。

確實,當你指定一個類符合一個協議時,你只是告訴編譯器將該協議內聲明的所有方法添加到類接口。這對性能或內存佔用幾乎沒有影響。

您遇到的主要問題是IMO有關班級可讀性。一般來說,如果你的班級提供了太多的公共方法,你就會遇到問題。這使得難以理解該課程是什麼。重構將被強烈建議,但是這與性能無關。

從粘貼的內容看來,您添加到類中的協議似乎與您在該類內部管理的UI元素相關。然後,您班級的視圖管理過於複雜,或者您需要這些代表。

1

編程的最佳實踐一般是儘可能分離關注點和功能。對我來說,它看起來像你的應用程序由一個擁擠的控制器組成。這是爲什麼?一個類或文件中的代碼過多會導致調試和維護變得更加困難,如果您擁有所有這些元素,則界面必須非常混亂。如果沒有看到更多的代碼,我不能給出具體的建議,但總的來說,在一個控制器中你有太多的東西。

0

我不認爲這會導致任何性能問題或錯誤。

但是看起來你的班級非常耦合,這是一個糟糕的設計實踐,但這並非必須如此,你班級的代碼行數是多少?

如果這很多,你認爲你班上做了一些工作,你不應該折騰你的代碼。