基本問題是，我們是否應該將邏輯放在「對象」類或執行計算的分離服務中？對象應該處理自己的動作/邏輯嗎？
讓我們來看一下情景：我們有一個可以在畫布上顯示的「多邊形」類型的對象，它也可以與其他多邊形合併，創建新的兩者之和。所以我們應該有這樣的方法： 1. DrawOnCanvas（..）2.合併（..）所以問題是這些方法應該存儲在Polygon類（以及DrawOnCanvas可以存儲在Canvas類）或一些PolygonService類？
是否有一些正式的方法論建議一種方式？
是否有一些正式的方法論暗示其他方法的一種方法？
完全沒有，但你可以稱之爲a good separation of concerns。
一些觀察：
像DrawOnCanvas(...)的操作不會是一個Polygon類的，因爲你要強制實施可重用性。也就是說，Polygon應該可用作可繪製對象或者只是作爲常規域對象。我看到一個DrawOnCanvas(...)方法作爲類的一部分，如UIRenderer，它會提供重載以處理Polygon的實例。
Merge(...)不應該在Polygon因爲涉及兩個多邊形。在PolygonService上實現它是安全的。
您應該執行1995年Polygon方法，如果這些代表變異的Polygon或唯一的操作涉及Polygon給定的實例。例如，CalculateArea(...)，CalculatePerimeter(...) ...
一個PolygonService絕對是一個壞主意，名稱的如果僅僅是因爲。您可能需要一個額外的類負責Canvas和Polygon之間的交互，一旦變得有趣的複雜性，並且肯定需要一個不同的名稱，並且不與負責合併和創建新類的類混合。