Chúng ta có thể nói các đối tượng có thuộc tính, trạng thái và hành vi?

Tôi đã đọc qua phần giới thiệu của Oracle về các khái niệm OOP và tôi đã xem qua mô tả này:

Các đối tượng trong thế giới thực có chung hai đặc điểm: Tất cả chúng đều có trạng thái và hành vi. Chó có trạng thái (tên, màu sắc, giống, đói) và hành vi (sủa, tìm nạp, vẫy đuôi). Các đối tượng phần mềm tương tự về mặt khái niệm với các đối tượng trong thế giới thực: chúng cũng bao gồm trạng thái và hành vi liên quan.

Vấn đề của tôi với đoạn văn đó là khi mô tả trạng thái trộn lẫn các thuộc tính của nó ở đó. Ví dụ, tên và màu sắc của một con chó là thuộc tính của nó, trong khi nó đang đói hoặc thursty là trạng thái của nó.

Vì vậy, theo tôi, chính xác hơn là chia các đặc điểm của các đối tượng thành ba phần: thuộc tính, trạng thái và hành vi .

Chắc chắn, khi dịch ngôn ngữ này sang ngôn ngữ lập trình tôi có thể thấy rằng phân vùng ba lần trở thành một phân chia hai lần, bởi vì cả hai thuộc tính và trạng thái sẽ được lưu trữ vào các trường / biến, trong khi các hành vi sẽ được lưu trữ vào các phương thức / hàm.

Nhưng về mặt khái niệm, nó có ý nghĩa hơn để có 3 điều riêng biệt.

Đây là một ví dụ khác: xem xét một đèn. Nói rằng cả kích thước đèn và dù nó có bật hay không đều là trạng thái theo quan điểm của tôi. Kích thước đèn là một thuộc tính, không phải là trạng thái, trong khi nó được bật hoặc tắt là trạng thái.

Hay tôi đã bỏ lỡ điều gì?

Bạn đúng trong các đối tượng bao gồm các thuộc tính, trạng thái và hành vi, nếu bạn xác định các thuộc tính có nghĩa là các đặc điểm không thay đổi của một thể hiện. Như một vấn đề thực tế, điều quan trọng là phải tạo ra sự khác biệt này, bởi vì tồn tại các đối tượng chỉ chứa các thuộc tính, (theo nghĩa của bạn) và không có trạng thái; chúng được gọi là bất biến và chúng rất hữu ích trong lập trình.

Định nghĩa ba phần này thực sự được thể hiện bằng các ngôn ngữ lập trình, ví dụ sử dụng finaltừ khóa trong Java hoặc readonlytừ khóa trong C # để biểu thị dữ liệu cá thể có thể không thay đổi trong suốt thời gian tồn tại của cá thể.

Tuy nhiên, tôi phải thêm rằng dữ liệu cá thể không thay đổi thường không được gọi là thuộc tính. Chúng tôi có xu hướng nói về chúng như 'cuối cùng' hoặc 'chỉ đọc' hoặc 'dữ liệu không đổi' tùy thuộc vào ngôn ngữ chúng tôi đang sử dụng. Thuật ngữ thích hợp cho chúng sẽ là 'bất biến', nhưng sau đó từ này không được sử dụng thường xuyên theo nghĩa này; nó thường được sử dụng cho những thứ khác.

Tôi nghĩ chính xác hơn khi nói các đối tượng chỉ có hai đặc điểm. Lấy ví dụ của Oracle:

Chó có trạng thái (tên, màu sắc, giống, đói) và hành vi (sủa, tìm nạp, vẫy đuôi). Các đối tượng phần mềm tương tự về mặt khái niệm với các đối tượng trong thế giới thực: chúng cũng bao gồm trạng thái và hành vi liên quan.

Thực tế là các giá trị (trạng thái) cho tên, màu sắc, giống và đói được lưu trữ trong đối tượng trong các thuộc tính là một chi tiết triển khai. Bạn thực sự không cần thuộc tính.

Nếu bạn sẽ bao gồm các thuộc tính như một đặc tính thứ ba, thì bạn cũng phải bao gồm các phương thức như một thứ tư, vì các hành vi (như trạng thái) của các đối tượng cũng có thể thay đổi. Nhà nước và hành vi là hai đặc điểm trừu tượng của các đối tượng. Các thuộc tính và phương pháp là các triển khai cụ thể của các khái niệm đó.

Trạng thái được đặt các thuộc tính và giá trị tương ứng, vì vậy theo quan điểm của tôi, bạn không đúng (và bạn đang tạo độ phức tạp bổ sung không cần thiết cho định nghĩa đơn giản).

Chúng ta có thể phân loại mọi thứ theo vô số cách và mỗi phân loại sẽ không có "câu trả lời đúng". Có một lợi ích để phân loại mọi thứ chỉ khi phân loại dẫn đến một số hiểu biết sâu sắc hơn hoặc để cải thiện giao tiếp. Nếu nhóm của bạn thích sử dụng các thuộc tính thuật ngữ, trạng thái và chức năng và có định nghĩa hoạt động tốt cho những điều này sẽ giúp cải thiện giao tiếp nội bộ nhưng bạn cần phải linh hoạt khi giao tiếp bên ngoài nhóm này.

