Tiny框架在設(shè)計(jì)時(shí)充分考慮此原則，凡是可以通過(guò)一定的約定來(lái)大大減少配置或開(kāi)發(fā)量的，一般都會(huì)采用。所以在Tiny框架的擴(kuò)展、開(kāi)發(fā)、配置過(guò)程中，會(huì)經(jīng)常發(fā)現(xiàn)一些“潛規(guī)則”，如果利用好這些“潛規(guī)則”，會(huì)起起事半功倍的效果。無(wú)標(biāo)簽評(píng)論用戶(hù)圖標(biāo): cskang蔡少康發(fā)表：Convention over Configuration（CoC）–慣例優(yōu)于配置原則簡(jiǎn)單點(diǎn)說(shuō)，就是將一些公認(rèn)的配置方式和信息作為內(nèi)部缺省的規(guī)則來(lái)使用。例如，Hibernate的映射文件，如果約定字段名和類(lèi)屬性一致的話(huà)，基本上就可以不要這個(gè)配置文件了。你的應(yīng)用只需要指定不convention的信息即可，從而減少了大量convention而又不得不花時(shí)間和精力啰里啰嗦的東西，配置文件很多時(shí)候相當(dāng)?shù)挠绊戦_(kāi)發(fā)效率。
Rails 中很少有配置文件（但不是沒(méi)有，數(shù)據(jù)庫(kù)連接就是一個(gè)配置文件），Rails 的fans號(hào)稱(chēng)期開(kāi)發(fā)效率是 java 開(kāi)發(fā)的 10倍，估計(jì)就是這個(gè)原因。Maven也使用了CoC原則，當(dāng)你執(zhí)行mvn -compile命令的時(shí)候，不需要指源文件放在什么地方，而編譯以后的class文件放置在什么地方也沒(méi)有指定，這就是CoC原則。
Tiny框架的構(gòu)建者對(duì)于做重復(fù)的事情一向是深?lèi)和唇^的，因此非常不原意開(kāi)發(fā)人員在基于Tiny框架進(jìn)行開(kāi)發(fā)時(shí)出現(xiàn)重復(fù)的內(nèi)容。為此Tiny框架在設(shè)計(jì)上做了大量的工作，來(lái)避免程序員做違反DRY原則的內(nèi)容，所以在Tiny框架中，所有的工作內(nèi)容都是做一次就足夠。無(wú)標(biāo)簽評(píng)論用戶(hù)圖標(biāo):cskang蔡少康發(fā)表：
DRY——Don't RepeatYourself Principle，直譯為“不要重復(fù)自己”原則^_^
DRY簡(jiǎn)而言之，就是不要寫(xiě)重復(fù)的代碼。原則本身很簡(jiǎn)單，但是，對(duì)于OOAD來(lái)說(shuō)，有著非常重大的意義。
DRY利用的方法就是抽象：把共同的事物抽象出來(lái)，把代碼抽取到一個(gè)地方去。這樣就可以避免寫(xiě)重復(fù)的代碼。
舉一個(gè)DRY的典型例子，如果在一個(gè)類(lèi)構(gòu)造的時(shí)候，需要進(jìn)行成員的初始化，在進(jìn)行了某些操作以后，同樣要進(jìn)行初始化，那么就可以把“初始化”抽象出來(lái)，做成一個(gè)方法Initial()，在構(gòu)造和需要用到的地方調(diào)用它。
雖然，抽取重復(fù)代碼是利用DRY的一個(gè)好的開(kāi)端，但DRY的實(shí)質(zhì)是，一個(gè)需求，用一個(gè)部分來(lái)完成。當(dāng)你試圖避免重復(fù)代碼的時(shí)候，實(shí)際上，你做的應(yīng)該是用一段代碼來(lái)完成一個(gè)需求。
為什么要用DRY原則？DRY會(huì)給代碼維護(hù)帶來(lái)很大的好處。以類(lèi)的初始化為例，假設(shè)類(lèi)修改了，增加、減少或是修改了成員，如果不寫(xiě)Initial()，那么你可能至少要修改兩處，而且，修改之處也可能出現(xiàn)不一致，維護(hù)成本大大增加。而寫(xiě)了Initial()方法，那么只要集中修改Initial()就行了。
既然DRY是關(guān)于“一個(gè)方法，實(shí)現(xiàn)一個(gè)需求”的，那么，是不是可以把DRY應(yīng)用到需求分析中？呵呵，答案是肯定的，而且，個(gè)人認(rèn)為，這是個(gè)非常好的主意。多個(gè)重復(fù)的需求可能導(dǎo)致多個(gè)重復(fù)或者相近的類(lèi)，最后導(dǎo)致重復(fù)代碼。所以DRY絕不僅僅對(duì)代碼適用，它是一個(gè)廣泛適用的原則。
減法原則是我們自己提出的，意思就是給程序員做減法。一般來(lái)說(shuō)越到底層的程序員，工作時(shí)間越短、技能越弱、經(jīng)驗(yàn)越少。但是實(shí)際工作當(dāng)中，你會(huì)發(fā)現(xiàn)越到底層的程序員要做的事情越多，要用的技能也越多。Tiny構(gòu)建者認(rèn)為，這也是現(xiàn)在程序員工作效率低、質(zhì)量差的重要原因。因此我們認(rèn)為應(yīng)該給程序員做減法，越到底層的程序員做的事情要越單一、越簡(jiǎn)單。
可能有人在笑了，這個(gè)也算原則？確實(shí)，它就是原則，只不過(guò)原來(lái)下級(jí)服務(wù)上級(jí)是掛在嘴上的，而Tiny框架則從框架層級(jí)做了限制，使得下級(jí)必須服務(wù)上級(jí)。這兩點(diǎn)主要體現(xiàn)在流程及頁(yè)面實(shí)現(xiàn)中，上級(jí)經(jīng)理可以對(duì)下級(jí)完成的工作內(nèi)容進(jìn)行強(qiáng)制性要求實(shí)現(xiàn)，不同的是流程是采用顯式繼承的方式，而頁(yè)面是隱式繼承的方式
幾乎每個(gè)熟悉Tiny框架的人可能會(huì)問(wèn)同一個(gè)問(wèn)題，那就是：為什么Tiny分了這么多的工程？Tiny框架的構(gòu)建者也深深的知道這樣會(huì)增加相當(dāng)?shù)募晒ぷ鳎沁@樣做的好處是可以把單一原則進(jìn)行強(qiáng)制性的約束，使得一個(gè)模塊只解決單一模塊應(yīng)該解決的問(wèn)題，從而避免不同的問(wèn)題放在一起解決所導(dǎo)致的胡子眉毛縷不清的問(wèn)題，同時(shí)也避免了不恰當(dāng)?shù)囊蕾?lài)及模板引用。
一般的軟件開(kāi)發(fā)，整個(gè)集成過(guò)程都需要人員小心翼翼，要配這個(gè)配那個(gè)，稍不小心就會(huì)有這種那樣問(wèn)題的出現(xiàn)Tiny框架構(gòu)建者也常常知道這一點(diǎn)給集成人員帶來(lái)的困難及給軟件開(kāi)發(fā)測(cè)試帶來(lái)的巨大的工作量，因此在整個(gè)Tiny框架的構(gòu)建過(guò)程中，都非常注重集成過(guò)程的自動(dòng)組裝，要求做到扔進(jìn)去不用管，由框架自動(dòng)集成。Tiny框架構(gòu)建者深深知道，模塊化對(duì)于軟件開(kāi)發(fā)過(guò)程中開(kāi)發(fā)、高度、集成、發(fā)布、維護(hù)過(guò)程中所起的作用及節(jié)省或花費(fèi)的巨大成本。因此提出了業(yè)務(wù)單元(Business Unit)的概念，使得與模塊相關(guān)的所有內(nèi)容都可以放在一起。
在Tiny構(gòu)建者多年的工作過(guò)程中，被配置的問(wèn)題所常常困擾，在開(kāi)發(fā)期有許多問(wèn)題是由于配置不當(dāng)引起，在測(cè)試在發(fā)布及升級(jí)過(guò)程中，也有相當(dāng)多的問(wèn)題是由于配置不當(dāng)引起的。在Tiny框架我們對(duì)配置做了大量的工作，一個(gè)是COC方式，如果不配，則采用系統(tǒng)默認(rèn)的值；一個(gè)是集中原則：把需要人工需要配置的內(nèi)容都集中起來(lái)統(tǒng)一配置；一個(gè)是對(duì)于不需要人工干預(yù)的配置，那就集成在Jar包中，作為發(fā)布者發(fā)布項(xiàng)的一部分。
掃碼關(guān)注鍍金池微信號(hào)
手機(jī)訂課，優(yōu)惠多多
