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

16

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?

Daniel Scocco
źródło
4
Tak, brakuje ci cech jako techniki symulowania zachowania.
yannis
Spójrz na ten post, może pomóc: yegor256.com/2014/12/09/…
yegor256

Odpowiedzi:

13

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.

Mike Nakis
źródło
Myślenie w kategoriach niezmiennych i zmieniających się cech instancji ma sens. I cieszę się, że nie byłem tak daleko. Dzięki!
Daniel Scocco
Czy rozmiar lampy podczas procesu produkcyjnego lub montażu będzie stanem?
JeffO
Nie, to będzie atrybut. (W znaczeniu OP).
Mike Nakis,
4
Nie ma zasadniczej różnicy między stanem a atrybutami, dlatego łatwiej jest zdefiniować stan jako możliwy do zmiany lub niezmienny. Chociaż posiadanie (niezmiennego) atrybutu i (zmiennego) stanu nie jest niepoprawne (iw wielu aspektach jest równoważne), to rozróżnienie sprawia, że ​​definicja jest bardziej złożona niż to konieczne. Chociaż IMO termin „stan” prawdopodobnie nie jest najlepszym terminem na opisanie tego pojęcia, ponieważ „stan” w jakiś sposób implikuje, że ma się zmienić, podczas gdy „stan” - jak opisano w artykule Oracle - tego nie ma.
Lie Ryan,
Myślę, że z upływem lat zmienia się stosunek ludzi do niezmienności; dla tych, którzy rozumieją jego znaczenie, istnieje zasadnicza różnica między stanem zmiennym a niezmiennym, wystarczającym, aby uzasadnić inną nazwę. Czy mogę polecić bardzo interesującą lekturę? Eric Lippert - Fantastyczne przygody w kodzie - Niezmienność w C # Część pierwsza: Rodzaje niezmienności
Mike Nakis
4

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.

Bill jaszczurka
źródło
Czy kolor futra lisa staje się stanem, ponieważ zmienia się w zimie?
JeffO
@JeffO Kolor futra może również ulec zmianie, gdy się zestarzeje, zmoknie, farbuje ... z wielu powodów. Tak naprawdę nie jest to stan tylko dlatego, że może się zmieniać w trakcie życia jednego obiektu, ale ponieważ różne obiekty tego samego typu mogą mieć różne wartości tego atrybutu.
Bill the Lizard
1

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).

Pavel Bucek
źródło
0

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.

Blane
źródło
-2

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.

Raku
źródło
1
Oracle zrobił stan wspominając jawnie; przeczytaj cytat. I OP oczywiście używa atrybutów słowa w znaczeniu niezmiennych właściwości obiektu, więc nie myli ich ze stanem.
Mike Nakis,
Nadal są cechami - niezależnie od tego, czy się zmieniają, czy nazywają je „atrybutami”, czy „członkami”. W świecie programowania nie ma nic poza reprezentowaniem stanu obiektu poza jego atrybutami.
Raku
-3

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.

tp1
źródło