Thực hành tốt nhất để sử dụng công cộng, bảo vệ, tư nhân?


12

Có công bằng không khi nói rằng đó là một thực tiễn tốt để mặc định mọi thứ privatelên phía trước khi mã hóa một cái gì đó?

Và sau đó chỉ nâng cấp nó lên protectednếu một lớp con cần nó, hoặc publicnếu một lớp khác cần nó?


2
Nếu bạn đang tạo một số API, bạn cần dự đoán chức năng mà người gọi có thể cần. Do đó, bạn sẽ cần suy nghĩ nhiều hơn vào công cụ sửa đổi truy cập của mình. Nó phụ thuộc vào người đang sử dụng mã mà bạn đang viết.
2023861

Câu trả lời:


10

Câu trả lời ngắn gọn:

Câu trả lời dài hơn:

Có, nhưng điều đó không nên được hiểu là một gợi ý để bắt đầu bằng cách viết các lớp học của bạn với mọi thứ riêng tư; Cách tiếp cận đó ngụ ý thiết kế lớp bằng cách tập trung vào chi tiết triển khai trước khi bạn giải quyết trên một giao diện.

Một trong những khía cạnh quan trọng nhất cần xem xét khi thiết kế một lớp là cách nó sẽ được sử dụng; bao gồm suy nghĩ về các phương pháp công khai của bạn trước khi bạn bắt đầu nghĩ về các chi tiết riêng tư / triển khai.

Hơn nữa, cách tiếp cận đó thường bỏ lỡ cơ hội để tự hỏi "Làm thế nào tôi có thể viết một bài kiểm tra đơn vị cho lớp này?" - đó là một câu hỏi quan trọng để hỏi ngay cả khi bạn không thực sự viết bài kiểm tra đơn vị. (Liên quan: "các nguyên tắc thiết kế thúc đẩy mã thử nghiệm là gì?" )

Vì vậy, một khi bạn đã xác định giao diện công cộng, thì nên mặc định phần còn lại là riêng tư vì phần lớn đó thường là chi tiết triển khai không đáng lo ngại, không liên quan đến bất cứ điều gì bên ngoài lớp.


Vì vậy, nếu tôi cố gắng tóm tắt những gì bạn đang nói lại với bạn (để xem tôi có hiểu không), thì tốt nhất là bạn nên nghĩ đến giao diện công khai trước tiên (ví dụ như lớp này thực sự được sử dụng bởi bên ngoài để bắt đầu với?) và sau đó làm cho mọi thứ khác riêng tư?
AJJ

1
@ArukaJ Một cách tiếp cận tốt là viết mã sẽ sử dụng các lớp của bạn trước khi bạn xây dựng triển khai. Đây có thể là một chút vấn đề về gà hoặc trứng cho đến khi bạn bắt đầu viết bài kiểm tra đơn vị trước.
JimmyJames

1
@ArukaJ Rộng rãi có; điều mà thoạt đầu có vẻ khó thực hiện hơn, mặc dù như JimmyJames đề cập, nó cảm thấy trực quan hơn rất nhiều khi bạn viết bài kiểm tra đơn vị. Nó có thể liên quan đến một suy nghĩ hơi khác, nhưng mục tiêu là suy nghĩ kỹ hơn về những gì lớp của bạn thể hiện, và đầu vào / đầu ra của bạn trông như thế nào - nói chung đó chỉ là cách nghĩ "OO" hơn về thiết kế; nhiều khả năng dẫn đến các lớp đóng gói gọn gàng với sự gắn kết cao.
Ben Cottrell

Tôi không thích sử dụng các bài kiểm tra đơn vị để thiết kế lớp học của mình, bởi vì các bài kiểm tra đơn vị không phải là những người thực sự sẽ sử dụng nó. Tuy nhiên, họ chắc chắn tốt hơn không có gì trong việc suy nghĩ làm thế nào lớp sẽ được sử dụng.
dùng949300

8

"Và sau đó chỉ nâng cấp nó lên được bảo vệ nếu một lớp con cần nó, hoặc công khai nếu một lớp khác cần nó?"

Đó là cách tiếp cận sai. Tại thời điểm thiết kế, bạn nên biết những gì bạn muốn cung cấp truy cập công cộng . Thông thường bạn cung cấp quyền truy cập công cộng vì đó là toàn bộ mục đích của lớp học của bạn. Và bạn cung cấp quyền truy cập được bảo vệ bởi vì bạn muốn các lớp con truy cập vào mọi thứ. Và bạn sử dụng riêng tư cho những thứ không phải là việc của ai khác.

Bây giờ nếu ai đó cần quyền truy cập vào những thứ họ không thể truy cập, thì bạn nên suy nghĩ thực sự khó khăn về nhu cầu đó . Họ không cần quyền truy cập đó, hoặc thiết kế của bạn sai. Có lẽ thiết kế của bạn sai, và một cái gì đó không được công khai nên được công khai, vì vậy bạn thay đổi điều đó. Nhưng nếu thiết kế của bạn là đúng, thì có một cái gì đó không đúng với nhu cầu , vì vậy bạn sửa thay vì làm hỏng thiết kế của bạn.


Hãy nói rằng bạn có một lớp học mà bạn không có ý định để lớp con vào thời điểm này (và có thể không bao giờ cần phải) và một phương pháp mà nếu bạn phải phân lớp lớp học của bạn, sẽ có ích / phải / bởi các lớp con. Bạn sẽ thực hiện phương pháp đó privatehay protected?
lfk

Nên là câu trả lời được chấp nhận, làm cho mọi thứ riêng tư thoạt nghe giống như tôi không muốn nghĩ / thiết kế.
Niing

2

Chìa khóa để hiểu khía cạnh này của lập trình hướng đối tượng là khái niệm đóng gói dữ liệu . Ý tưởng là làm cho một lớp dễ hiểu hơn bằng cách ẩn các chi tiết thực hiện của nó. Điều này được gọi là ẩn dữ liệu . Vì vậy, chúng tôi chỉ muốn đưa ra (công khai) những chức năng cần thiết để sử dụng lớp. Các chức năng này là giao diện cho lớp.

Hãy nghĩ về một giao diện giống như bánh xe của một chiếc xe hơi. Bạn quyết định xe đi theo hướng nào bằng cách quay bánh xe, nhưng bên dưới vỏ có các van quay, thủy lực, ròng rọc thay đổi vòng quay của bánh xe, nhưng bạn không cần phải là kỹ sư cơ khí để lái xe.

Vì vậy, câu trả lời cho câu hỏi của bạn là có. Bạn muốn ẩn càng nhiều chi tiết về một lớp từ các lớp khác càng tốt. Hiểu khi nào một cái gì đó nên công khai, riêng tư hoặc được bảo vệ là dễ học nhưng khó để thành thạo.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.