軟件,很多寫起來的時候講究一些格式。不怎習慣去看那些方式和經驗,因爲沒怎麼遇到過使用場景,沒有類似的思考。現在在編程中了,主要考慮怎麼把功能分到合適的類裏,或者僅僅是分配職責。
沒怎麼找到以自己想到的出發點進行的思考。於是自己寫一些進行分析。
最近,比較開心的,是遇到一前輩,他說了一句話,把功能放到“一個”地方容易維護。場景是很多地方都要完成這個功能,而且根據場景不同功能有些細節的變化。更重要的是 是一塊很大的功能,不是那麼容易編排和移動。如果只是爲了實現需求的話,可能就需要寫在兩三個地方。因爲這個功能裏邊處理的事情比較多,後期有變動的話可能就要在“兩三個”地方做改動。這份功能本來就很大,一個小改動就比較耗時或者說需要小心認真,如果每個小改動都要維護多份的話,就太頭大了。
他說這話讓我感受到一些,c++系的思考。比較透徹,這語言的分類就有些向簡單直接地把 功能放到唯一一個地方,容易維護。如果是java 系的話,思考起來就更像是劃分職責。這個職責歸誰所有,然後把這個職責分配給它。不把它考慮成一個功能,考慮成一份職責。
在代碼功能分配的初始,就劃分好每一部分必須要完成的事情。也就是爲什麼需要這一部分,存在的必要性是什麼。確定每一個區域的基本職責之後,再把需要完成的功能朝這些區域分配。更適合哪個區域就給哪個區域,這樣再設計的初始就儘量避免讓各區域出現重複的代碼 重複的責任。
不過最根本,這樣做的原因,也就是把 某種業務邏輯放到唯一一個地方,以後改動起來方便。
本來寫程序就是想要達到更大程度這樣。結合面向對象的話會有一個稍微清晰一些的思考,如果是c++系,偏向最簡便的方式實現功能的話,可能就難一點。後者要求了更高的專業度和行業經驗,思考量比較大。用面向對象 即職責劃分的思維的話,顯得比較容易一些。
做好分類,不用承載太多的計算量和代碼邏輯量。至少會稍微優化一些。這是一種思想,最終目的也是和前輩的一樣,放在同一個地方好維護。只是爲怎麼做到提供了一個理論參考的方法。
對功能進行職責劃分,分到具體區域裏去。對每個功能區域進行反思,思考它存在的必然性確定它的基本職責。兩者結合。
另一個是數據庫方面的例子,還沒有思考很清。
都會遇到一個類似出庫表或者收據表。承載普通收據上那些東西。有的存放方式是通用信息放一個表,收據上的每一項放另一個表然後和前者關聯;也有存放方式是全部都放在一個表中,每一行數據都由通用信息和三條項目佔用的空間組成。
前者,自己看到的一般都這樣用,隨着數據量的增多,兩個表之間的關聯情況會越來越 遠。後者,有的場景在用着,這種更符合面向對象。面向對象的功能建模就是參考實際,這樣會好一點。具體意思就是平時生活中收據都是這麼用的,這樣建立以後,平時生活對收據的各種操作也能比較簡單的映射到編程中,不用做過多的思考。存放的是一個現實對象,不是一個爲實現功能的拆分。至於三項不滿出現空餘,這個就不要緊了,生活中也是這樣空餘。
不過改成後者之後,發現另一個問題,檢索。用單聯的話檢索一個特定商品,做統計就比較容易。做成多聯的話,每個商品都需要在單條的三個條目中依次搜索。當然啦,生活中, 在還沒有出現電腦取代的時候,都是存放在多聯裏,可能需要搜查的數據另外統計在另一個手寫表裏。只是在做的項目,如果改成多聯的話model類和一些相關的東西也要改,於是一時沒做起來。
從職責劃分角度,做成三項存一條 多聯 比較好。
總之,對對象進行職責劃分和功能職責分配是比較好的方式。我在這方面還在學習和發現更多。