Czy jest to anty-wzorzec, jeśli właściwość klasy tworzy i zwraca nową instancję klasy?

Mam klasę o nazwie, Headingktóra robi kilka rzeczy, ale powinna również być w stanie zwrócić przeciwieństwo bieżącej wartości nagłówka, która w końcu musi zostać użyta poprzez utworzenie nowej instancji Headingsamej klasy.

Mogę mieć prostą właściwość wywoływaną w reciprocalcelu zwrócenia przeciwnego nagłówka bieżącej wartości, a następnie ręcznie utworzyć nową instancję klasy Heading, lub mogę utworzyć metodę polegającą createReciprocalHeading()na automatycznym utworzeniu nowej instancji klasy Heading i zwróceniu jej do właściwości użytkownik.

Jednak jeden z moich kolegów polecił mi po prostu utworzenie właściwości klasy o nazwie, reciprocalktóra zwraca nową instancję samej klasy za pomocą metody getter.

Moje pytanie brzmi: czy to nie jest anty-wzorzec dla właściwości klasy, która zachowuje się w ten sposób?

Uważam to za mniej intuicyjne, ponieważ:

1. Moim zdaniem własność klasy nie powinna zwracać nowej instancji klasy, i
2. Nazwa właściwości, która reciprocalnie pomaga deweloperowi w pełni zrozumieć jej zachowanie, bez uzyskania pomocy z IDE lub sprawdzenia podpisu gettera.

Czy jestem zbyt rygorystyczny co do tego, co powinna zrobić własność klasy, czy jest to uzasadniona obawa? Zawsze starałem się zarządzać stanem klasy poprzez jej pola i właściwości oraz jej zachowanie za pomocą metod, i nie rozumiem, jak to pasuje do definicji właściwości klasy.

Nie jest nieznane posiadanie takich funkcji jak Copy () lub Clone (), ale tak, myślę, że masz rację, że martwisz się tym.

Weź na przykład:

h2 = h1.reciprocal
h2.Name = "hello world"
h1.reciprocal.Name = ?

Przydałoby się ostrzeżenie, że za każdym razem właściwość była nowym obiektem.

możesz również założyć, że:

h2.reciprocal == h1

Jednak. Jeśli twoja klasa nagłówkowa była niezmiennym typem wartości, to możesz zaimplementować te relacje, a odwrotność może być dobrą nazwą dla operacji

Interfejs klasy prowadzi użytkownika do przyjęcia założeń dotyczących jego działania.

Jeśli wiele z tych założeń jest poprawnych, a kilka jest błędnych, interfejs jest dobry.

Jeśli wiele z tych założeń jest błędnych, a niewiele ma rację, interfejs jest śmieci.

Powszechnym założeniem dotyczącym właściwości jest to, że wywoływanie funkcji get jest tanie. Innym powszechnym założeniem dotyczącym właściwości jest to, że wywołanie funkcji get dwa razy z rzędu zwróci to samo.

Możesz obejść ten problem, stosując spójność, aby zmienić oczekiwania. Na przykład, dla małej biblioteki 3D, gdzie trzeba Vector, Ray Matrixitd można zrobić to w taki sposób, jak w pozyskiwaniu Vector.normali Matrix.inversesą prawie zawsze drogie. Niestety, nawet jeśli twoje interfejsy konsekwentnie używają drogich właściwości, interfejsy będą co najmniej tak intuicyjne, jak te, które używają, Vector.create_normal()a Matrix.create_inverse()jednak nie znam mocnego argumentu, który można by uzasadnić, że używanie właściwości tworzy bardziej intuicyjny interfejs, nawet po zmianie oczekiwań.

Właściwości powinny zwracać się bardzo szybko, zwracać tę samą wartość przy powtarzanych wywołaniach, a uzyskanie ich wartości nie powinno mieć skutków ubocznych. To, co tu opisujesz, nie powinno być implementowane jako własność.

