Thực thi giao diện – Phần 4

Giao diện rất giống như các lớp trừu tượng. Thật vậy, chúng ta có thể thay thế khai báo của <b>Istorable</b> trở thành một lớp trừu tượng:

Giao diện đối lập với lớp trừu tượng Bây giờ lớp Document có thể thừa kế từ lớp trừu tượng Istorable, và cũng không có gì khác nhiều so với việc sử dụng giao diện. Tuy nhiên, giả sử chúng ta mua một lớp List từ một hãng thứ ba và chúng ta muốn kết hợp với lớp có sẵn như Storable. Trong ngôn ngữ C++ chúng ta có thể tạo ra một lớp StorableList kế thừa từ List và cảStorable. Nhưng trong ngôn ngữ C# chúng ta không thể làm được, chúng ta không thể kế thừa từ lớp trừu tượng Storable và từ lớp List bởi vì trong C# không cho phép thực hiện đa kế thừa từ những lớp. Tuy nhiên, ngôn ngữ C# cho phép chúng ta thực thi bất cứ những giao diện nào và dẫn xuất từ một lớp cơ sở. Do đó, bằng cách làm cho Storable là một giao diện, chúng ta có thể kế thừa từ lớp List và cũng từIstorable. Ta có thể tạo lớp StorableList như sau: Thực thi phủ quyết giao diện Khi thực thi một lớp chúng ta có thể tự do đánh dấu bất kỳ hay tất cả các phương thức thực thi giao diện như là một phương thức ảo. Ví dụ, lớp Document thực thi giao diện Istorable và có thể đánh dấu các phương thức Read() và Write() như là phương thức ảo. Lớp Document có thể đọc và viết nội dung của nó vào một kiểu dữ liệu File. Những người phát triển sau có thể dẫn xuất một kiểu dữ liệu mới từ lớpDocument, có thể là lớp Note hay lớp EmailMessage, và những người này mong muốn lớp Note đọc và viết vào cơ sở dữ liệu hơn là vào một tập tin. Ví dụ 8.4 mở rộng từ ví dụ 8.3 và minh họa việc phủ quyết một thực thi giao diện. Phương thức Read()được đánh dấu như phương thức ảo và thực thi bởi Document.Read() và cuối cùng là được phủ quyết trong kiểu dữ liệu Note được dẫn xuất từ Document. Ví dụ 8.4: Phủ quyết thực thi giao diện. Kết quả: Trong ví dụ trên, lớp Document thực thi một giao diện đơn giản là Istorable: Người thiết kế của lớp Document thực thi phương thức Read() là phương thức ảo nhưng không tạo phương thức Write() tương tự như vậy: Trong ứng dụng thế giới thực, chúng ta cũng đánh dấu cả hai phương thức này là phương thức ảo. Tuy nhiên trong ví dụ này chúng ta minh họa việc người phát triển có thể tùy ý chọn các phương thức ảo của giao diện mà lớp thực thi. Một lớp mới Note dẫn xuất từ Document: Việc phủ quyết phương thức Read() trong lớp Note là không cần thiết, nhưng ở đây ta tự do làm điều này: Trong lớp Tester, phương thức Read() và Write() được gọi theo bốn cách sau: Thông qua lớp cơ sở tham chiếu đến đối tượng của lớp dẫn xuất : ♦ Thông qua một giao diện tạo từ lớp cơ sở tham chiếu đến đối tượng dẫn xuất. ♦ Thông qua một đối tượng dẫn xuất. ♦ Thông qua giao diện tạo từ đối tượng dẫn xuất. Thực hiện cách gọi thứ nhất, một tham chiếu Document được tạo ra, và địa chỉ của một đối tượng mới là lớp dẫn xuất Note được tạo trên heap và gán trở lại cho đối tượng Document: Một tham chiếu giao diện được tạo ra và toán tử as được sử dụng để gán Document cho tham chiếu giao diện Istorable: Sau đó gọi phương thức Read() và Write() thông qua giao diện. Kết xuất của phương thức Read() được thực hiện một cách đa hình nhưng phương thức Write() thì không, do đó ta có kết xuất sau: Phương thức Read() và Write() cũng được gọi trực tiếp từ bản thân đối tượng: và một lần nữa chúng ta thấy việc thực thi đa hình làm việc: Trong trường hợp này, phương thức Read() của lớp Note được gọi, và phương thức Write() của lớpDocument được gọi. Để chứng tỏ rằng kết quả này của phương thức phủ quyết, chúng ta tiếp tục tạo đối tượng Note thứ hai và lúc này ta gán cho một tham chiếu Note. Điều này được sử dụng để minh họa cho những trường hợp cuối cùng (gọi thông qua đối tượng dẫn xuất và gọi thông qua giao diện được tạo từ đối tượng dẫn xuất): Một lần nữa, khi chúng ta gán cho một tham chiếu, phương thức phủ quyết Read() được gọi. Tuy nhiên, khi những phương thức được gọi trực tiếp từ đối tượng Note: kết quả cho ta thấy rằng cách phương thức của Note được gọi chứ không phải của một phương thứcDocument: Hết phần 3