Czy możemy powiedzieć, że obiekty mają atrybuty, stany i zachowania?

Czytałem wprowadzenie Oracle do koncepcji OOP i natrafiłem na ten opis:

Rzeczywiste obiekty mają dwie cechy: wszystkie mają stan i zachowanie. Psy mają stan (imię, kolor, rasę, głodny) i zachowanie (szczekanie, ściąganie, machanie ogonem). Obiekty oprogramowania są koncepcyjnie podobne do obiektów w świecie rzeczywistym: one również składają się ze stanu i powiązanych zachowań.

Mój problem z tym fragmentem polega na tym, że opisując stan, również tam miesza atrybuty . Na przykład, nazwa i kolor psa to jego atrybuty, a jego głód lub zgorzknienie to jego stany.

Moim zdaniem dokładniejsze jest rozbicie cech obiektów na trzy części: atrybuty, stany i zachowania .

Jasne, tłumacząc to na język programowania, widzę, że trzykrotna partycja staje się dwukrotna, ponieważ zarówno atrybuty, jak i stany zostaną zapisane w polach / zmiennych, a zachowania w metodach / funkcjach.

Ale pod względem koncepcyjnym sensowniejsze jest oddzielenie 3 rzeczy.

Oto inny przykład: rozważ lampę. Stwierdzenie, że zarówno rozmiar lampy, jak i to, czy jest włączona, są stanami. Rozmiar lampy jest atrybutem, a nie stanem, natomiast włączenie lub wyłączenie jest stanem.

A może coś przeoczyłem?

Masz rację, że obiekty składają się z atrybutów, stanów i zachowania, jeśli zdefiniujesz atrybuty jako niezmienne cechy instancji. W rzeczywistości ważne jest dokonanie tego rozróżnienia, ponieważ istnieją obiekty, które zawierają tylko atrybuty (w twoim znaczeniu) i nie mają stanu; nazywa się je niezmiennymi i są bardzo przydatne w programowaniu.

Ta trzyczęściowa definicja jest rzeczywiście reprezentowana w językach programowania, na przykład za pomocą finalsłowa kluczowego w Javie lub readonlysłowa kluczowego w C # do oznaczenia danych instancji, które mogą się nie zmieniać przez cały okres istnienia instancji.

Muszę jednak dodać, że niezmienne dane instancji zwykle nie są nazywane atrybutami. Mówimy o nich jako o „ostatecznych”, „tylko do odczytu” lub „stałych danych” w zależności od używanego języka. Właściwym terminem dla nich byłyby „niezmienniki”, ale wtedy to słowo nie jest często używane w tym znaczeniu; jest częściej używany do innych rzeczy.

Myślę, że dokładniej jest powiedzieć, że obiekty mają tylko dwie cechy. Biorąc przykład Oracle:

Psy mają stan (imię, kolor, rasę, głodny) i zachowanie (szczekanie, ściąganie, machanie ogonem). Obiekty oprogramowania są koncepcyjnie podobne do obiektów w świecie rzeczywistym: one również składają się ze stanu i powiązanych zachowań.

Fakt, że wartości (stan) nazwy, koloru, rasy i głodowania są przechowywane w obiekcie w atrybutach, jest szczegółem implementacji. Tak naprawdę wcale nie potrzebujesz atrybutów.

Jeśli zamierzasz dołączyć atrybuty jako trzecią cechę, musisz również uwzględnić metody jako czwartą, ponieważ (podobnie jak stan) zachowania obiektów mogą się również zmienić. Stan i zachowanie to dwie abstrakcyjne cechy obiektów. Atrybuty i metody są konkretnymi implementacjami tych koncepcji.

Stan jest zbiorem atrybutów i odpowiadających im wartości, więc z mojego punktu widzenia nie masz racji (i tworzysz niepotrzebną dodatkową złożoność prostej definicji).

Możemy klasyfikować rzeczy na niezliczone sposoby, a każda klasyfikacja nie miałaby „właściwej odpowiedzi”. Zaletą klasyfikacji jest korzyść tylko wtedy, gdy klasyfikacja prowadzi do głębszego zrozumienia lub poprawy komunikacji. Jeśli Twój zespół woli używać terminów atrybuty, stany i funkcje i ma dla nich dobre definicje robocze, pomoże to poprawić komunikację wewnętrzną, ale musisz być elastyczny, komunikując się poza tą grupą.

