Hình vuông KẾ THỪA hình chữ nhật, và một hàm không hề biết nó tồn tại in ra 16 thay vì 20
Mỗi nguyên tắc SOLID một đoạn mã trước và sau, cùng phép thử chạy được cho thấy vi phạm Liskov làm hỏng hàm không hề biết gì về lớp con.
Mỗi nguyên tắc SOLID một đoạn mã trước và sau, cùng phép thử chạy được cho thấy vi phạm Liskov làm hỏng hàm không hề biết gì về lớp con.
Bốn loại lớp lồng, một đoạn phản chiếu lôi ra tận mắt cái trường this$0 do trình biên dịch thêm vào, vì sao nó là nguồn của những vụ rò rỉ bộ nhớ khó tìm nhất, và vì sao mặc định nên đặt static.
Interface có phương thức default từ Java 8 nên ranh giới mờ đi nhiều. Hai thứ còn khác thật sự — giữ trạng thái và số lượng kế thừa được — cùng hai câu hỏi để chọn và một ví dụ chuyển từ lớp trừu tượng sang interface.
Phương thức được chọn theo đối tượng thật lúc chạy, trường được chọn theo kiểu khai báo lúc biên dịch. Mở bytecode ra là thấy ngay: invokevirtual tra bảng lúc chạy, getfield chốt chỉ mục lúc dịch — cùng một đối tượng cho ra hai kết quả.
Cùng một lớp đếm số lượt thêm, kế thừa HashSet cho ra 6 còn giữ một Set bên trong cho ra 3 — vì addAll âm thầm gọi add. Vì sao 'kế thừa phá vỡ đóng gói', và ba câu hỏi để biết khi nào kế thừa vẫn đúng.
Bốn mức truy cập của Java qua thông báo lỗi thật của javac, cái luật protected mà ít người biết (chỉ qua tham chiếu kiểu chính nó), vì sao mức mặc định bị đánh giá thấp, và lý do sinh getter/setter cho mọi trường là thói quen nên bỏ.