2.1 組件定位：精準地解決共性問題

組件來源于軟件工程實踐中，是對重復、反復出現、普遍的、有相似性的問題進行分析，剝離掉各個問題的特性，而提取各個問題之間的共性。此共性就確定了組件要解決的問題。如果不是共性的問題，那么寫完后的代碼就只能在一種或有限的幾種情況下才能被使用，就無法實現大規模復用。不能廣泛地復用，就不能被叫做組件。

因此，組件首先是業務驅動的，不是技術驅動的。不能因為我們有了新的技術，就想著要寫幾個新的組件。

共性的業務問題，是組件的產生來源。

另外，即使確定了要解決的共性問題，組件也還必須提供解決問題最合理、最有效的方式和方法。如果提供的方法不是最好的，那么也很難得到使用者的喜愛，最終也難以推廣和復用。因此，組件設計上，必須提供解決問題的精準思路和方案。這是決定同類別的組件中，哪個組件能勝出的最主要原因。

一個組件提供的問題解決方法，是否最有效，主要評價原則如下：

1.技術與業務對齊

技術結構和技術概念要與業務上的模型、概念保持一致，在組件對外暴露的接口上，最好不要引入新的技術術語和概念，這樣的組件最吻合業務的需求，也最容易理解。

技術與業務對齊，這是組件設計的第一位重要原則。

2.技術方案的優勢

這是結構設計、技術選型范疇內要考慮的問題。實現同一個功能，可以有很多不同的結構設計，也可以采用很多不同的技術。優秀的組件，一定要在技術方案上有明顯的技術優勢。

3.接口簡單

組件暴露出來供外界使用的接口，必須足夠簡單。在概念和模型層面上與業務保持一致，另外接口封裝、抽象上要仔細推敲，保證接口提供給別人使用時，調用者足夠簡單地使用。

4.功能強大

組件如果提供的功能太少，意味著能幫用戶解決的問題比較少，這樣的組件實用性大打折扣。而如果組件的功能過多，就會讓用戶覺得這個組件非常臃腫和龐大，用戶只用了其中一小部分功能，其他大部分功能都用不上或者很少用，這樣用戶要在一本厚厚的使用手冊中，仔細尋找自己需要的部分，去除自己不需要的部分，這也算不上一個優秀的組件。因此，一個組件提供的功能，既要能滿足多種場景下不同客戶的需求，還要在不同的需求中進行取舍和合并，使提供的功能集不會超出客戶實際使用需求太多。