資訊專欄INFORMATION COLUMN
摘要：但是站在抽象層次和接口的復用率角度應該第四種才是最合理的場景二有兩個接口和現在在組合層需要同時調用和來組裝成一個新的實體。
場景 場景一
用戶基本信息的展示.產品需要有3個頁面,分別面向的是消費者,運營,商家。所以3個頁面的內容不是完全一樣的,并且有些內容是敏感的,但是他們的數據源是一致的?，F在一共有四種解決方案:
分別寫三個DAO,根據頁面需求返回不同的數據
分別寫三個service,調用的是同一個DAO,在service中根據頁面需求進行裁剪
分別寫三個組合層的接口,組合層調用的是同一個service,然后在組合層根據頁面需求進行裁剪
根據頁面需求在controller層對字段進行裁剪,調用的是同一個組合層
處理方式:在這個場景中,我一開始選擇的處理方式是第三種,當時是基于公有轉換代碼的重復利用。但是站在抽象層次和接口的復用率角度應該第四種才是最合理的
場景二有兩個接口ServiceA.methodA()和ServiceA.methodB(),現在在組合層需要同時調用methodA()和methodB()來組裝成一個新的實體。有兩種方案可以解決:
在ServiceA中重新寫一個方法methodC()給組合層使用
在組合層自己寫私有方法或者Utils方法去組裝實體
場景三電商系統商品詳情頁,有放入購物車和直接購買兩個選項,直接購買選項也會放入購物車,但是和實際上的購物車是分離的。實現方式有三種:
前臺通過傳遞一個時間戳t來標示是放入購物車還是直接購買,如果t=0就是放入購物車,如果是t!=0就是直接購買。購物車相對應也有兩個接口Service.MethodA(),Service.MethodB(long t),分別對應放入購物車和直接購買(這里的t對購物車模塊有特殊作用)
購物車值提供一個接口Service.Method(long t),在購物車模塊中根據t自己去判斷是直接購買還是放入購物車
前臺傳一個標示flag表示是否直接購買,購物車提供兩個接口Service.MethodA(),Service.MethodB()(這里去除了購物車模塊對時間戳t的依賴)
場景四一個Service.Method()返回了一個A實體.現在有新的需求發現A實體返回的字段太少了,得多加一個字段。這個時候有兩種處理方式:
直接在A實體中添加
重新寫一個接口返回的是實體B,B比A要多一些字段
總結場景一和場景四代表的是各個層次如何定義自己的接口,以及是否需要定義一些特殊的接口,目前感覺:在開發之前需要評估一下每個接口的調用頻率,是否需要定義一些多帶帶的返回接口(除非明顯感覺有性能問題,一些接口可能返回一些大字段,而這個大字段在很多場景下是用不到的,或者因為接口需要返回一個字段而需要做很多消耗性能的工作,或者接口返回50個字段,而我只需要一個字段,并且這種場景很多。這些可以多帶帶定義一些特殊接口),而其它的可以共用的接口盡量共用,當后期在線上運行的時候發現某個調用確實因為接口太粗而導致了性能問題,那么可以重新拎出一個接口。
場景二代表的是,一開始定義的接口粒度很小,但是后期需求發現上層調用需要用到一個粒度更加大的接口,這個時候需要分析這種場景是否很多,如果發現很多,就可以多帶帶為其開一個新的接口，新的接口調用內部的粒度小的接口來組合成一個新的返回實體(假設這些實體分屬不同的表),這種相當于在原來的層次中間加了一層層次更加高的抽象,如果以后這種越來場景越多(小粒度組成大粒度),這層就會變得越來越明顯。
場景三,表示的是模塊需要給上層提供什么樣子的接口,一些模塊內部的信息或者其它東西就不要暴露給上層調用者,比如方法一合方法三的不同之處就是是否需要知道內部的Key是要用時間戳來表示的,所以在設計接口的時候需要同時站在使用者的角度和設計者的角度考慮,盡量不要把內部的實現細節暴露給使用者(比如上述的例子,如果以后不是以時間戳來當key的話,那么這個接口傳入的時間戳就顯得毫無意義的)，當然也不是一定要遵循這個原則,當接口由于你傳入一個參數而導致性能出現了質的飛躍,那么這些反設計的接口還是允許存在的
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/65368.html
摘要：本書概括以軟件系統為例，重點講解了應用架構中的物理設計問題，即如何將軟件系統拆分為模塊化系統。容器獨立模塊不依賴于具體容器，采用輕量級容器，如獨立部署模塊可獨立部署可用性模式發布接口暴露外部配置使用獨立的配置文件用于不同的上下文。 本文為讀書筆記，對書中內容進行重點概括，并將書中的模塊化結合微服務、Java9 Jigsaw談談理解。 本書概括 以Java軟件系統為例，重點講解了應用架構...
摘要：一個復雜的應用都是由簡單的應用發展而來的隨著越來越多的功能加入項目代碼就會變得越來越難以控制本文章主要探討在大型項目中如何對組件進行組織讓項目具備可維護性系列目錄類型檢查組件的組織樣式的管理組件的思維狀態管理目錄組件設計的基本原則基本原則高 一個復雜的應用都是由簡單的應用發展而來的, 隨著越來越多的功能加入項目, 代碼就會變得越來越難以控制. 本文章主要探討在大型項目中如何對組件進行組...
摘要：上一篇，講到了，最近，在做的設計對于設計，一方面是對于后端框架的設計，另一方面呢，是對于整個體系的設計在這里呢，我們來理理思路，先來大致分一下塊風格就不用說了，我們就用風格，接下來，也就是我們所說的接口描述語言框架，整個服務的核心驅動版本控 上一篇，講到了，最近，在做 api 的設計 對于設計，一方面是對于后端 server 框架的設計，另一方面呢，是對于整個 api 體系的設計 在這...
摘要：前言關于設計模式，想必大家的第一感覺就是過于高深，有點虛吧。為什么要學習設計模式因為要裝逼啊咳咳，大家請忽略前面那句話。處處都是設計模式的體現，所以若想攻下，設計模式是必學的。下節預告單例模式 前言 關于設計模式，想必大家的第一感覺就是過于高深，有點虛吧。相對來說，我們還是更熟悉ssh或者ssm之類的開發框架，一個工具用久了就會熟能生巧，就像刷漆工，時間長了也知道如何刷的一手漂亮的好墻...
閱讀 909·2021-09-09 09:32
閱讀 2849·2021-09-02 10:20
閱讀 2685·2021-07-23 11:24
閱讀 824·2019-08-30 15:54
閱讀 3631·2019-08-30 15:54
閱讀 1346·2019-08-30 11:02
閱讀 2844·2019-08-26 17:40
閱讀 1122·2019-08-26 13:55
