srp

    -1熱度

    3回答

    我非常執着於OC分類或實例方法,並將其移動到自己的類 中,很多時候一個簡單的「hello world」方法將被分成許多類。 像例如, class MainProgram def hello_world puts "hello world" end end 將被劃分到 class SayHello def initialize @hello =

    1熱度

    1回答

    我的項目中有一個需求,我必須建立一個web服務。此WebService將做以下事情: 接受XML格式的數據 返回XML格式的數據 XML輸入數據將有一個因素將登錄信息和需要處理的其他元素的數據。 現在我正在尋找一種設計模式,我可以讓web服務代碼看起來很整潔。因爲webservice必須做很多事情。 首先解析XML 驗證通過檢查用戶名和密碼 創建一個從數據對象,然後將數據保存到數據庫 準備和XML

    2熱度

    1回答

    我希望我能正確地描述這個問題。在處理具有靜態和實例可變字段的類的狀態和測試能力時,我有一個擔憂。 由於它們的生命期/範圍的不同,靜態字段實質上構成了不同的類/責任/實例嗎? 如果是這樣的話,那麼實例字段是不是也應該是一個單獨的類/數據結構? 然後:如果是這樣,那麼不應該所有的類都是無狀態的,只能接受它們對構造的依賴關係,並且應該都是不可變的嗎? 最後,這是否意味着函數式編程也是進行面向對象編程的正

    0熱度

    1回答

    我想創建一個不記錄異常的日誌系統,但是用戶活動以及他們對數據執行的操作。例如,當用戶刪除一條記錄時,我想記錄用戶名,記錄ID,日期和...。 首先我決定創建一個日誌類,並在其他所有類的方法中使用它的方法。但在讀過一些博客和搜索之後,我發現這種方法與OOP的SRP原理相反。 現在我正在考慮另一種解決方案。我仍然有我的日誌課程。但不是在代碼中調用它的方法,我應該使用事件。我正在考慮添加一個偵聽器類來訂

    5熱度

    2回答

    我想在我的.NET MVC 3應用程序上實現這個Command Pattern,專門用於保存對Thing的編輯。我不確定如何繼續。之前,我實際的問題,這裏是簡化代碼: public class ThingController { private readonly ICommandHandler<EditThingCommand> handler; public ThingC

    0熱度

    1回答

    程序解析日誌文件 - 每個日誌文件可能有不同類型的字段格式(固定寬度,逗號分隔等)。另外每個日誌文件都混合了幾種不同類型的日誌 - 每種日誌文件都有不同的字段定義)。例如,CSV日誌文件可能看起來像 日誌文件 logType1, 10/1/2012, 12, abc logType2, a, b, c, d, 11/1/2012 logType1, 10/2/2012, 21, def

    0熱度

    1回答

    我最近一直在閱讀Single Responsibility Principle概念,理論上我很同意它。我很難說明哪些代碼可以被嚴格分類爲違反該原則。我想實施這個原則,以便推動測試驅動開發。例如下面的代碼 採取: public void MarkAsSuccessful(PaymentMethodSpecific paymentMethod, bool requiresManualIntervent

    0熱度

    3回答

    最近我和其他一些開發人員討論過,表中有多少列或模型上的屬性過多是代碼味道。有些人認爲,具有太多屬性的模型做了太多事情,應該分割。 但是如果模型實際需要這些屬性呢? 讓我以users表爲例。 用戶可以具有 first_name,last_name,street_name,city,state,age等。 根據參數,我認爲street_name,city和state應該被移到不同的表中。我同意相關數據

    3熱度

    3回答

    假設您有抽象類A做一些事情。然後你有抽象類B做其他的事情。 而最後幾個正常上課,讓我們說ç... Z. A和B提供由C類..ž類使用功能。在我的情況下,主要是靜態的觀察者模式,以及某些類型的屬性的某些__get magic + lazy-loading - 這不是靜態的。我正在考慮將它合併到一個類中,但後來我確定它違反了SRP :) 所以我在C,D等中擴展A,B ......基本上所有C..Z類繼

    0熱度

    1回答

    我想了解SRP幫助我們減少耦合的所有可能方法。到目前爲止,我可以想到三個: 1)如果A類有多個責任,這些責任將變得相互耦合,因此,對這些責任之一的更改可能需要更改A的其他責任。 2)相關功能通常需要根據相同的原因進行更改,並將其分組到一個類中,可以在儘可能少的地方進行更改(最多隻需對類進行更改將這些功能組合在一起) 3)假設類A執行兩個任務(因此可能因爲兩個原因而改變),則利用A的類的數量將大於如