單一職責原則

A. 結構化設計方法強調高內聚低耦合，OO強調類的責任單一，這些設計原則共同追求的NFR 是什麼

網路粘過來的，你看看：
基本解釋
高內聚低耦合，是軟體工程中的概念，是判斷設計好壞的標准，主要是面向對象的設計，主要是看類的內聚性是否高，耦合度是否低。
高內聚
內聚就是一個模塊內各個元素彼此結合的緊密程度，高內聚就是一個模塊內各個元素彼此結合的緊密程度高。 所謂高內聚是指一個軟體模塊是由相關性很強的代碼組成，只負責一項任務，也就是常說的單一責任原則。
低耦合
耦合：一個軟體結構內不同模塊之間互連程度的度量(耦合性也叫塊間聯系。指軟體系統結構中各模塊間相互聯系緊密程度的一種度量。模塊之間聯系越緊密，其耦合性就越強，模塊的獨立性則越差，模塊間耦合的高低取決於模塊間介面的復雜性，調用的方式以及傳遞的信息。) 對於低耦合，粗淺的理解是： 一個完整的系統，模塊與模塊之間，盡可能的使其獨立存在。 也就是說，讓每個模塊，盡可能的獨立完成某個特定的子功能。 模塊與模塊之間的介面，盡量的少而簡單。 如果某兩個模塊間的關系比較復雜的話，最好首先考慮進一步的模塊劃分。 這樣有利於修改和組合。[1]
編輯本段為什麼要追求高內聚和低耦合
軟體架構設計的目的簡單說就是在保持軟體內在聯系的前提下，分解軟體系統，降低軟體系統開發的復雜性，而分解軟體系統的基本方法無外乎分層和分割。但是在保持軟體內在聯系的前提下，如何分層分割系統，分層分割到什麼樣的粒度，並不是一件容易的事，這方面有各種各樣的分解方法，比如：關注點分離，面向方面，面向對象，面向介面，面向服務，依賴注入，以及各種各樣的設計原則等，而所有這些方法都基於高內聚，低耦合的原則。 高內聚和低耦合是相互矛盾的，分解粒度越粗的系統耦合性越低，分解粒度越細的系統內聚性越高，過度低耦合的軟體系統，軟體模塊內部不可能高內聚，而過度高內聚的軟體模塊之間必然是高度依賴的，因此如何兼顧高內聚和低耦合是軟體架構師功力的體現。 高內聚，低耦合的系統有什麼好處呢？事實上，短期來看，並沒有很明顯的好處，甚至短期內會影響系統的開發進度，因為高內聚，低耦合的系統對開發設計人員提出了更高的要求。高內聚，低耦合的好處體現在系統持續發展的過程中，高內聚，低耦合的系統具有更好的重用性，維護性，擴展性，可以更高效的完成系統的維護開發，持續的支持業務的發展，而不會成為業務發展的障礙。[2]

B. PHP面向對象編程——單一職責原則（SRP）是什麼

簡單的模板引擎來說明一下PHP面向對象編程中單一職責原則的應用和作用
原文地址： http://www.chhua.com/web-note1121

C. ocp原則蘊含了單一職責原則 嗎

單一職責原則
對於單一職責原則，其核心思想為：一個類，最好只做一件事，只有一個引起它的變化。單一職責原則可以看做是低耦合、高內聚在面向對象原則上的引申，將職責定義為引起變化的原因，以提高內聚性來減少引起變化的原因。職責過多，可能引起它變化的原因就越多，這將導致職責依賴，相互之間就產生影響，從而大大損傷其內聚性和耦合度。通常意義下的單一職責，就是指只有一種單一功能，不要為類實現過多的功能點，以保證實體只有一個引起它變化的原因。
專注，是一個人優良的品質；同樣的，單一也是一個類的優良設計。交雜不清的職責將使得代碼看起來特別別扭牽一發而動全身，有失美感和必然導致醜陋的系統錯誤風險。

D. Java 設計模式，「單一職責原則」中說「每一個類只負責一項任務」。那麼...

一些小職責可以用內部類，static class A{} ,源文件不須太多
設計也是對已經存在的問題進行分類，而不在抽象上做不實際的細分吧..
至於類多，可以參考一派的觀點OOP是有殘疾的，純OO經常導致畫蛇添足...代碼量翻倍
退回到過程和對象混用...盡量少分類，多用函數式純函數，
現在的python就持這類理念

E. 《單一職責准則》與《介面隔離原則》有什麼區別

