問題:在將具有現有基本功能子集的子類引入到已建立的繼承系統時,除了 Liskov 替換原則之外,還有其他設計原則需要考慮嗎?
背景關系:我們有一個既定的系統,該系統可以對具有共享基本功能的數十種不同型別的物體進行建模。因此,我們有基礎資料庫表、基礎聚合、基礎助手、基礎驗證器等,然后是從基礎類繼承的物體型別特定子類。
我們被要求引入一種新型別的物體,它只實作這個基本功能的一個子集。據我了解,將基本功能保留在適當的位置并僅覆寫新物體的子類中受影響的屬性和方法將違反 Liskov 替換原則。然而,徹底改革系統以實作以下目的似乎違反直覺:
- 將除新物體型別之外的所有物體型別所需的資料庫欄位移動到相關表
- 將基本聚合、幫助程式和驗證器實作更改為僅加載/獲取/更新/驗證基本資料的子集并在所有物體型別特定聚合中覆寫它(即使它們使用通用配接器或幫助器)
- ETC...
僅針對一種新物體型別,知道所有其他物體型別都需要以前共享的資料庫欄位和基本實作。
在這種情況下,違反 LSP 是否可以接受?還有其他適用于這種情況的設計原則嗎?
詳細示例:考慮一個作業管理系統:
- 有許多型別,
Assignment但都有一個Person指定的。 - 它們都有
AssignmentNotes,這允許將零到多個Notes添加到Assignment. AssignmentNotes還允許將Assignment標記為Assignment帶有可選注釋的組,并且可以識別Person中涉及的 s 。Assignment
每種分配型別都有 Aggregate、Helper 和 Validator 類,但由于共享功能,它們分別從 aBaseAssignmentAggregate和BaseAssignmentHelper繼承BaseAssignmentValidator。負責加載和更新共享資料,BaseAssignmentAggregate例如:
public virtual async Task Load(int id)
{
Model = await Context.Assignment.SingleAsync(a => a.Id == id);
await Context.AssignmentNotes.Where(a => a.AssignmentId == id)
.Include(an => an.AssignmentNotesNote)
.Include(an => an.AssignmentNotesGroupAssignmentIncludedPerson)
.LoadAsync();
}
public async Task SaveAssignmentNotes(IReadOnlyCollection<int> noteIds, bool isGroupAssignment, string groupAssignmentComments, IReadOnlyCollection<int> groupAssignmentIncludedPersonIds)
{
AssertIsLoaded();
if (noteIds == null) throw new ArgumentNullException(nameof(noteIds));
...
// synchronise notes
...
Model.AssignmentNotes.IsGroupAssignment = groupAssignmentComments;
Model.AssignmentNotes.GroupAssignmentComments = groupAssignmentComments;
// synchronise group assignment people
...
// save
await SaveChanges();
}
DbContext 中的相關物體型別可能如下:
public partial class Assignment
{
public int Id { get; set; }
public byte AssignmentTypeId { get; set; }
public int AssignedPersonId { get; set; }
public virtual Person AssignedPerson { get; set; }
public virtual AssignmentNotes AssignmentNotes { get; set; }
public virtual AssignmentType AssignmentType { get; set; }
public virtual AssignmentTypeADetails AssignmentTypeADetails { get; set; }
public virtual AssignmentTypeBDetails AssignmentTypeBDetails { get; set; }
public virtual AssignmentTypeCDetails AssignmentTypeCDetails { get; set; }
public virtual AssignmentTypeDDetails AssignmentTypeDDetails { get; set; }
...
}
public partial class Person
{
public Person()
{
Assignment = new HashSet<Assignment>();
AssignmentNotesGroupAssignmentIncludedPerson = new HashSet<AssignmentNotesGroupAssignmentIncludedPerson>();
}
public int PersonId { get; set; }
public string Name { get; set; }
public virtual ICollection<Assignment> Assignment { get; set; }
public virtual ICollection<AssignmentNotesGroupAssignmentIncludedPerson> AssignmentNotesGroupAssignmentIncludedPerson { get; set; }
}
public partial class AssignmentNotes
{
public AssignmentNotes()
{
AssignmentNotesNote = new HashSet<AssignmentNotesNote>();
AssignmentNotesGroupAssignmentIncludedPerson = new HashSet<AssignmentNotesGroupAssignmentIncludedPerson>();
}
public int AssignmentId { get; set; }
public bool IsGroupAssignment { get; set; }
public string GroupAssignmentComments { get; set; }
public virtual Assignment Assignment { get; set; }
public virtual ICollection<AssignmentNotesNote> AssignmentNotesNote { get; set; }
public virtual ICollection<AssignmentNotesGroupAssignmentIncludedPerson> AssignmentNotesGroupAssignmentIncludedPerson { get; set; }
}
public partial class AssignmentNotesNote
{
public int Id { get; set; }
public int AssignmentId { get; set; }
public int NoteId { get; set; }
public virtual Note Note { get; set; }
public virtual AssignmentNotes Assignment { get; set; }
}
public partial class AssignmentNotesGroupAssignmentIncludedPerson
{
public int Id { get; set; }
public int AssignmentId { get; set; }
public int PersonId { get; set; }
public virtual Person Person { get; set; }
public virtual AssignmentNotes Assignment { get; set; }
}
現在假設我們被要求引入一個新的AssignmentTypeZ,它永遠不會是一個組分配,即這個分配型別仍然可以有注釋,但它永遠不會IsGroupAssignment,它永遠不會有GroupAssignmentComments,也永遠不會有任何AssignmentNotesGroupAssignmentIncludedPerson。
現在這些屬性在 AssignmentNotes 表和所有相關的基類中是否存在無效?是否涉及其他設計原則或者我現在有義務
- 轉移這些屬性說一個新的
AssignmentNotesGroupAssignment資料庫表? - 更改
BaseAssignmentAggregate為不加載此表或在其上實作屬性,并覆寫所有其他AssignmentTypeAggregates 這樣做? - 將 更改
BaseAssigmentAggregate為僅更新 Notes,并覆寫所有其他 AssignmentTypeAggregates 以更新AssignmentNotesGroupAssignment詳細資訊? - ETC...
只針對一種新的物體型別?
uj5u.com熱心網友回復:
現在這些屬性在 AssignmentNotes 表和所有相關的基類中是否存在無效?
我認為在物件和資料之間劃清界限很重要。最常見的軟體應用程式設計可能是“資料庫驅動設計”,其中首先設計資料庫模式,每個“物件”只是資料庫表的表示。然而,這是一種糟糕的 OOP 方式,因為資料庫表會保存資料,而不是物件。表不保留繼承或多型性或封裝或任何作為 OOP 中物件核心的業務邏輯。
OO 應用程式設計應該獨立于持久性,因為同一個應用程式可以運行在 NoSQL 或 RDBMS 或平面檔案或從網路中提取的 JSON 資料之上。沒關系。
這是一個冗長的咆哮,說 LSP 不關心 AssignmentNotes 表。
當涉及到AssignmentNotes類時,LSP 對總是回傳 falseIsGroupAssignment并且從不填充GroupAssignmentCommentsor的子類沒有問題AssignmentNotesGroupAssignmentIncludedPerson。畢竟,另一個子類在同一狀態下是有效的,即使它也允許其他狀態。
LSP 問題源于此方法簽名:
SaveAssignmentNotes(IReadOnlyCollection<int> noteIds, bool isGroupAssignment, string groupAssignmentComments, IReadOnlyCollection<int> groupAssignmentIncludedPersonIds).
即使在添加提議的子類之前,該方法似乎也有問題,因為isGroupAssignment引數指示是否可以填充最后兩個引數,這意味著可以使用無效的引陣列合呼叫該方法。
我會將方法一分為二。
SaveAssignmentNotes(IReadOnlyCollection<int> noteIds)
SaveAssignmentNotes(IReadOnlyCollection<int> noteIds, string groupAssignmentComments, IReadOnlyCollection<int> groupAssignmentIncludedPersonIds)
理想情況下,這兩種方法將位于不同的基類中:一種支持組分配,另一種不支持。如果您將他們留在同一個班級,請將第二個記錄為可選的,用于AssignmentNotes該支持小組。
無論哪種方式,Liskov 的解決方案始終是清楚地記錄前置條件、后置條件和不變數。LSP 是一種句法和語意原則,這意味著 API 契約不僅是方法簽名,而且是其檔案。基類可以定義可選行為(在這種情況下用于保存“不支持的”欄位),但它還必須為未實作可選行為的子類定義預期行為,因此客戶端不會對該子類感到驚訝。
轉載請註明出處,本文鏈接:https://www.uj5u.com/net/464912.html
標籤:C# 遗产 坚实的原则 设计原则 liskov-替代原则
上一篇:從母類物件列印擴展類物件的值