Các khái niệm "đói" và "khát" có thể được bắt nguồn từ các thuộc tính cơ bản (ví dụ: đường huyết, mức độ hydrat hóa) để chúng ta có thể nghĩ về trạng thái như một thuộc tính meta có nguồn gốc từ các thuộc tính cơ bản mà chúng ta có thể chuyển thành Đúng hoặc Sai dựa trên trạng thái của các thuộc tính cơ sở có liên quan. Đối với ví dụ ánh sáng, chúng ta có thể nghĩ về ánh sáng là có các thuộc tính applied_voltagevà resistancevà các chức năng voltage_switch()và shine(). Sau voltage_swich()đó, đây là một chức năng của một số đầu vào (ví dụ: chuyển đổi thủ công, ánh sáng, hẹn giờ, v.v.) và shine()là một chức năng của applied_voltagevà resistance. Chúng ta có thể khai báo một thuộc tính meta được gọi light_statelà Đúng hoặc Sai để giúp xây dựng đối tượng về mặt tinh thần, nhưng cuối cùng, những ý tưởng này chỉ là những cấu trúc tinh thần mà chúng ta sử dụng để tổ chức công việc.

Trạng thái của một đối tượng được mã hóa trong các thuộc tính của nó, trực tiếp hoặc gián tiếp. Ví dụ, nếu bạn muốn Chó của bạn khát, bạn có thể để nó có

private boolean thirsty;

Ngoài ra, bạn có thể để nó có cái gì đó như

private Date lastDrinkAt;

và kết luận liệu cá thể chó của bạn có khát nước hay không bằng cách so sánh thời gian hiện tại với thời gian nó uống thứ gì đó.

Dù bằng cách nào, trạng thái của các đối tượng của bạn nằm trong các thuộc tính của nó.

Sau đó, có các lớp không có thuộc tính, chủ yếu là các lớp tiện ích. Nhưng bạn thường không muốn tạo một thể hiện của chúng trong trường hợp này.

Để có thể suy luận về các tuyên bố, các nhà khoa học thường tuân theo nguyên tắc tối thiểu. Tôi nghĩ đó là lý do tại sao Oracle không đề cập đến trạng thái rõ ràng. Nó có thể được bắt nguồn từ giá trị của các thuộc tính.

Các kết nối trong thế giới thực là sai lầm. Đây là cách tôi sẽ dạy nó (cách tiếp cận c ++):

1. Máy tính hỗ trợ hai định dạng lưu trữ khác nhau: dữ liệu và mã
2. dữ liệu trông giống như bit 010101010101
3. mã trông giống như hướng dẫn asm
4. bit dữ liệu có hai giá trị khác nhau, đó là 0 hoặc 1
5. dữ liệu được trừu tượng hóa thành các loại dữ liệu: int i = 1; chỉ là ký hiệu ngắn cho một số bit 0000001
6. mã sẽ trông giống như một hàm: int f (int a) {return a + a + a; } là ký hiệu ngắn cho một số hướng dẫn asm
7. Khi bạn có một vài biến, bạn kết hợp chúng thành một cấu trúc: int a; phao b; có thể được đặt vào một cấu trúc AB {int a; phao b; };
8. khi bạn kết hợp một số đoạn mã với nó, bạn sẽ có được một lớp: class ABf {int a; phao b; float tổng (float c) const {return a + b + c; }};
9. Sau đó, đối với dữ liệu, chúng ta có các tên biến có thể được sử dụng để tìm giá trị: a + b + c để truy cập dữ liệu.
10. Và sau đó chúng ta có các lệnh gọi hàm bình thường: int k = f (10); để truy cập các lệnh asm "được lưu trữ" bên trong hàm f.
11. Sau đó, có các thể hiện đối tượng: ABf var;
12. Và hàm thành viên gọi: int k2 = var.sum (10.0);
13. hàm có kiểu int f (int);
14. các hàm thành viên có kiểu int ABf :: sum (float);
15. Có con trỏ này với kiểu ABf *
16. các biến như a và b và c phụ thuộc vào ngữ cảnh, nếu chúng nằm trong hàm thành viên, chúng có thể có nghĩa này-> b hoặc chỉ b.
17. Các hàm thành viên int ABf :: sum (float c) chỉ là ký hiệu ngắn cho int sum (ABf * this, float c);
18. từ "trạng thái" chỉ có nghĩa giống như dữ liệu
19. từ "hành vi" chỉ có nghĩa giống như mã
20. từ "thuộc tính" chỉ có nghĩa giống như dữ liệu.

Vì vậy, thực sự không có gì khác nhau giữa trạng thái và thuộc tính. Nó chỉ là tập hợp ngẫu nhiên của các bit. Nó chỉ là sự phân biệt tùy ý để phân tách chúng. Chỉ cần biết bí danh của nó để làm gì.