Làm thế nào có thể thiết kế cho thừa kế gây ra chi phí thêm? [đóng cửa]

Vì vậy, tôi muốn kế thừa từ một sealed classtrong CSharp và bị đốt cháy. Không có cách nào để mở khóa nó trừ khi bạn có quyền truy cập vào nguồn.

Sau đó, nó khiến tôi suy nghĩ "tại sao sealedthậm chí tồn tại?". 4 tháng trước. Tôi không thể tìm ra nó, mặc dù đọc nhiều điều về nó, chẳng hạn như:

• Mong muốn của Jon Skeet " các lớp được niêm phong theo mặc định trong .NET. "
• Thích thành phần hơn thừa kế?
• "Bạn không nên niêm phong tất cả các lớp (...)"
• Làm thế nào để bạn chế nhạo một lớp kín?

Tôi đã cố gắng tiêu hóa tất cả những thứ đó kể từ đó, nhưng nó chỉ là quá nhiều đối với tôi. Cuối cùng, ngày hôm qua tôi đã thử lại. Tôi đã quét qua tất cả chúng một lần nữa, cộng thêm vài lần nữa:

• Tại sao một lớp nên là bất cứ thứ gì khác ngoài "trừu tượng" hoặc "cuối cùng / niêm phong"?
• Trong hơn 15 năm lập trình, lần đầu tiên tôi nghe nói về RẮN , từ một câu trả lời từ một câu hỏi đã được liên kết và rõ ràng tôi đã không đọc nó cả 4 tháng trước

Cuối cùng, sau nhiều suy ngẫm, tôi quyết định chỉnh sửa mạnh câu hỏi ban đầu dựa trên tiêu đề mới.

Câu hỏi cũ quá rộng và chủ quan. Về cơ bản nó đã hỏi:

1. Trong tiêu đề cũ: Một lý do chính đáng để sử dụng niêm phong
2. Trong cơ thể: Làm thế nào để sửa đổi một lớp kín? Quên về thừa kế? Sử dụng thành phần?

Nhưng bây giờ, sự hiểu biết (mà tôi đã không làm ngày hôm qua) rằng tất cả đều sealedngăn cản sự kế thừa , và chúng ta thực sự có thể và nên sử dụng thành phần trên sự kế thừa , tôi nhận ra những gì tôi cần là những ví dụ thực tế .

Tôi đoán câu hỏi của tôi ở đây là (và trên thực tế luôn luôn như vậy) chính xác những gì Mr.Mindor gợi ý cho tôi trong một cuộc trò chuyện : Làm thế nào để thiết kế cho thừa kế có thể gây thêm chi phí?

Điều này không quá khó để hiểu. sealedđã được tạo ra ĐẶC BIỆT cho Microsoft để làm cho cuộc sống của họ dễ dàng hơn, tiết kiệm hàng tấn tiền và giúp danh tiếng của họ. Vì nó là một tính năng ngôn ngữ mà mọi người khác cũng có thể sử dụng nhưng BẠN có thể sẽ không bao giờ cần phải sử dụng niêm phong.

Hầu hết mọi người đang phàn nàn về việc không thể mở rộng một lớp và nếu họ làm như vậy thì họ nói tốt mọi người đều biết đó là trách nhiệm của các nhà phát triển để làm cho nó hoạt động chính xác. Điều đó là chính xác, NGOẠI TRỪ những người đó không có manh mối về lịch sử của Windows và một trong những vấn đề sealedđang cố gắng giải quyết.

Giả sử nhà phát triển đã mở rộng lớp lõi .Net (vì không được niêm phong) và khiến nó hoạt động hoàn hảo. Yay, cho nhà phát triển. Nhà phát triển cung cấp sản phẩm cho khách hàng. Ứng dụng của nhà phát triển hoạt động rất tốt. Khách hàng hài lòng. Cuộc sống là tốt.

