Các lớp cơ sở trừu tượng lớn

Question

Tôi đang viết một lớp cơ sở trừu tượng lớn với 30 phương thức thuần túy ảo *.

Tìm tất cả các chức năng để thực hiện trong một lớp cơ sở trong các lớp thực hiện là một chút buồn tẻ, chủ yếu là vì MSVC++ không cho bạn biết có chức năng bạn thất bại trong việc thực hiện với lỗi biên dịch "Không thể xây dựng lớp trừu tượng"

Vì vậy, tôi tự hỏi là lớp cơ sở trừu tượng lớn của tôi là một ý tưởng tồi, hoặc tôi nên chia nó thành nhiều giao diện, hoặc có một cảnh báo trình biên dịch tôi có thể kích hoạt mà sẽ cho tôi biết phương pháp nào tôi không cung cấp .. hay đây chỉ là một phần của việc viết mã với các lớp trừu tượng và tôi nên quen với nó.

_{* Những gì nó cung cấp là lớp chức năng chung giữa một vài hệ thống con hiển thị khác nhau.}

Answer 1

Không có câu trả lời đúng cho câu hỏi này. Việc quyết định có tách rời lớp cơ sở thành nhiều lớp cơ sở trừu tượng có lẽ là quyết định của bạn hay không dựa trên cơ sở có hay không lớp cơ sở logic đại diện cho một số khái niệm khác nhau. Nếu lý do duy nhất bạn làm điều này là cho các thông báo lỗi trình biên dịch, bạn có thể muốn kiểm tra và xem liệu bạn có thể nâng cấp trình biên dịch hoặc nếu có một số lý do khác để làm điều này. Hầu hết các trình biên dịch hiện đại nên cung cấp các lỗi chi tiết, rất đẹp về điều này.

Tách giao diện thành nhiều phần có thể là một ý tưởng hay nếu thiết kế của bạn gợi ý rằng bạn có thể thực sự muốn có nhiều lớp khác nhau chỉ triển khai các phần nhỏ của lớp cơ sở. Nếu bạn mong đợi để làm điều này, nó có thể được thuận lợi để yếu tố giao diện ngoài. Bạn sẽ thấy một số phức tạp thêm từ này, tuy nhiên. Ví dụ, nếu bạn có một con trỏ của một kiểu giao diện cho một đối tượng đang triển khai nhiều giao diện, bạn có thể phải thực hiện một số kiểu cross-cast để có được kiểu đúng hoặc bạn có thể phải giới thiệu một lớp trừu tượng mới đại diện cho một cái gì đó kế thừa từ tất cả các loại giao diện khác nhau. Nhiều thừa kế với các lớp giao diện cũng có thể dẫn đến một số xung đột tên, mặc dù điều này thường không phải là vấn đề nếu các giao diện được thiết kế chính xác.

Tóm lại, tôi khuyên bạn không nên làm điều này vì lý do lỗi trình biên dịch, nhưng nếu bạn nghĩ đó là một quyết định thiết kế tốt thì tất cả có nghĩa là đi cho nó. Trình biên dịch là đủ tốt những ngày này mà bạn hiếm khi (nhưng không bao giờ) cần phải xây dựng thiết kế của bạn xung quanh chúng.

Answer 2

Lớp giao diện theo ý kiến ​​của tôi vốn dĩ không tốt, tuy nhiên câu hỏi đặt ra khiến ứng dụng cụ thể này nghi ngờ âm thanh.

Nếu bạn có các lớp bắt nguồn từ giao diện này và không rõ chính xác bạn cần ghi đè những hàm nào, điều đó có vẻ chỉ ra rằng tất cả các hàm đó có thể không cần thiết.

Khi bạn tạo lớp cơ sở trừu tượng, số phương pháp ảo thuần túy không quan trọng (đối với tôi), nhưng phải rõ ràng lý do tại sao mỗi lớp xuất phát từ giao diện này phải triển khai từng hàm ảo thuần túy. Nếu bạn thấy mình suy nghĩ "Tại sao tôi phải thực hiện chức năng này?", Nó có thể thích hợp để chia lớp trừu tượng thành nhiều giao diện riêng biệt.

Answer 3

Dù sao một lớp học lớn như vậy là một mớ hỗn độn, lớp học chống lại Thượng đế. Sử dụng tập hợp/thành phần để phân chia một lớp và xem xét các nguyên tắc phát triển SOLID, có vẻ như 30 phương pháp cho một lớp không tuân theo nguyên tắc trách nhiệm duy nhất, ít nhất ... vì vậy tôi wold như đề nghị xem xét lại một thiết kế của lớp. Chúc may mắn!

Answer 4

Thông thường, ngay sau lỗi "Không thể khởi tạo lớp trừu tượng" (được ném vào dòng nó được gọi), nếu bạn đã sao chép và dán giao diện vào lớp trước khi viết triển khai, bạn sẽ gặp lỗi liên kết "Lỗi bên ngoài chưa được giải quyết" trỏ đến phương pháp bạn quên triển khai.