Pojęcia „głodny” i „spragniony” można wyprowadzić z podstawowych atrybutów (np. Poziomu glukozy we krwi, poziomu nawodnienia), abyśmy mogli myśleć o stanie jako o meta-atrybucie, który jest pochodną atrybutów podstawowych, które możemy przekształcić w Prawda lub Fałsz na podstawie stan odpowiednich atrybutów podstawowych. Na przykład światła możemy uznać, że światło ma atrybuty applied_voltagei resistancefunkcje voltage_switch()oraz shine(). voltage_swich()Jest wówczas funkcją pewnej wejścia (np ręczny przełącznik, światło, zegara, etc.) i shine()jest funkcją applied_voltagei resistance. Możemy zadeklarować meta-atrybut o nazwie light_statePrawda lub Fałsz, aby pomóc mentalnie skonstruować obiekt, ale ostatecznie wszystkie te pomysły są tylko konstrukcjami mentalnymi, których używamy do organizowania naszej pracy.

Stan obiektu jest zakodowany w jego atrybutach, bezpośrednio lub pośrednio. Na przykład, jeśli chcesz, aby Twój pies był spragniony, możesz pozwolić mu mieć

private boolean thirsty;

Alternatywnie możesz pozwolić, aby coś takiego miało

private Date lastDrinkAt;

i stwierdź, czy Twój pies jest spragniony, porównując aktualny czas z czasem, kiedy coś wypił.

Tak czy inaczej, stan twoich obiektów leży w jego atrybutach.

Są też klasy, które nie mają atrybutów, głównie klasy użytkowe. Ale w tym przypadku zwykle nie chcesz tworzyć ich instancji.

W celu uzasadnienia twierdzeń naukowcy zwykle trzymają się zasady minimalności. Myślę, że właśnie dlatego Oracle nie wspomniał wyraźnie o stanie. Można go wyprowadzić z wartości atrybutów.

Rzeczywiste połączenia są błędne. Oto jak bym tego nauczył (podejście c ++):

1. Komputery obsługują dwa różne formaty pamięci: dane i kod
2. dane wyglądają jak bity 010101010101
3. kod wygląda jak instrukcje asm
4. bity danych mają dwie różne wartości, albo 0, albo 1
5. dane są abstrakcyjne do typów danych: int i = 1; to tylko krótki zapis do niektórych bitów 0000001
6. kod będzie wyglądał jak funkcja: int f (int a) {return a + a + a; } to krótki zapis niektórych instrukcji asm
7. kiedy masz kilka zmiennych, łączysz je w struct: int a; pływak b; może być umieszczony w strukturze AB {int a; pływak b; };
8. kiedy połączysz kilka fragmentów kodu, otrzymujesz klasę: class ABf {int a; pływak b; float sum (float c) const {return a + b + c; }};
9. Następnie dla danych mamy nazwy zmiennych, których można użyć do znalezienia wartości: a + b + c, aby uzyskać dostęp do danych.
10. A potem mamy normalne wywołania funkcji: int k = f (10); aby uzyskać dostęp do instrukcji asm „zapisanych” w funkcji F.
11. Następnie są instancje obiektów: ABf var;
12. I wywołuje funkcję członka: int k2 = var.sum (10.0);
13. funkcje mają typy int f (int);
14. funkcje składowe mają typy int ABf :: sum (float);
15. Jest ten wskaźnik typu ABf *
16. zmienne takie jak aib są zależne od kontekstu, jeśli są w funkcji składowej, mogą oznaczać to-> b lub po prostu b.
17. Funkcje składowe int ABf :: suma (liczba zmiennoprzecinkowa c) jest tylko krótką notacją dla wartości int suma (ABf * this, zmiennoprzecinkowa c);
18. słowo „stan” oznacza po prostu to samo, co dane
19. słowo „zachowanie” oznacza po prostu to samo, co kod
20. słowo „atrybut” oznacza po prostu to samo, co dane.

Więc tak naprawdę nic nie różni się między stanem a atrybutem. To tylko losowa kolekcja bitów. Rozróżnienie ich jest po prostu arbitralne. Musisz tylko wiedzieć, po co to jest alias.