Bây giờ Microsoft phát hành một hệ điều hành mới, bao gồm sửa các lỗi trong lớp lõi .Net cụ thể này. Khách hàng muốn theo kịp thời đại và chọn cài đặt hệ điều hành mới. Thật bất ngờ, ứng dụng mà khách hàng thích rất nhiều không còn hoạt động nữa, vì nó không tính đến các lỗi đã được sửa trong lớp lõi .Net.

Ai nhận lỗi?

Những người quen thuộc với lịch sử của Microsoft đều biết rằng HĐH mới của Microsoft sẽ bị khiển trách chứ không phải phần mềm ứng dụng đã lạm dụng các thư viện windows. Vì vậy, nó trở thành đương nhiệm của Microsoft để khắc phục vấn đề thay vì công ty ứng dụng đã tạo ra vấn đề. Đây là một trong những lý do tại sao mã Windows trở nên cồng kềnh. Từ những gì tôi đã đọc, mã hệ điều hành Windows nằm rải rác với if-then cụ thể kiểm tra xem một ứng dụng và phiên bản cụ thể có đang chạy hay không và nếu vậy thì hãy xử lý đặc biệt để cho phép chương trình hoạt động. Đó là rất nhiều tiền mà Microsoft đã bỏ ra để khắc phục sự bất tài của một công ty khác.

Sử dụng sealedkhông loại bỏ hoàn toàn kịch bản trên, nhưng nó có ích.

sealedđược sử dụng để chỉ ra rằng người viết của lớp đã không thiết kế nó để được kế thừa. Không hơn không kém

Thiết kế đúng một giao diện đã đủ khó đối với nhiều lập trình viên. Thiết kế đúng một lớp có thể được kế thừa có thêm độ khó và dòng mã. Nhiều dòng mã được viết có nghĩa là nhiều mã hơn để duy trì. Để tránh khó khăn ngày càng tăng này, sealedcó thể chỉ ra rằng lớp không bao giờ được dự định kế thừa và trong bối cảnh này, niêm phong một lớp là một giải pháp hoàn toàn hợp lệ cho một vấn đề .

Hãy tưởng tượng trường hợp mà lớp CustomBoeing787có nguồn gốc từ Airliner. Điều này CustomBoeing787ghi đè một số phương thức được bảo vệ từ Airliner, nhưng không phải tất cả chúng. Nếu nhà phát triển có đủ thời gian và nó xứng đáng, anh ta có thể kiểm tra lớp để đảm bảo mọi thứ hoạt động như mong đợi, ngay cả trong bối cảnh khi các phương thức không được ghi đè (ví dụ: các setters được bảo vệ thay đổi trạng thái của đối tượng). Nếu cùng một nhà phát triển (1) không có thời gian, (2) sẽ không muốn chi thêm hàng trăm hoặc hàng ngàn đô la cho ông chủ / khách hàng của mình hoặc (3) không muốn viết thêm mã mà anh ta không muốn viết cần ngay bây giờ (YAGNI), sau đó anh ta có thể:

• hoặc phát hành mã trong tự nhiên, xem xét rằng đó là mối quan tâm của các lập trình viên, những người sẽ duy trì dự án này sau này để quan tâm đến các lỗi tiềm ẩn,

• hoặc đánh dấu lớp sealedđể hiển thị rõ ràng cho các lập trình viên tương lai rằng lớp này không có ý định kế thừa, và việc tiết lộ nó và sử dụng nó như một phụ huynh nên tự chịu rủi ro.

Có phải là một ý tưởng tốt để đóng dấu càng nhiều lớp càng tốt, hoặc càng ít càng tốt? Từ kinh nghiệm của tôi, không có câu trả lời dứt khoát. Một số nhà phát triển có xu hướng sử dụng sealedquá nhiều; những người khác không quan tâm đến việc lớp học sẽ được kế thừa như thế nào và vấn đề nó có thể gây ra. Với cách sử dụng như vậy, vấn đề tương tự như vấn đề bao gồm việc xác định liệu lập trình viên có nên sử dụng hai hoặc bốn khoảng trắng để thụt lề hay không: không có câu trả lời đúng.

Khi một lớp được niêm phong, nó cho phép mã sử dụng loại đó để biết chính xác những gì họ đang xử lý.