Twoja intuicja jest zasadniczo poprawna. Metoda fabryczna nie zwraca tej samej wartości przy powtarzanych wywołaniach. Za każdym razem zwraca nową instancję. To prawie dyskwalifikuje to jako własność. Nie jest to również szybkie, jeśli późniejszy rozwój zwiększa wagę tworzenia instancji, np. Zależności sieci.

Właściwości powinny zasadniczo być bardzo prostymi operacjami, które pobierają / ustawiają część bieżącego stanu klasy. Operacje fabryczne nie spełniają tych kryteriów.

Nie sądzę, aby istniała odpowiedź na to pytanie niezależnie od języka, ponieważ to, co stanowi „właściwość”, jest pytaniem specyficznym dla danego języka, a to, czego oczekuje osoba wywołująca „właściwość”, jest również pytaniem specyficznym dla danego języka. Myślę, że najbardziej owocnym sposobem na myślenie o tym jest myślenie o tym, jak to wygląda z punktu widzenia dzwoniącego.

W języku C # właściwości wyróżniają się tym, że są (konwencjonalnie) pisane wielkimi literami (jak metody), ale nie zawierają nawiasów (jak zmienne instancji publicznej). Jeśli widzisz następujący kod, brak dokumentacji, czego oczekujesz?

var reciprocalHeading = myHeading.Reciprocal;

Jako względny nowicjusz w języku C #, ale czytający Wytyczne użytkowania nieruchomości firmy Microsoft , spodziewałbym Reciprocalsię między innymi:

1. być logicznym członkiem Headingklasy
2. bądź niedrogi, aby zadzwonić, aby nie trzeba było buforować wartości
3. brak obserwowalnych skutków ubocznych
4. dają ten sam wynik, jeśli zostaną wywołane dwa razy pod rząd
5. (może) zaoferować ReciprocalChangedwydarzenie

Spośród tych założeń (3) i (4) są prawdopodobnie poprawne (zakładając, że Headingjest to niezmienny typ wartości, jak w odpowiedzi Ewana ), (1) jest dyskusyjny, (2) jest nieznany, ale także dyskusyjny, a (5) jest mało prawdopodobne mają sens semantyczny (chociaż cokolwiek ma nagłówek, może być HeadingChangedzdarzeniem). To sugeruje mi, że w API C # „pobierz lub oblicz wzajemność” nie powinno być implementowane jako właściwość, ale zwłaszcza jeśli obliczenia są tanie i Headingsą niezmienne, jest to przypadek graniczny.

(Zauważ jednak, że żaden z tych problemów nie ma nic wspólnego z tym, czy wywołanie właściwości tworzy nową instancję , nawet (2). Tworzenie obiektów w CLR samo w sobie jest dość tanie).

W Javie właściwości są konwencją nazewnictwa metod. Jeśli widzę

Heading reciprocalHeading = myHeading.getReciprocal();

moje oczekiwania są podobne do powyższych (jeśli mniej wyraźnie określone): oczekuję, że połączenie będzie tanie, idempotentne i pozbawione skutków ubocznych. Jednak poza ramą JavaBeans koncepcja „właściwości” nie jest tak bardzo znacząca w Javie, a zwłaszcza, gdy rozważa się niezmienną właściwość bez odpowiadającej jej setReciprocal(), getXXX()konwencja jest obecnie nieco staromodna. Od Effective Java , drugie wydanie (już ponad osiem lat):

Metody zwracające booleanfunkcję lub atrybut obiektu, na który są wywoływane, są zwykle nazywane rzeczownikiem, wyrażeniem rzeczownikowym lub wyrażeniem czasownikowym rozpoczynającym się od czasownika get… Istnieje kontyngent wokalny, który twierdzi, że tylko trzecia forma (zaczynająca się od get) jest akceptowalna, ale jest niewiele podstaw do tego twierdzenia. Pierwsze dwie formy zwykle prowadzą do bardziej czytelnego kodu… (s. 239)

Zatem we współczesnym, bardziej płynnym API spodziewałbym się zobaczyć

