Công cụ sửa đổi truy cập, ghi đè phương thức và triển khai các phương thức trừu tượng

"Tôi sẽ nói với bạn về « công cụ sửa đổi truy cập ». Tôi đã nói về chúng một lần trước đây, nhưng sự lặp lại là trụ cột của việc học."

Bạn có thể kiểm soát quyền truy cập (khả năng hiển thị) mà các lớp khác có đối với các phương thức và biến của lớp bạn. Công cụ sửa đổi truy cập trả lời câu hỏi «Ai có thể truy cập phương thức/biến này?». Bạn chỉ có thể chỉ định một công cụ sửa đổi cho mỗi phương thức hoặc biến.

1) công cụ sửa đổi « công khai ».

Một biến, phương thức hoặc lớp được đánh dấu bằng công cụ sửa đổi công khai có thể được truy cập từ bất kỳ đâu trong chương trình. Đây là mức độ mở cao nhất: không có hạn chế.

2) công cụ sửa đổi « riêng tư ».

Một biến, phương thức hoặc lớp được đánh dấu bằng công cụ sửa đổi riêng tư chỉ có thể được truy cập trong lớp nơi nó được khai báo. Phương thức hoặc biến được đánh dấu bị ẩn khỏi tất cả các lớp khác. Đây là mức độ riêng tư cao nhất: chỉ lớp học của bạn mới có thể truy cập được. Các phương thức như vậy không được kế thừa và không thể bị ghi đè. Ngoài ra, chúng không thể được truy cập trong lớp con.

3)  « Công cụ sửa đổi mặc định ».

Nếu một biến hoặc phương thức không được đánh dấu bằng bất kỳ công cụ sửa đổi nào, thì nó được coi là được đánh dấu bằng công cụ sửa đổi "mặc định". Các biến và phương thức với công cụ sửa đổi này được hiển thị cho tất cả các lớp trong gói nơi chúng được khai báo và chỉ cho các lớp đó. Công cụ sửa đổi này còn được gọi là quyền truy cập " gói " hoặc " gói riêng ", gợi ý thực tế rằng quyền truy cập vào các biến và phương thức được mở cho toàn bộ gói chứa lớp.

4) công cụ sửa đổi « được bảo vệ ».

Mức truy cập này rộng hơn một chút so với gói . Một biến, phương thức hoặc lớp được đánh dấu bằng công cụ sửa đổi được bảo vệ có thể được truy cập từ gói của nó (như "gói") và từ tất cả các lớp kế thừa.

Bảng này giải thích tất cả:

Có một cách để dễ dàng ghi nhớ bảng này. Hãy tưởng tượng rằng bạn đang viết di chúc. Bạn đang chia mọi thứ của mình thành bốn loại. Ai được sử dụng những thứ của bạn?

"Giống như tưởng tượng rằng các lớp học trong cùng một gói là một phần của một gia đình."

"Tôi cũng muốn cho bạn biết một số sắc thái thú vị về các phương pháp ghi đè."

1) Thực hiện ngầm định một phương thức trừu tượng.

Giả sử bạn có đoạn mã sau:

class Cat
{
 public String getName()
 {
  return "Oscar";
 }
}

Và bạn đã quyết định tạo một lớp Tiger kế thừa lớp này và thêm giao diện cho lớp mới

class Cat
{
 public String getName()
 {
   return "Oscar";
 }
}

interface HasName
{
 String getName();
 int getWeight();
}

class Tiger extends Cat implements HasName
{
 public int getWeight()
 {
  return 115;
 }

}

Nếu bạn chỉ triển khai tất cả các phương thức còn thiếu mà IntelliJ IDEA yêu cầu bạn triển khai, thì sau này, bạn có thể sẽ mất nhiều thời gian để tìm lỗi.

Nó chỉ ra rằng lớp Tiger có một phương thức getName kế thừa từ Cat, phương thức này sẽ được coi là triển khai phương thức getName cho giao diện HasName.

"Tôi không thấy có gì khủng khiếp về điều đó."

"Cũng không tệ lắm, có khả năng phạm sai lầm."

Nhưng nó có thể còn tồi tệ hơn:

interface HasWeight
{
 int getValue();
}

interface HasSize
{
 int getValue();
}

class Tiger extends Cat implements HasWeight, HasSize
{
 public int getValue()
 {
  return 115;
 }
}