Bây giờ trong C # stringlà sealed, bạn không thể thừa hưởng từ nó, nhưng hãy giả sử trong một giây không phải vậy. Nếu bạn đã làm, thì ai đó có thể viết một lớp như thế này:

public class EvilString// : String
{
    public override string ToString()
    {
        throw new Exception("I'm mean");
    }
    public override bool Equals(object obj)
    {
        return false;
    }
    public override int GetHashCode()
    {
        return 0;
    }
}

Bây giờ đây sẽ là một lớp chuỗi vi phạm tất cả các loại thuộc tính mà các nhà thiết kế stringđã biết là đúng. Họ biết rằng Equalsphương pháp này sẽ mang tính bắc cầu, nhưng điều này thì không. Heck, phương thức bằng này thậm chí không đối xứng, vì một chuỗi có thể bằng với nó nhưng nó sẽ không bằng chuỗi đó. Tôi chắc chắn rằng có tất cả các loại lập trình viên đã viết mã theo giả định rằng ToStringphương pháp stringsẽ không đưa ra một ngoại lệ cho các giá trị khác không. Bây giờ bạn sẽ có thể vi phạm giả định đó.

Có bất kỳ số lượng các lớp khác chúng ta có thể làm điều này cho, và tất cả các loại giả định khác mà chúng ta có thể vi phạm. Nếu bạn loại bỏ tính năng ngôn ngữ chosealedsau đó các nhà thiết kế ngôn ngữ bây giờ cần bắt đầu hạch toán những thứ như thế này trong tất cả các mã thư viện của họ. Họ cần thực hiện tất cả các loại kiểm tra để đảm bảo rằng các loại mở rộng của loại mà họ muốn sử dụng sẽ được viết "đúng", đây có thể là một việc rất tốn kém (cả về thời gian phát triển, cũng như thời gian chạy). Bằng cách có thể niêm phong một lớp, họ có thể đảm bảo rằng điều này là không thể, và bất kỳ xác nhận nào họ đưa ra về các chi tiết triển khai của các loại của riêng họ đều không thể bị vi phạm, ngoại trừ các loại được thiết kế có chủ ý được mở rộng. Đối với những loại được thiết kế để mở rộng, bạn sẽ thấy mã ngôn ngữ cần phải phòng thủ hơn nhiều về cách nó xử lý chúng.

Có bất kỳ lý do tốt để sử dụng niêm phong?

Tăng cường? Không thường xuyên. Tôi sẽ chỉ sử dụng niêm phong khi tôi có một loại không thay đổi (hoặc một số hạn chế khác) thực sự cần duy trì bất biến và tôi không thể tin tưởng những người thừa kế vào yêu cầu đó mà không đưa các lỗi catastropic tinh vi vào hệ thống.

Giả sử có một lý do chính đáng để sử dụng niêm phong và chúng ta nên sử dụng nó làm mặc định cho mọi thứ, chúng ta làm gì với thừa kế?

Chúng tôi sử dụng sự kế thừa cho những thứ không mặc định. Ngay cả khi thành phần được ưa chuộng hơn sự kế thừa (và thực tế), điều đó không có nghĩa là sự kế thừa sẽ bị loại bỏ. Điều đó có nghĩa là sự kế thừa có một số vấn đề nội tại mà nó đưa vào thiết kế và khả năng duy trì mã và thành phần thực hiện nhiều điều tương tự với (nói chung) ít vấn đề hơn. Và nó có nghĩa là ngay cả khi thành phần được ưa chuộng thì sự kế thừa là tốt cho các tập hợp con nhất định của các vấn đề.

Tôi không có nghĩa là quá có ý nghĩa nhưng nếu bạn vừa nghe nói về RẮN và thử nghiệm đơn vị, có lẽ bạn nên thoát ra khỏi hòn đá của mình và thực sự viết mã. Mọi thứ không rõ ràng và hiếm khi "luôn luôn làm X" hoặc "không bao giờ sử dụng Y" hoặc "Z là tốt nhất" là cách đúng đắn (giống như bạn có vẻ hấp dẫn dựa trên quan điểm của câu hỏi của bạn). Khi bạn viết mã, bạn có thể thấy các trường hợp sealedcó thể tốt và các trường hợp khiến nó đau buồn - giống như bất kỳ sự đánh đổi nào khác.