Heading reciprocalHeading = myHeading.reciprocal();

- co ponownie sugeruje, że wywołanie jest tanie, idempotentne i nie ma skutków ubocznych, ale nie powiedziałoby nic o tym, czy wykonywane jest nowe obliczenie, czy tworzony jest nowy obiekt. To jest w porządku; w dobrym API, nie powinno mnie to obchodzić.

W Ruby nie ma czegoś takiego jak własność. Istnieją „atrybuty”, ale jeśli widzę

reciprocalHeading = my_heading.reciprocal

Nie mam bezpośredniego sposobu, aby dowiedzieć się, czy uzyskuję dostęp do zmiennej instancji @reciprocalza attr_readerpomocą prostej metody akcesorium, czy też wywołuję metodę, która wykonuje kosztowne obliczenia. Jednak fakt, że nazwa metody jest rzeczownikiem prostym, zamiast powiedzieć calcReciprocal, sugeruje ponownie, że wywołanie jest co najmniej tanie i prawdopodobnie nie ma skutków ubocznych.

W Scali konwencja nazewnictwa mówi, że metody z efektami ubocznymi przyjmują nawiasy, a metody bez nich nie, ale

val reciprocal = heading.reciprocal

może być jednym z:

// immutable public value initialized at creation time
val reciprocal: Heading = … 

// immutable public value initialized on first use
lazy val reciprocal: Heading = … 

// public method, probably recalculating on each invocation
def reciprocal: Heading = …

// as above, with parentheses that, by convention, the caller
// should only omit if they know the method has no side effects
def reciprocal(): Heading = …

(Zauważ, że Scala dopuszcza różne rzeczy, które mimo wszystko są zniechęcane przez przewodnik po stylu . To jedna z moich głównych irytacji ze Scali.)

Brak nawiasów mówi mi, że połączenie nie ma skutków ubocznych; nazwa ponownie sugeruje, że połączenie powinno być stosunkowo tanie. Poza tym nie obchodzi mnie, w jaki sposób zyskuje mi wartość.

W skrócie: poznaj język, którego używasz, i dowiedz się, jakie oczekiwania przyniosą inni programiści w interfejsie API. Cała reszta to szczegół implementacji.

Jak powiedzieli inni, zwracanie instancji tej samej klasy jest dość powszechnym wzorcem.

Nazewnictwo powinno iść w parze z konwencjami nazewnictwa języka.

Na przykład w Javie prawdopodobnie spodziewałbym się, że zostanie wywołany getReciprocal();

Biorąc to pod uwagę, rozważę obiekty zmienne vs niezmienne .

W przypadku tych niezmiennych rzeczy są dość łatwe i nie zaszkodzi, jeśli zwrócisz ten sam przedmiot, czy nie.

W przypadku zmiennych może to być bardzo przerażające.

b = a.reciprocal
a += 1
b = what?

Teraz do czego odnosi się b? Odwrotność pierwotnej wartości? Czy odwrotność zmienionego? To może być zbyt krótki przykład, ale rozumiesz.

W takich przypadkach szukaj lepszego nazewnictwa, które informuje o tym, co się dzieje, na przykład createReciprocal()może być lepszym wyborem.

Ale tak naprawdę zależy to również od kontekstu.

W trosce o pojedynczą odpowiedzialność i przejrzystość chciałbym mieć ReverseHeadingFactory, który wziąłby obiekt i zwrócił jego odwrotność. Ułatwiłoby to wyjaśnienie, że zwracany jest nowy obiekt, i oznaczałoby, że kod generujący odwrotność został zamknięty w innym kodzie.

To zależy. Zwykle oczekuję, że właściwości zwrócą rzeczy, które są częścią instancji, więc zwrócenie innej instancji tej samej klasy byłoby nieco niezwykłe.

Ale na przykład klasa łańcuchowa może mieć właściwości „firstWord”, „lastWord” lub jeśli obsługuje Unicode „firstLetter”, „lastLetter”, które byłyby obiektami pełnego ciągu - zwykle mniejszymi.