Hóa ra không phải lúc nào bạn cũng có thể kế thừa từ nhiều giao diện. Chính xác hơn, bạn có thể kế thừa chúng, nhưng bạn không thể triển khai chúng một cách chính xác. Nhìn vào ví dụ. Cả hai giao diện đều yêu cầu bạn triển khai phương thức getValue(), nhưng không rõ nó sẽ trả về cái gì: trọng lượng hay kích thước? Điều này là khá khó chịu để phải đối phó với.

"Tôi đồng ý. Bạn muốn triển khai một phương thức, nhưng bạn không thể. Bạn đã kế thừa một phương thức có cùng tên từ lớp cơ sở. Nó bị hỏng."

"Nhưng có một tin tốt."

2) Mở rộng tầm nhìn. Khi kế thừa một kiểu, bạn có thể mở rộng khả năng hiển thị của một phương thức. Cái này nó thì trông như thế nào:

class Cat
{
 protected String getName()
 {
  return "Oscar";
 }
}

class Tiger extends Cat
{
 public String getName()
 {
  return "Oscar Tiggerman";
 }
}

public static void main(String[] args)
{
 Cat cat = new Cat();
 cat.getName();
}

public static void main(String[] args)
{
 Tiger tiger = new Tiger();
 tiger.getName();
}

public static void main(String[] args)
{
 Cat catTiger = new Tiger();
 catTiger.getName();
}

"Tôi không chắc mình đã hoàn toàn hiểu, nhưng tôi sẽ nhớ rằng điều này là có thể."

3) Thu hẹp loại trả về.

Trong một phương thức được ghi đè, chúng ta có thể thay đổi kiểu trả về thành kiểu tham chiếu thu hẹp.

class Cat
{
 public Cat parent;
 public Cat getMyParent()
 {
  return this.parent;
 }
 public void setMyParent(Cat cat)
 {
  this.parent = cat;
 }
}

class Tiger extends Cat
{
 public Tiger getMyParent()
 {
  return (Tiger) this.parent;
 }
}

public static void main(String[] args)
{
 Cat parent = new Cat();

 Cat me = new Cat();
 me.setMyParent(parent);
 Cat myParent = me.getMyParent();
}

public static void main(String[] args)
{
 Tiger parent = new Tiger();

 Tiger me = new Tiger();
 me.setMyParent(parent);
 Tiger myParent = me.getMyParent();
}

public static void main(String[] args)
{
 Tiger parent = new Tiger();

 Cat me = new Tiger();
 me.setMyParent(parent);
 Cat myParent = me.getMyParent();
}

"Vâng. Hiểu rồi. Khi ghi đè các phương thức, bạn phải biết tất cả những thứ này hoạt động như thế nào nếu chúng ta chuyển các đối tượng của mình sang mã chỉ có thể xử lý lớp cơ sở và không biết gì về lớp của chúng ta. "

"Chính xác! Sau đó, câu hỏi lớn là tại sao chúng ta không thể thu hẹp loại giá trị trả về khi ghi đè một phương thức?"

"Rõ ràng là trong trường hợp này, mã trong lớp cơ sở sẽ ngừng hoạt động:"

class Cat
{
 public Cat parent;
 public Cat getMyParent()
 {
  return this.parent;
 }
 public void setMyParent(Cat cat)
 {
  this.parent = cat;
 }
}

class Tiger extends Cat
{
 public Object getMyParent()
 {
  if (this.parent != null)
   return this.parent;
  else
   return "I'm an orphan";
 }
}

public static void main(String[] args)
{
 Tiger parent = new Tiger();

 Cat me = new Tiger();
 Cat myParent = me.getMyParent();
}

"Ví dụ tuyệt vời, Amigo!"

Trong Java, trước khi một phương thức được gọi, không có kiểm tra xem đối tượng có phương thức đó hay không. Tất cả các kiểm tra xảy ra trong thời gian chạy. Và một cuộc gọi [giả thuyết] đến một phương thức bị thiếu rất có thể sẽ khiến chương trình cố thực thi mã byte không tồn tại. Điều này cuối cùng sẽ dẫn đến một lỗi nghiêm trọng và hệ điều hành sẽ buộc phải đóng chương trình.

"Chà. Giờ thì tôi biết rồi."