Trước hết, bạn nên đọc bài đăng của Eric Lippert về lý do tại sao Microsoft niêm phong các lớp học của họ.

http://bloss.msdn.com/b/ericlippert/archive/2004/01/22/61804.aspx

Thứ hai, từ khóa kín tồn tại để làm chính xác những gì nó làm - ngăn chặn sự kế thừa. Có nhiều tình huống mà bạn muốn ngăn chặn sự kế thừa. Hãy xem xét một lớp học mà bạn có một bộ sưu tập. Nếu mã của bạn phụ thuộc vào lớp đó hoạt động theo kiểu cụ thể, bạn không muốn ai đó ghi đè một trong các phương thức hoặc thuộc tính trong lớp đó và khiến ứng dụng của bạn bị lỗi.

Thứ ba, sử dụng niêm phong khuyến khích thành phần trên thừa kế, đó là một thói quen tốt để có được vào. Sử dụng thành phần trên thừa kế có nghĩa là bạn không thể phá vỡ nguyên tắc thay thế của Liskov và bạn đang tuân theo nguyên tắc Mở / Đóng. sealeddo đó là một từ khóa hỗ trợ bạn tuân theo hai trong số năm nguyên tắc quan trọng nhất của lập trình oo. Tôi muốn nói rằng làm cho nó một tính năng rất có giá trị.

Tôi nghĩ rằng câu hỏi này không có câu trả lời khách quan và tất cả phụ thuộc vào quan điểm của bạn.

Một bên, một số người muốn mọi thứ "mở" và gánh nặng đảm bảo mọi thứ hoạt động chính xác là ở người mở rộng lớp học. Đây là lý do tại sao các lớp được mở để kế thừa theo mặc định. Và tại sao các phương thức Java đều là ảo theo mặc định.

Mặt khác, một số người muốn mọi thứ được đóng theo mặc định và cung cấp các tùy chọn để mở nó. Trong trường hợp này, tác giả của lớp cơ sở, người cần đảm bảo mọi thứ anh ta làm "mở" đều an toàn để sử dụng theo bất kỳ cách nào có thể tưởng tượng được. Đây là lý do tại sao trong C #, tất cả các phương thức đều không ảo theo mặc định và cần được khai báo ảo để được ghi đè. Nó cũng dành cho những người đó, đó là cách để tránh các mặc định "mở". Giống như làm cho lớp bị niêm phong / cuối cùng, bởi vì họ thấy ai đó xuất phát từ lớp là một vấn đề lớn đối với thiết kế của lớp họ.

vấn đề với niêm phong trong C # là nó khá cuối cùng. Trong 7 năm phát triển thương mại C #, nơi duy nhất tôi thấy nó được sử dụng là trên các lớp Microsoft .NET, nơi tôi cảm thấy mình có lý do chính đáng để mở rộng một lớp khung để thực hiện hành vi được điều chỉnh và vì lớp này đã bị niêm phong, tôi không thể .

Không thể viết một lớp suy nghĩ về mọi cách có thể được sử dụng, và quyết định rằng không ai trong số chúng là hợp pháp. Tương tự như vậy nếu bảo mật khung phụ thuộc vào lớp không được kế thừa, thì bạn có một lỗi thiết kế bảo mật.

Vì vậy, kết luận, tôi chắc chắn về quan điểm rằng niêm phong không phục vụ mục đích hữu ích và cho đến nay tôi chưa đọc được gì ở đây đã thay đổi quan điểm đó.

Tôi có thể thấy cho đến nay đã có ba đối số biện minh được niêm phong cho đến nay.

1. Luận điểm 1 là nó loại bỏ một nguồn lỗi khi mọi người thừa hưởng từ các lớp và sau đó đã tăng quyền truy cập vào các phần bên trong của lớp đó mà không thực sự hiểu đúng về các phần bên trong.

