Liệu mô hình nhà nước có vi phạm Nguyên tắc thay thế Liskov?

Hình ảnh này được lấy từ Áp dụng các mẫu và thiết kế hướng tên miền: Với các ví dụ trong C # và .NET

Đây là sơ đồ lớp cho MẫuSalesOrder trạng thái nơi a có thể có các trạng thái khác nhau trong suốt thời gian tồn tại của nó. Chỉ có sự chuyển tiếp nhất định được cho phép giữa các trạng thái khác nhau.

Bây giờ OrderStatelớp là một abstractlớp và tất cả các phương thức của nó được kế thừa vào các lớp con của nó. Nếu chúng ta xem xét lớp con Cancelledlà trạng thái cuối cùng không cho phép chuyển đổi sang bất kỳ trạng thái nào khác, chúng ta sẽ phải sử dụng overridetất cả các phương thức của nó trong lớp này để đưa ra ngoại lệ.

Bây giờ không vi phạm nguyên tắc thay thế của Liskov vì một sublcass không nên thay đổi hành vi của cha mẹ? Việc thay đổi lớp trừu tượng thành một giao diện có sửa lỗi này không?
Làm thế nào để sửa cái này?

Điều này đặc biệt thực hiện, vâng. Nếu bạn thực hiện các lớp cụ thể của tiểu bang chứ không phải là người triển khai trừu tượng thì bạn sẽ thoát khỏi điều này.

Tuy nhiên, mẫu trạng thái mà bạn đang đề cập đến một cách hiệu quả là thiết kế máy trạng thái nói chung là thứ tôi không đồng ý với cách tôi đã thấy nó phát triển. Tôi nghĩ rằng có đủ cơ sở để giải mã điều này là vi phạm nguyên tắc trách nhiệm duy nhất bởi vì các mô hình quản lý nhà nước này cuối cùng trở thành kho lưu trữ trung tâm cho kiến ​​thức về tình trạng hiện tại của nhiều bộ phận khác trong hệ thống. Bộ phận quản lý nhà nước này được tập trung hóa thường xuyên hơn sẽ không yêu cầu các quy tắc kinh doanh liên quan đến nhiều bộ phận khác nhau của hệ thống để phối hợp chúng một cách hợp lý.

Hãy tưởng tượng nếu tất cả các bộ phận của hệ thống quan tâm đến trạng thái ở các dịch vụ khác nhau, các quy trình khác nhau trên các máy khác nhau, trình quản lý trạng thái trung tâm sẽ nêu chi tiết trạng thái cho từng vị trí đó làm tắc nghẽn toàn bộ hệ thống phân tán này và tôi nghĩ rằng tắc nghẽn là một dấu hiệu vi phạm SRP cũng như thiết kế nói chung là xấu.

Ngược lại, tôi sẽ đề nghị một đối tượng làm cho các đối tượng thông minh hơn như trong đối tượng Mô hình trong mô hình MVC nơi mô hình biết cách tự xử lý, nó không cần một người điều phối bên ngoài để quản lý hoạt động bên trong của nó hoặc lý do cho nó.

Ngay cả việc đặt một mẫu trạng thái như thế này bên trong một đối tượng để nó chỉ tự quản lý, có cảm giác như bạn sẽ làm cho đối tượng đó quá lớn. Quy trình công việc nên được thực hiện thông qua thành phần của các đối tượng tự chịu trách nhiệm khác nhau, thay vì với một trạng thái được phối hợp duy nhất quản lý dòng chảy của các đối tượng khác hoặc dòng chảy của trí thông minh trong chính nó.

Nhưng tại thời điểm đó, nó nghệ thuật hơn kỹ thuật và do đó, chắc chắn chủ quan của bạn đối với một số trong những điều đó, nói rằng các nguyên tắc là một hướng dẫn tốt và có, việc thực hiện mà bạn liệt kê là vi phạm LSP, nhưng có thể không được sửa. Chỉ cần rất cẩn thận về SRP khi sử dụng bất kỳ mẫu nào có tính chất này và bạn có thể an toàn.

một sublcass không nên thay đổi hành vi của cha mẹ?

Đó là cách hiểu sai về LSP. Một lớp con có thể thay đổi hành vi của cha mẹ, miễn là nó vẫn đúng với kiểu cha mẹ.

Có một lời giải thích dài trên Wikipedia , cho thấy những điều sẽ vi phạm LSP:

... có một số điều kiện hành vi mà kiểu phụ phải đáp ứng. Đây là những chi tiết trong một thuật ngữ giống như thiết kế theo phương pháp hợp đồng, dẫn đến một số hạn chế về cách hợp đồng có thể tương tác với kế thừa:

• Điều kiện tiên quyết không thể được tăng cường trong một kiểu con.
• Postconditions không thể được làm yếu trong một kiểu con.
• Bất biến của siêu kiểu phải được bảo toàn trong một kiểu con.
• Ràng buộc lịch sử ("quy tắc lịch sử"). Các đối tượng được coi là có thể sửa đổi chỉ thông qua các phương thức của chúng (đóng gói). Vì các kiểu con có thể giới thiệu các phương thức không có trong siêu kiểu, nên việc giới thiệu các phương thức này có thể cho phép thay đổi trạng thái trong kiểu con không được phép trong siêu kiểu. Các ràng buộc lịch sử cấm điều này. Đó là yếu tố tiểu thuyết được giới thiệu bởi Liskov và Wing. Một hành vi vi phạm ràng buộc này có thể được minh họa bằng cách định nghĩa MutablePoint là một kiểu con của ImmutablePoint. Đây là vi phạm ràng buộc lịch sử, bởi vì trong lịch sử của Điểm bất biến, trạng thái luôn giống nhau sau khi tạo, do đó, nó không thể bao gồm lịch sử của MutablePoint nói chung. Tuy nhiên, các trường được thêm vào kiểu con có thể được sửa đổi một cách an toàn vì chúng không thể quan sát được thông qua các phương thức siêu kiểu.

Cá nhân, tôi thấy dễ dàng hơn để nhớ điều này: Nếu tôi đang xem một tham số trong một phương thức có loại A, liệu ai đó có vượt qua một kiểu con B có gây cho tôi bất ngờ không? Nếu họ sau đó sẽ vi phạm LSP.

Là ném một ngoại lệ là một bất ngờ? Không hẳn vậy. Đó là điều có thể xảy ra bất cứ lúc nào, cho dù tôi đang gọi phương thức Ship trên OrderState hay Granted hoặc Shipped. Vì vậy, tôi phải tính đến nó và nó không thực sự vi phạm LSP.

Điều đó nói rằng , tôi nghĩ có nhiều cách tốt hơn để xử lý tình huống này. Nếu tôi viết điều này bằng C #, tôi sẽ sử dụng các giao diện và kiểm tra việc thực hiện giao diện trước khi gọi phương thức. Ví dụ: nếu OrderState hiện tại không triển khai IShippable, đừng gọi phương thức Ship trên đó.

Nhưng sau đó tôi cũng sẽ không sử dụng mô hình Bang cho tình huống cụ thể này. Mẫu Trạng thái phù hợp hơn nhiều với trạng thái của ứng dụng so với trạng thái của một đối tượng miền như thế này.

Vì vậy, một cách ngắn gọn, đây là một ví dụ kém về Mô hình Nhà nước và không phải là một cách đặc biệt tốt để xử lý trạng thái của một đơn đặt hàng. Nhưng nó được cho là không vi phạm LSP. Và mô hình Nhà nước, tự bản thân nó, chắc chắn là không.

(Điều này được viết từ quan điểm của C #, vì vậy không có trường hợp ngoại lệ nào được kiểm tra.)

Theo bài viết trên Wikipedia về LSP , một trong những điều kiện của LSP là:

Không có ngoại lệ mới nào được đưa ra bằng các phương thức của kiểu con, ngoại trừ trường hợp các ngoại lệ đó là các kiểu con của ngoại lệ được ném bởi các phương thức của siêu kiểu.

Làm thế nào bạn nên hiểu điều đó? Chính xác thì những trường hợp ngoại lệ nào được ném bởi các phương thức của supertype khi các phương thức của siêu kiểu là trừu tượng? Tôi nghĩ đó là những ngoại lệ được ghi nhận là những ngoại lệ có thể được ném ra bởi các phương pháp của siêu kiểu.

Điều này có nghĩa là nếu OrderState.Ship()được ghi lại như một thứ gì đó giống như ném ra InvalidOperationExceptionnếu hoạt động này không được hỗ trợ bởi trạng thái hiện tại, thì tôi nghĩ rằng thiết kế này không phá vỡ LSP. Mặt khác, nếu các phương thức siêu kiểu không được ghi lại theo cách này, LSP bị vi phạm.

Nhưng điều này không có nghĩa đây là thiết kế tốt, bạn không nên sử dụng ngoại lệ cho luồng điều khiển thông thường, điều này có vẻ rất gần với. Ngoài ra, trong một ứng dụng thực tế, có lẽ bạn sẽ muốn biết liệu một thao tác có thể được thực hiện hay không trước khi bạn cố gắng thực hiện, ví dụ như để vô hiệu hóa nút Nút Ship Ship trong giao diện người dùng.