Ponieważ pozostałe odpowiedzi dotyczą części Właściwość, zajmę się twoim drugim tematem reciprocal :

Nie używaj niczego innego niż reciprocal. Jest to jedyny poprawny termin na to, co opisujesz (i jest to termin formalny). Nie pisz niepoprawnego oprogramowania, aby uchronić programistów przed nauczeniem się domeny, w której pracują. W nawigacji terminy mają bardzo konkretne znaczenie i używanie czegoś tak pozornie nieszkodliwego, jak reversei oppositemoże prowadzić do zamieszania w niektórych kontekstach.

Logicznie nie, nie jest to właściwość nagłówka. Gdyby tak było, można by również powiedzieć, że ujemna liczba jest własnością tej liczby, i szczerze mówiąc, że „własność” straci wszelkie znaczenie, prawie wszystko byłoby własnością.

Odwrotność jest czystą funkcją nagłówka, tak samo jak ujemna liczba jest czystą funkcją tej liczby.

Zasadniczo, jeśli ustawienie nie ma sensu, prawdopodobnie nie powinno być własnością. Ustawienie to nadal może być oczywiście zabronione, ale dodanie settera powinno być teoretycznie możliwe i sensowne.

Teraz, w niektórych językach, sensowne może być posiadanie go jako właściwości określonej w kontekście tego języka, jeśli przynosi pewne korzyści wynikające z mechaniki tego języka. Na przykład, jeśli chcesz przechowywać go w bazie danych, prawdopodobnie rozsądnym rozwiązaniem jest ustawienie go jako właściwości, jeśli pozwala on na automatyczną obsługę przez środowisko ORM. A może jest to język, w którym nie ma rozróżnienia między właściwością a parametryczną funkcją składową (nie znam takiego języka, ale jestem pewien, że istnieją). Następnie projektant interfejsu API i dokumentator muszą rozróżnić funkcje i właściwości.

Edycja: W szczególności w języku C #, przyjrzałbym się istniejącym klasom, zwłaszcza klasowym.

• Istnieją BigIntegeri Complexstruktury. Ale są to struktury i mają tylko funkcje statyczne, a wszystkie właściwości są innego rodzaju. Więc nie ma wiele pomocy w projektowaniuHeading klasy.
• Math.NET Numerics ma Vectorklasę , która ma bardzo mało właściwości i wydaje się być bardzo zbliżona do twojej Heading. Jeśli przejdziesz przez to, będziesz miał funkcję wzajemności, a nie właściwość.

Możesz przyjrzeć się bibliotekom faktycznie używanym przez kod lub istniejącym podobnym klasom. Staraj się być konsekwentny, zwykle jest to najlepszy sposób, jeśli jeden sposób nie jest wyraźnie właściwy, a drugi zły.

Rzeczywiście bardzo interesujące pytanie. Nie widzę naruszenia SOLID + DRY + KISS w tym, co proponujesz, ale nadal pachnie źle.

Metoda zwracająca instancję klasy nazywa się konstruktorem , prawda? więc tworzysz nową instancję z metody innej niż konstruktor. To nie koniec świata, ale jako klient nie spodziewałbym się tego. Odbywa się to zwykle w szczególnych okolicznościach: fabrycznej lub, czasem, statycznej metodzie tej samej klasy (przydatne dla singletonów i dla ... niezbyt obiektowych programistów?)

Plus: co się stanie, jeśli wywołasz getReciprocal()zwrócony obiekt? otrzymujesz inną instancję klasy, która może być bardzo dokładną kopią pierwszej! A jeśli się odwołujeszgetReciprocal() TEGO? Przedmioty rozkładają się na kimś?

Ponownie: co jeśli wywołujący potrzebuje wartości wzajemnej (mam na myśli skalar)? getReciprocal()->getValue()? naruszamy Prawo Demeter za niewielkie zyski.