2. Đối số 2 là nếu bạn mở rộng một lớp microsoft và sau đó microsoft thực hiện sửa lỗi trong lớp đó nhưng sự gia hạn của bạn dựa vào lỗi đó thì mã của bạn đã bị hỏng, microsoft bị đổ lỗi và bịt kín ngăn chặn điều đó

3. Đối số 3 là với tư cách là nhà phát triển của lớp, lựa chọn của tôi có cho phép bạn mở rộng nó hay không, như là một phần trong thiết kế của lớp tôi.

Đối số 1 dường như là một đối số mà bạn lập trình viên cuối không biết cách sử dụng mã của tôi. Đó có thể là trường hợp, nhưng nếu bạn vẫn cho phép tôi truy cập vào giao diện đối tượng thì vẫn đúng là tôi đang sử dụng đối tượng của bạn và thực hiện các cuộc gọi đến nó mà không hiểu cách sử dụng nó, và do đó có thể gây ra nhiều thiệt hại theo cách đó . Đây là một lời biện minh yếu ớt về sự cần thiết phải niêm phong.

Tôi hiểu cơ sở thực tế cho arg 2 đến từ đâu. Đặc biệt, khi microsoft đưa các kiểm tra hệ điều hành bổ sung vào các cuộc gọi api win32 để xác định các cuộc gọi không đúng định dạng, điều này đã cải thiện tính ổn định chung của Windows XP so với Windows NT, nhưng với chi phí ngắn hạn, nhiều ứng dụng đã bị hỏng khi Windows XP được phát hành. Microsoft đã giải quyết vấn đề này bằng cách đặt 'quy tắc' cho các kiểm tra này để nói, bỏ qua khi ứng dụng X phá vỡ quy tắc này, đây là một lỗi đã biết

Đối số 2 là một đối số kém vì được niêm phong tốt nhất không có gì khác biệt bởi vì nếu có lỗi trong thư viện .NET, bạn không có lựa chọn nào khác ngoài việc tìm một công việc xung quanh và khi sửa lỗi microsoft xuất hiện, rất có khả năng có nghĩa là công việc của bạn xung quanh phụ thuộc vào hành vi bị hỏng bây giờ bị phá vỡ. Cho dù bạn đã khắc phục điều này bằng cách sử dụng tính kế thừa hoặc bằng một số mã trình bao bọc bổ sung khác, khi mã được sửa, công việc của bạn sẽ bị hỏng.

Đối số 3 là đối số duy nhất có bất kỳ chất nào để tự biện minh cho chính nó. Nhưng nó vẫn còn yếu. Nó chỉ đi ngược lại với hạt tái sử dụng mã.

Tôi chỉ sử dụng sealedtừ khóa trên các lớp chỉ chứa các phương thức tĩnh.

Bằng chứng là câu hỏi của tôi, tôi không có chuyên gia ở đây. Nhưng tôi thấy không có lý do gì sealedđể tồn tại.

Nó dường như được thực hiện để giúp các kiến ​​trúc sư mã để thiết kế một giao diện. Nếu bạn muốn viết một lớp sẽ ra ngoài tự nhiên và nhiều người sẽ thừa hưởng từ nó, sửa đổi bất cứ điều gì trong lớp đó có thể phá vỡ nó cho quá nhiều người. Vì vậy, chúng tôi có thể niêm phong nó và không ai có thể thừa kế. "Vấn đề được giải quyết".

Chà, có vẻ như "che một chỗ và phát hiện ra một điểm khác". Và nó thậm chí không giải quyết được vấn đề - nó chỉ loại bỏ một công cụ : thừa kế. Là bất kỳ công cụ nào, nó có nhiều công dụng và kế thừa từ một lớp không ổn định là rủi ro bạn gặp phải. Ai chấp nhận rủi ro đó thì nên biết rõ hơn.

Có lẽ có thể có một từ khóa stable, vì vậy mọi người sẽ biết rằng an toàn hơn khi kế thừa từ đó.