2015-09-27 74 views
-1

我有一個關於課程設計的問題,我一直在研究一個項目。更準確地說,我將解釋這種情況,如果其方法正確或者不正確,將需要反饋。這是設計課程的正確方法嗎?

我們有一個驗證類,用於在持久化之前驗證用戶輸入的業務數據,例如我有一個驗證方法來檢查用戶名是否以空白開頭,另一個方法驗證特定類型的用戶應該提供地址,就像我們有幾種驗證方法一樣,隨着項目的發展,我們將會有更多這樣的驗證。這些驗證方法在服務類中用公共接口方法聲明爲私有,只有在用戶單擊保存時纔會調用所有這些私有方法。現在這裏的問題是,當爲第n個驗證方法編寫junit時,我必須遍歷所有以前的驗證準備測試數據,因爲它們有一個公共的公共接口。此外,如果任何其他驗證的邏輯發生變化,我的聯合可能會失敗。如果不公開這些方法,我建議我的同事擁有軟件包或受保護的可見性,但他們表示只是爲了單元測試而改變可見性並不正確。

此外,我發現了另一種使用反射訪問私有成員的解決方案,但它似乎更多的是黑客攻擊,並不推薦按照堆棧溢出中給出的某些答案。所以現在我開始思考如果這是一種設計氣味,將來我們可能需要在項目的其他部分進行一些驗證,然後必須將其公開化。但在提出這種改變之前,我不確定這一點,因此我認爲最好找一些專家就此提出意見。

您能否告訴我們這是否是一個設計問題,我們應該將這些方法作爲公開使用,這不是一個設計問題,那麼應該如何處理這個問題呢?

+0

這是提問的不好方法。還提供了你得到的實際設計,這將更多的可讀性,然後這個文本。 – YoungHobbit

+0

我想回答這個問題,然後看到這個混亂。我甚至不想讀它。這不是構建問題的正確方法。對不起。 –

+0

從'private'改變可視性對於單元測試來說默認是完全可以接受的,事實上,在上述情況下可能是最好的解決方案。反射和脆弱測試都是更差的結果。 –

回答

0

我認爲你應該將通用的驗證邏輯提取到一個單獨的類中並測試這個類。您的具體驗證類應該只包含或多或少的聲明性語法規則。例如,檢查how validation is handled in such frameworks as Laravel。你有套房嗎?

+0

感謝您的回答。現在我已經按照上面的建議將這些方法聲明爲package private。 –

相關問題