介面隔離原則表明客戶端不應該被強迫實現一些他們不會使用的介面，應該把胖介面中的方法分組，然後用多個介面代替它，每個介面服務於一個子模塊。
介面隔離原則
不應該強迫客戶端依賴於他們不會使用的介面。
實例
下面是一個違反了介面隔離原則的例子。我們使用Manager類代表一個管理工人的管理者。有兩種類型的工人：普通的和高效的，這兩種工人都需要吃午飯。現在來了一批機器人，它們同樣為公司工作，但是他們不需要吃午飯。一方面Robot類需要實現IWoker介面，因為他們要工作，另一方面，它們又不需要實現IWorker介面，因為它們不需要吃飯。
在這種情況下IWorker就被認為是一個被污染了的介面。
如果我們保持現在的設計，那麼Robot類將被迫實現eat()方法，我們可以寫一個啞類它什麼也不做（比如說它只用一秒鍾的時間吃午飯），但是這會對程序造成不可預料的結果（例如管理者看到的報表中顯示被帶走的午餐多於實際的人數）。
根據介面隔離原則，一個靈活的設計不應該包含被污染的介面。對於我們的例子來說，我們應該把IWorker分離成2個介面。
3. interface IWorker {
4. public void work();
5.
6. public void eat();
7. }
8.
9. class Worker implements IWorker {
10. public void work() {
11. // ....working
12. }
13.
14. public void eat() {
15. // ...... eating in launch break
16. }
17. }
18.
19. class SuperWorker implements IWorker{
20. public void work() {
21. //.... working much more
22. }
23.
24. public void eat() {
25. //.... eating in launch break
26. }
27. }
28.
29. class Manager {
30. IWorker worker;
31.
32. public void setWorker(IWorker w) {
33. worker=w;
34. }
35.
36. public void manage() {
37. worker.work();
38. }
39. }

// interface segregation principle - bad example
interface IWorker {
public void work();
public void eat();
}
class Worker implements IWorker {
public void work() {
// ....working
}
public void eat() {
// ...... eating in launch break
}
}
class SuperWorker implements IWorker{
public void work() {
//.... working much more
}
public void eat() {
//.... eating in launch break
}
}
class Manager {
IWorker worker;
public void setWorker(IWorker w) {
worker=w;
}
public void manage() {
worker.work();
}
}

下面是遵循介面隔離原則的代碼。通過把IWorker分離成兩個介面，Robot類不需要再被強迫實現eat()方法。如果我們需要為Robot類添加其他的功能，例如重新充電，我們可以創建一個新的IRechargeable介面，其中包含一個重新充電的方法recharge。
Java代碼 復制代碼

1. //interface segregation principle - good example
2.
3. interface IWorkable {
4. public void work();
5. }
6.
7. interface IFeedable{
8. public void eat();
9. }
10.
11. class Worker implements IWorkable, IFeedable {
12. public void work() {
13. // ....working
14. }
15.
16. public void eat() {
17. //.... eating in launch break
18. }
19. }
20.
21. class SuperWorker implements IWorkable, IFeedable{
22. public void work() {
23. //.... working much more
24. }
25.
26. public void eat() {
27. //.... eating in launch break
28. }
29. }
30.
31. class Robot implements IWorkable{
32. public void work() {
33. // ....working
34. }
35. }
36.
37. class Manager {
38. IWorkable worker;
39.
40. public void setWorker(IWorkable w) {
41. worker = w;
42. }
43.
44. public void manage() {
45. worker.work();
46. }
47. }

//interface segregation principle - good example
interface IWorkable {
public void work();
}
interface IFeedable{
public void eat();
}
class Worker implements IWorkable, IFeedable {
public void work() {
// ....working
}
public void eat() {
//.... eating in launch break
}
}
class SuperWorker implements IWorkable, IFeedable{
public void work() {
//.... working much more
}
public void eat() {
//.... eating in launch break
}
}
class Robot implements IWorkable{
public void work() {
// ....working
}
}
class Manager {
IWorkable worker;
public void setWorker(IWorkable w) {
worker = w;
}
public void manage() {
worker.work();
}
}

總結
如果已經設計成了胖介面，可以使用適配器模式隔離它。
像其他設計原則一樣，介面隔離原則需要額外的時間和努力，並且會增加代碼的復雜性，但是可以產生更靈活的設計。如果我們過度的使用它將會產生大量的包含單一方法的介面，所以需要根據經驗並且識別出那些將來需要擴展的代碼來使用它。