代碼耦合度
❶ 怎樣降低iOS代碼耦合性
凡是維護過中型項目的iOS工程師都應該有過類似的體驗：ViewController代碼繁重、功能復雜、維護困難，整個工程寥寥幾個就完成了整個項目的開發。每個控制器中都囊括了所有的頁面布局、委託代理、網路請求、資料庫操作和核心功能，這樣的代碼往往問題重重，修改起來牽一發而動全身，著實令人頭疼。
為了應對這一系列的問題，蘋果公司的工程師給我們提供了很多選擇去更好的在項目工程中貫徹MVC的設計理念，例如使用從前的Interface Builder製作xib可視布局，現在已經內置到xcode裡面，並且提供了更為強大Storyboard功能，來減少控制器中的頁面樣式布局代碼量；再例如NSFetchedResultsController這樣的類和的完美結合，大大減少類似構架項目的代碼量，並且穩定高效。
這些技巧在objc.io上有一個專門的專題，推薦給大家對應中文站objc中國，感謝objc 中國項目組。
Storyboard與代碼耦合性
如果放在兩年前去討論iOS工程要不要使用Stortboard進行布局，我們可能還會猶豫一下，很多iOS程序猿內心會有一種想把一切化為代碼掌控在手中的想法，選擇拒絕使用Storyboard或者更早的xib。但事到如今，iPhone、iPad的屏幕尺寸越來越多，工程里為了適配不同屏幕冗餘代碼越來越長的時候，Storyboard似乎成為了我們必須同時也是蘋果公司在引導我們將要實踐的方向。
從iOS 6中的Autolayout到iOS 8中的Size Class，新技術的涌現正是為了應對更復雜的布局任務。有人可能會反駁說，自動布局也可以用純代碼完成呀。你說的沒錯，純代碼是可以完成，但其復雜程度遠遠不是重寫Frame這么簡單了，更靈活地將Storyboard和代碼結合，才是比較完備的解決方案。
這里通過三個方面介紹通過使用Storyboard減小工程代碼耦合性的途徑：
•IBDesignable和IBInspectable
•預覽Storyboard Preview
•NSObject和Runtime Attributes
IBDesignable和IBInspectable
IBDesignable和IBInspectable的出現為Storyboard提供了可視化使用高度自定義控制項的方法，例子中我們在製作一個雙行標簽控制項，用來顯示日期和星期，命名為DateLabel，使用方法如下：
?12345678 //IB_DESIGNABLE 標記 IB_DESIGNABLE @interface DateLabel : UIView //IBInspectable 標記 @property (nonatomic, strong) IBInspectable NSString* dateLabelText; @property (nonatomic, strong) IBInspectable NSString* weekLabelText; @end
其中，IB_DESIGNABLE標記賦予我們的繼承類DateLabel可以在界面編輯器裡面實時渲染的特權。IBInspectable則賦予讓界面編輯器可以設置或者預置View的參數dateLabelText和weekLabelText。具體不多介紹了，有點跑題，大家可以參見如何在iOS 8中使用Swift和Xcode 6製作精美的UI組件，同樣適用於Objective-C和Swift。
引用上文介IBInspectable支持Int,CGFloat,Double,String,Bool,CGPoint,CGSize,
CGRect,UIColor,UIImage等類型的變數。
現在在Github上已經有一部分開源的UI控制項使用了這項特性，如此一來，很多需要在代碼中實現的控制項自定義特性，都可以在Storyboard中完成，後者的優勢也很明顯：
1.所見即所得
2.剝離了ViewController中的定製View代碼，減小耦合
預覽Storyboard Preview
Storybord中提供了預覽功能，可以預覽其界面在各個尺寸設備上的真實顯示效果。詳見Xcode 6中學習Swift、CloudKit 和 Testflight，搜索Storyboard Preview。
NSObject和Runtime Attributes
大家對這個概念再熟悉不過了，但大家有沒有對他作為一個沒有界面的控制項在Storyboard作用產生過疑問呢。先來看下這篇文章 0代碼ViewController的前言。
Storyboard中的NSObject可以是UITableView的DataSource,也可以是MapView的Delegate，連線一下，就能將原本在ViewController中寫得最多的代理方法全部移出，並且，當你需要的時候，這些現成的代理方法，可以直接移到其他的項目中使用。
Runtime Attributes功能則可以在Storyboard中給參數寫好初始值，但這里如果控制項沒有對應的參數的話，則會出現下面的報錯。
Failed to set (xxx) user defined inspected property on (xxx): [ setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key xxx.
Storyboard小結
當你了解了Storyboard的基本原理，就會發現Storyboard是一個很好用的工具，是Model-View-Controller模型中Controller跳轉邏輯和View初始化的實用載體，從根本上把Controller中的導航代碼移出，把頁面配置代碼、觸摸事件甚至協議委託方法分攤到其他實例中，各個類各司其職，整個項目的邏輯也變的更加清晰、更易維護。
❷ 高內聚、低耦合的含義是什麼如何提高代碼的可重用性
網路粘過來的，你看看：
基本解釋
高內聚低耦合，是軟體工程中的概念，是判斷設計好壞的標准，主要是面向對象的設計，主要是看類的內聚性是否高，耦合度是否低。
高內聚
內聚就是一個模塊內各個元素彼此結合的緊密程度，高內聚就是一個模塊內各個元素彼此結合的緊密程度高。 所謂高內聚是指一個軟體模塊是由相關性很強的代碼組成，只負責一項任務，也就是常說的單一責任原則。
低耦合
耦合：一個軟體結構內不同模塊之間互連程度的度量(耦合性也叫塊間聯系。指軟體系統結構中各模塊間相互聯系緊密程度的一種度量。模塊之間聯系越緊密，其耦合性就越強，模塊的獨立性則越差，模塊間耦合的高低取決於模塊間介面的復雜性，調用的方式以及傳遞的信息。) 對於低耦合，粗淺的理解是： 一個完整的系統，模塊與模塊之間，盡可能的使其獨立存在。 也就是說，讓每個模塊，盡可能的獨立完成某個特定的子功能。 模塊與模塊之間的介面，盡量的少而簡單。 如果某兩個模塊間的關系比較復雜的話，最好首先考慮進一步的模塊劃分。 這樣有利於修改和組合。[1]
編輯本段為什麼要追求高內聚和低耦合
軟體架構設計的目的簡單說就是在保持軟體內在聯系的前提下，分解軟體系統，降低軟體系統開發的復雜性，而分解軟體系統的基本方法無外乎分層和分割。但是在保持軟體內在聯系的前提下，如何分層分割系統，分層分割到什麼樣的粒度，並不是一件容易的事，這方面有各種各樣的分解方法，比如：關注點分離，面向方面，面向對象，面向介面，面向服務，依賴注入，以及各種各樣的設計原則等，而所有這些方法都基於高內聚，低耦合的原則。 高內聚和低耦合是相互矛盾的，分解粒度越粗的系統耦合性越低，分解粒度越細的系統內聚性越高，過度低耦合的軟體系統，軟體模塊內部不可能高內聚，而過度高內聚的軟體模塊之間必然是高度依賴的，因此如何兼顧高內聚和低耦合是軟體架構師功力的體現。 高內聚，低耦合的系統有什麼好處呢？事實上，短期來看，並沒有很明顯的好處，甚至短期內會影響系統的開發進度，因為高內聚，低耦合的系統對開發設計人員提出了更高的要求。高內聚，低耦合的好處體現在系統持續發展的過程中，高內聚，低耦合的系統具有更好的重用性，維護性，擴展性，可以更高效的完成系統的維護開發，持續的支持業務的發展，而不會成為業務發展的障礙。[2]
❸ 有關c語言的問題:什麼是模塊的內聚程度和耦合程度(希望能得到詳解)
對於開發者而言，耦合原則表示程序中單個的模塊應該盡可能的獨立。
處理一個模塊時，不應該依賴另一個模塊的內部工作。
內聚原則是指，在一個給定的模塊內部，所有的代碼應該只完成一個單個的目標。
IT界有一句很著名的口號：強內聚、松耦合。
即使是最初級的程序員，在常常的被教導中，他也了解了這句口號的含義：我們的程序要模塊化，模塊要完成明確的一組關聯的服務功能，要求它的各部分是相關的、有機組合起來是完整體（外部程序來看黑盒子），模塊的內部各成分之間相關聯程度要盡可能高（強內聚）；而模塊與模塊之間又要求是可分拆的、少依賴的（松耦合）。
人們易於實現強內聚的模塊，例如：一個函數實現一個獨立的功能，這就是強內聚。
人們不易實現松耦合，因為，孤獨的模塊毫無意義，只有模塊間的相互協調地工作，才能實現系統的目的。而對於模塊間的相互關系的設計，沒有一定的經驗是難以把握。耦合的強度依賴於：（1）一個模塊對另一個模塊的調用；（2）一個模塊向另一個模塊傳遞的數據量；（3）一個模塊施加到另一個模塊的控制的多少；（4）模塊之間介面的復雜程度。等等。
當然，「強內聚、松耦合」也是有矛盾的，如：內聚性越強，則要求的函數越多（每個函數只作一件「事」），這樣，將它們組合成「大」的功能，也就越復雜，就不可能達到松耦合。因此，應在二者之間作出平衡與折衷的選擇，這也體現程序員的水平。從系統論的角度來看，系統是有層次的，即系統可以分為子系統，模塊可分為子模塊，「強內聚、松耦合」的「度」的把握，應結合系統的次層性來考慮，即通常應在層次性上作出折衷，如：模塊內子程序（下一個層次上）應共享數據（有一定的耦合度），而減少全局變數能降低子程序性間的耦合性。
面向對象的語言進一步強化了「強內聚、松耦合」，類的封裝性既強調了相關內容（數據及其操作）的內聚，又強調了類的獨立性和私密性。而類的繼承性以及友元等，就是在松耦合的原則下規范了類之間的關聯關系。類與類之間通常通過介面的契約實現服務提供者/服務請求者模式，這就是典型的松耦合。
「強內聚、松耦合」對於程序編寫分工、程序的可維護性以及測試都有重要的關系，如：從設計角度來看，在「強內聚、松耦合」的指導下進行的設計得到的程序模塊，符合項目管理的WBS（工作分解結構）的要求，其相對獨立的模塊可以分配到具體的程序員進行開發，另外，程序編碼外包也必須建立在這種原則的設計之下；從程序生命期角度來看，它有利於提高程序質量，特別是方便於程序的日後維護，即程序模塊的相對獨立性是可維護性的保證；再從測試角度來看，符合「強內聚、松耦合」的程序，易於對局部（模塊）進行黑盒測試，也易於編寫測試用的「樁」和「驅動」。
「強內聚、松耦合」也是對組織結構的要求，項目組分為幾個小組（正式的或非正式的），各小組的工作應是高度相關的，各小組之間的工作應盡量是較少相關或有明確的介面，從而減少溝通成本。其實，「強內聚、松耦合」是系統中應遵守的普遍原則，我們在許多領域都可以找到它的應用。
「強內聚、松耦合」是我們不得不念的「三字經」，我們一定要念好它。
❹ java程序的耦合度是什麼
程序的耦合度是 你的子程序之間的相關聯性,也就是說你的多個類的聯系 是否版太緊密，打個比權方，你房子里邊有窗子 ，那房子 和窗子 就有了關聯
耦合度 是松還是緊 就看你的 關聯 是強還是弱，也就是修改的代價，比如 你窗子是扣死在牆里的 那麼你修改窗子 就必須修改牆 這就比較緊密了，但是如果你窗子是按照某種規格的 可以自由拆裝的 那麼修改的代價就小，耦合度也就低了
我們寫程序的目標就是 高內聚 低耦合！
這樣修改起來 就不會有太多的聯系 不用 改一個地方 其他的都要修改
❺ c語言中耦合度、內聚度、復雜度、數據傳輸特性相關含義
盡可能的獨立。
處理一個模塊時，不應該依賴另一個模塊的內部工作。
內聚原則是指，在一個給定的模塊內部，所有的代碼應該只完成一個單個的目標。
IT界有一句很著名的口號：強內聚、松耦合。
即使是最初級的程序員，在常常的被教導中，他也了解了這句口號的含義：我們的程序要模塊化，模塊要完成明確的一組關聯的服務功能，要求它的各部分是相關的、有機組合起來是完整體（外部程序來看黑盒子），模塊的內部各成分之間相關聯程度要盡可能高（強內聚）；而模塊與模塊之間又要求是可分拆的、少依賴的（松耦合）。
人們易於實現強內聚的模塊，例如：一個函數實現一個獨立的功能，這就是強內聚。
人們不易實現松耦合，因為，孤獨的模塊毫無意義，只有模塊間的相互協調地工作，才能實現系統的目的。而對於模塊間的相互關系的設計，沒有一定的經驗是難以把握。耦合的強度依賴於：（1）一個模塊對另一個模塊的調用；（2）一個模塊向另一個模塊傳遞的數據量；（3）一個模塊施加到另一個模塊的控制的多少；（4）模塊之間介面的復雜程度。等等。
當然，「強內聚、松耦合」也是有矛盾的，如：內聚性越強，則要求的函數越多（每個函數只作一件「事」），這樣，將它們組合成「大」的功能，也就越復雜，就不可能達到松耦合。因此，應在二者之間作出平衡與折衷的選擇，這也體現程序員的水平。從系統論的角度來看，系統是有層次的，即系統可以分為子系統，模塊可分為子模塊，「強內聚、松耦合」的「度」的把握，應結合系統的次層性來考慮，即通常應在層次性上作出折衷，如：模塊內子程序（下一個層次上）應共享數據（有一定的耦合度），而減少全局變數能降低子程序性間的耦合性。
面向對象的語言進一步強化了「強內聚、松耦合」，類的封裝性既強調了相關內容（數據及其操作）的內聚，又強調了類的獨立性和私密性。而類的繼承性以及友元等，就是在松耦合的原則下規范了類之間的關聯關系。類與類之間通常通過介面的契約實現服務提供者/服務請求者模式，這就是典型的松耦合。
「強內聚、松耦合」對於程序編寫分工、程序的可維護性以及測試都有重要的關系，如：從設計角度來看，在「強內聚、松耦合」的指導下進行的設計得到的程序模塊，符合項目管理的WBS（工作分解結構）的要求，其相對獨立的模塊可以分配到具體的程序員進行開發，另外，程序編碼外包也必須建立在這種原則的設計之下；從程序生命期角度來看，它有利於提高程序質量，特別是方便於程序的日後維護，即程序模塊的相對獨立性是可維護性的保證；再從測試角度來看，符合「強內聚、松耦合」的程序，易於對局部（模塊）進行黑盒測試，也易於編寫測試用的「樁」和「驅動」。
「強內聚、松耦合」也是對組織結構的要求，項目組分為幾個小組（正式的或非正式的），各小組的工作應是高度相關的，各小組之間的工作應盡量是較少相關或有明確的介面，從而減少溝通成本。其實，「強內聚、松耦合」是系統中應遵守的普遍原則，我們在許多領域都可以找到它的應用。
「強內聚、松耦合」是我們不得不念的「三字經」，我們一定要念好它。
❻ 代碼太過耦合 後期編碼擴展是什麼意思
代碼太過耦合就是說代碼的緊密性太強，軟體工程規定寫代碼的原則是「高內聚，低耦合」，低耦合的模塊便於進行單元測試，且便於維護。
簡單點說就像所有的模塊聯系過於密切，改一個地方也要把其他的模塊都要進行修改，在後期進行編碼擴展時候修改一個地方往往要改全局所有的地方，非常會耗時耗力，所以，編碼最好能夠"高內聚，低耦合"，這樣添加新的功能或修改一個變數不用修改全局所有模塊、能夠利於後期擴展功能，測試，維護等。
耦合性也叫塊間聯系。指軟體系統結構中各模塊間相互聯系緊密程度的一種度量。模塊之間聯系越緊密，其耦合性就越強，模塊之間越獨立則越差，模塊間耦合的高低取決於模塊間介面的復雜性，調用的方式以及傳遞的信息。
❼ 在JAVA編程中什麼叫耦合
耦合性是編程中的一個判斷代碼模塊構成質量的屬性，不影響已有功能，但影響未來拓展，與之對應的是內聚性。
耦合性：也稱塊間聯系。指軟體系統結構中各模塊間相互聯系緊密程度的一種度量。模塊之間聯系越緊密，其耦合性就越強，模塊的獨立性則越差。模塊間耦合高低取決於模塊間介面的復雜性、調用的方式及傳遞的信息。
內聚性：又稱塊內聯系。指模塊的功能強度的度量，即一個模塊內部各個元素彼此結合的緊密程度的度量。若一個模塊內各元素（語名之間、程序段之間）聯系的越緊密，則它的內聚性就越高。
因此，現代程序講究高內聚低耦合，即將功能內聚在同一模塊，模塊與模塊間盡可能獨立，互相依賴低。沒有絕對沒有耦合的模塊組，只有盡量降低互相之間的影響。使模塊越獨立越好。
❽ 計算機編程語言中的耦合是什麼意思
軟體工程中耦合
簡單地說，軟體工程中對象之間的耦合度就是對象之間的依賴性。指導使用和維護對象的主要問題是對象之間的多重依賴性。對象之間的耦合越高，維護成本越高。因此對象的設計應使類和構件之間的耦合最小。
有軟硬體之間的耦合，還有軟體各模塊之間的耦合。
耦合性是程序結構中各個模塊之間相互關聯的度量。它取決於各個模塊之間的介面的復雜程度、調用模塊的方式以及哪些信息通過介面。
耦合可以分為以下幾種，它們之間的耦合度由高到低排列如下：
（1） 內容耦合。當一個模塊直接修改或操作另一個模塊的數據時，或一個模塊不通過不正常入口而轉入另一個模塊時，這樣的耦合被稱為內容耦合。內容耦合是最高程度的耦合，應該避免使用之。
（2） 公共耦合。兩個或兩個以上的模塊共同引用一個全局數據項，這種耦合被稱為公共耦合。在具有大量公共耦合的結構中，確定究竟是哪個模塊給全局變數賦了一個特定的值是十分困難的。
（3） 外部耦合 。一組模塊都訪問同一全局簡單變數而不是同一全局數據結構，而且不是通過參數表傳遞該全局變數的信息，則稱之為外部耦合。
（4） 控制耦合 。一個模塊通過介面向另一個模塊傳遞一個控制信號，接受信號的模塊根據信號值而進行適當的動作，這種耦合被稱為控制耦合。
（5） 標記耦合 。若一個模塊A通過介面向兩個模塊B和C傳遞一個公共參數，那麼稱模塊B和C之間存在一個標記耦合。
（6） 數據耦合。模塊之間通過參數來傳遞數據，那麼被稱為數據耦合。數據耦合和最低的一種耦合形式，系統中一般都存在這種類型的耦合，因為為了完成一些有意義的功能，往往需要將某些模塊的輸出數據作為另一些模塊的輸入數據。
（7） 非直接耦合 。兩個模塊之間沒有直接關系，它們之間的聯系完全是通過主模塊的控制和調用來實現的
總結：耦合是影響軟體復雜程度和設計質量的一個重要因素，在設計上我們應採用以下原則：如果模塊間必須存在耦合，就盡量使用數據耦合，少用控制耦合，限制公共耦合的范圍，盡量避免使用內容耦合。
e...,我猜測你所說的「計算機編程語言中的耦合」指的應該就是「如何在計算機編程時處理耦合」，那就是上面所說的了。否則，。。偶也不曉得啦
❾ 程序設計中耦合性高有什麼壞處
當然耦合度高不好了。耦合性：也稱塊間聯系。指軟體系統結構中各模塊間專相互聯系緊密程度屬的一種度量。模塊之間聯系越緊密，其耦合性就越強，模塊的獨立性則越差。模塊間耦合高低取決於模塊間介面的復雜性、調用的方式及傳遞的信息。
❿ java中的代碼冗餘和耦合有什麼區別請詳細舉例，謝謝
比如說兩段代碼抄A,B執行襲不同的功能，但是這兩段代碼裡面需要用到相同的另一端代碼C，如果A,B都要寫C就顯得麻煩，這時候就把C提取出來作為單獨的部分調用這樣就不顯得冗餘，因為只要寫一遍，而前者要寫兩遍。耦合的話就是我定義A,B兩個類（不是代碼），但是B類裡面的方法要用到A，比如要new一個A的對象，這樣兩個類就耦合了
望點贊