Jaki jest sens właściwości?

Oto kilka argumentów dla właściwości i moich kontrargumentów:

Łatwiejszy w użyciu niż pisanie metod pobierających i ustawiających

Pary metod Gettera i Settera są zapachem kodu. Ułatwienie ich pisania jest jak ułatwienie zaliczenia testu matematycznego za pomocą formularza Scantron i wypełnienia wszystkich liter „C”. Obiekty, które zawierają tylko stan, dla trwałości, nie powinny używać pobierających / ustawiających i powinny tworzyć niezmienne obiekty w czasie trwałości.

Dla konsumenta przedmiotu ważne jest to, co robi, a nie jak to robi. Zachowuje się tak, jak robi; jego stan jest taki, jak to robi. Jeśli czujesz, że dbasz o stan obiektu (z wyjątkiem uporczywości, chociaż to również łamie OO), po prostu nie robisz OOP i nie tracisz jego zalet.

Dają przybliżone wyniki konsumentom

To może się zmienić w przyszłości dla dowolnej nieruchomości. Załóżmy, że w wersji 1.0 uzyskanie dostępu do PropertyX po prostu zwraca pole. W wersji 1.5, jeśli pole ma wartość null, PropertyX używa wzorca Null Object do utworzenia nowego obiektu null. W wersji 2.0 pole jest dalej sprawdzane za pomocą metody pobierającej w PropertyX.

Ponieważ właściwość staje się coraz bardziej złożona, wskazanie wydajności korzystania z właściwości wydaje się coraz mniej prawdziwe.

Są lepsze niż pola publiczne

To prawda. Ale są też metody.

Reprezentują zasadniczo inny aspekt obiektu niż metody i wszyscy konsumenci obiektu powinni o to dbać

Czy jesteś pewien, że oba powyższe stwierdzenia są prawdziwe?

Łatwiej je pisać, stary

Jasne, pisanie myObject.Lengthjest łatwiejsze niż pisanie myObject.Length(), ale czy nie można tego naprawić odrobiną cukru syntaktycznego?

Dlaczego warto korzystać z metod zamiast właściwości?

• Brak gwarancji wydajności. Interfejs API pozostanie zgodny z prawdą, nawet jeśli metoda stanie się bardziej złożona. Konsument będzie musiał profilować swój kod, jeśli napotyka problemy z wydajnością, a nie opierać się na słowie API.

• Mniej do myślenia przez konsumenta. Czy ta właściwość ma funkcję ustawiającą? Metoda na pewno nie.

• Konsument myśli z właściwego sposobu myślenia OOP. Jako konsument interfejsu API jestem zainteresowany interakcją z zachowaniem obiektu. Kiedy widzę właściwości w interfejsie API, wygląda bardzo podobnie do stanu. W rzeczywistości, jeśli właściwości robią za dużo, nie powinny nawet być właściwościami, więc tak naprawdę właściwości w stanie API ARE są takie, jakie wyglądają dla konsumentów.

• Programista API głębiej zastanowi się nad metodami ze zwracanymi wartościami i, jeśli to możliwe, uniknie modyfikowania stanu obiektu w takich metodach. W miarę możliwości należy egzekwować oddzielanie poleceń od zapytań.

Pytam więc, dlaczego warto używać właściwości zamiast metod? Większość punktów w MSDN to same w sobie zapachy kodowe i nie należą one ani do właściwości, ani do metod.

(Te myśli przyszły mi do głowy po myśleniu o CQS.)

Dlaczego są to „metody przeciw właściwościom”? Metoda coś robi. Właściwość jest, no cóż, członkiem obiektu. Są to zupełnie różne rzeczy, chociaż dwa rodzaje powszechnie pisanych metod - pobierające i ustawiające - odpowiadają właściwościom. Ponieważ porównywanie właściwości z metodami w ogóle nie ma znaczenia, zakładam, że chciałeś porozmawiać o getterach / setterach.

Pary metod Gettera i Settera są zapachem kodu.

Niekoniecznie, argumentowałbym, ale w każdym razie nie jest to kwestia getters / setters vs. właściwości, ale kwestia, czy należy użyć któregoś z nich. Pamiętaj również, że możesz np. Pominąć setXczęść, tak jak możesz tworzyć właściwości tylko do odczytu.

Dla konsumenta przedmiotu ważne jest to, co robi, a nie jak to robi. Zachowuje się tak, jak robi; jego stan jest taki, jak to robi. Jeśli czujesz, że dbasz o stan obiektu (z wyjątkiem uporczywości, chociaż to również łamie OO), po prostu nie robisz OOP i nie tracisz jego zalet.

Bardzo wątpliwe podejście. Jeśli GUI chce wyprowadzać dane przechowywane przez a DataStuffManagerImpl, musi jakoś pobrać z niego tę liczbę (i nie, wrzucenie połowy aplikacji do klasy widżetu nie jest opcją).

Ponieważ właściwość staje się coraz bardziej złożona, wskazanie wydajności korzystania z właściwości wydaje się coraz mniej prawdziwe.

[Metody mają] Brak gwarancji wydajności. Interfejs API pozostanie zgodny z prawdą, nawet jeśli metoda stanie się bardziej złożona. Konsument będzie musiał profilować swój kod, jeśli napotyka problemy z wydajnością, a nie opierać się na słowie API.

W prawie wszystkich przypadkach cała logika walidacji itp. Jest nadal efektywnie O (1) lub w inny sposób nieznaczna pod względem kosztów. Jeśli nie, być może posunąłeś się za daleko i nadszedł czas na zmianę. I getX()metoda jest zwykle traktowana jako tania!

Jasne, wpisanie myObject.Length jest łatwiejsze niż wpisanie myObject.Length (), ale czy nie można tego naprawić za pomocą odrobiny cukru syntaktycznego?

Właściwości to cukier syntaktyczny.

Mniej do myślenia przez konsumenta. Czy ta właściwość ma funkcję ustawiającą? Metoda na pewno nie.

„Czy istnieje setter dla tego gettera?” Ta sama różnica.

Programista API głębiej zastanowi się nad metodami ze zwracanymi wartościami i, jeśli to możliwe, uniknie modyfikowania stanu obiektu w takich metodach. W miarę możliwości należy egzekwować oddzielanie poleceń od zapytań.

Nie jestem pewien, co chcesz nam tutaj powiedzieć. W przypadku właściwości istnieje jeszcze silniejsze niepisane prawo, aby nie powodować skutków ubocznych.

Pary metod Gettera i Settera są zapachem kodu.

To błędne założenie i całkowicie niepoprawne. Metody Get / Set są sposobem na enkapsulację elementu danych i nie są w żaden sposób „zapachem kodu”. Naprawdę nienawidzę sposobu, w jaki niektórzy ludzie używają terminu „zapach kodu”, ale w każdym razie ...

To może się zmienić w przyszłości dla dowolnej nieruchomości. Załóżmy, że w wersji 1.0 uzyskanie dostępu do PropertyX po prostu zwraca pole. W wersji 1.5, jeśli pole ma wartość null, PropertyX używa wzorca Null Object do utworzenia nowego obiektu null. W wersji 2.0 pole jest dalej sprawdzane za pomocą metody pobierającej w PropertyX.

Ponieważ właściwość staje się coraz bardziej złożona, wskazanie wydajności korzystania z właściwości wydaje się coraz mniej prawdziwe.

Brzmi jak źle zaprojektowany interfejs API, nie rozumiem, jak to jest wina składni właściwości.

Właściwości w języku C # były po prostu cukrem syntaktycznym dla bardzo powszechnego wzoru, który ułatwiał nam życie jako programistów. Jednak obecnie, jeśli chcesz użyć powiązania danych, musisz „użyć” właściwości, więc są one teraz czymś więcej niż cukrem syntaktycznym. Chyba naprawdę nie zgadzam się z żadnym z twoich argumentów i nie rozumiem, dlaczego nie lubisz funkcji językowej, która bezpośrednio obsługuje wspólny wzór.

Twoje założenie jest złe.

Właściwości nie są w żaden sposób umową o wykonanie, wewnętrzną realizację lub cokolwiek innego.
Właściwości to specjalne pary metod, które semantycznie reprezentują atrybut, jeśli wolisz. A zatem jedyną umową jest to, że właściwość zachowuje się tak, jak można się spodziewać po atrybucie.
Jeśli pytam o kolor obiektu, nie zakładam, czy jest on uzyskiwany przez zwykły dostęp do pola, czy też jest obliczany na czas.
Chodzi o to, aby mieć możliwość ujawnienia zachowania atrybutu za pomocą metod, podczas gdy jest on przejrzysty dla konsumenta interfejsu, bez względu na to, czy używasz pola, czy akcesoriów.

Posiadanie atrybutów (i faktycznie ukrywanie ich implementacji, ponieważ właściwości przeciwstawiają się polom) jest potężną funkcją deklaratywną , która jest podstawą do posiadania inspektorów obiektów wizualnych i innych automatycznych generowań widoków, do wiązania danych i wielu innych przydatnych rzeczy. A co najważniejsze, wyraźnie przekazuje te informacje również innym programistom.

Konsument myśli z właściwego sposobu myślenia OOP. Jako konsument interfejsu API jestem zainteresowany interakcją z zachowaniem obiektu. Kiedy widzę właściwości w interfejsie API, wygląda bardzo podobnie do stanu. W rzeczywistości, jeśli właściwości robią za dużo, nie powinny nawet być właściwościami, więc tak naprawdę właściwości w stanie API ARE są takie, jakie wyglądają dla konsumentów.

Właściwość ma być stanem. Jeśli bazowy program ustawiający lub kod gettera zmieni się, aby znacznie zwiększyć przetwarzanie wymagane do ustawienia lub uzyskania stanu, to tak naprawdę nie jest to już właściwość i należy ją zastąpić metodami. To zależy od ciebie, jako autora kodu.

Umieszczanie za dużo (ile to za dużo zależy) kodu w seterze lub getterze jest złe, ale tylko dlatego, że jest to możliwe, nie jest powodem do odrzucenia wzorca we wszystkich przypadkach.

Jednej rzeczy brakuje, a nie wiem, czy jest to spowodowane ignorancją, czy celowo przeoczacie ten szczegół, że właściwości są metodami.

Gdy używasz składni właściwości C #, kompilator po cichu tworzy metody pobierające i ustawiające za pomocą metadanych, które mówią językom, które rozumieją właściwości jako pierwszorzędną funkcję składniową, aby traktowały je jako takie. To jest cukier syntaktyczny, o który prosisz. Kilka języków, które można uruchomić na CLR, nie ukrywa przed Tobą całkowicie tego szczegółu (Boo, jeśli pamięć mi służy i niektóre implementacje Lisp), i możesz jawnie wywoływać metody pobierające i ustawiające.

Właściwości czasami powodują skutki uboczne, takie jak wyzwalanie zdarzeń powiadomienia o zmianie (na przykład INotifyPropertyChanged) lub oznaczanie instancji klasy jako brudną. Tutaj mają swoją prawdziwą wartość, choć ich tworzenie to trochę więcej pracy (z wyjątkiem Boo, który ma makra zrozumiałe pod względem składni).

Teraz szerszym pytaniem jest, czy metody pobierające i ustawiające są w rzeczywistości Dobrą Rzeczą. Istnieją wyraźne kompromisy; jeśli masz metody mutatora, twój kod jest z natury mniej równoległy, ponieważ musisz teraz poradzić sobie z problemami z synchronizacją wątków. I całkiem możliwe, że zaryzykujesz naruszeniem Prawa Demetera przy użyciu metod mutatora (niezależnie od tego, czy nazywane są właściwościami, czy metodami getter / setter; są one równoważne), ponieważ jest to cholernie wygodne.

Ale czasem jest to właściwe. Czasami twoim problemem jest pobranie danych z jakiegoś źródła, zmiana ich trochę, przedstawienie zaktualizowanych danych użytkownikowi i zapisanie zmian. Ten idiom jest dobrze obsługiwany przez właściwości. Jak mówi artykuł Allena Holuba , to, że osoby pobierające i ustawiające mają problemy, nie oznacza, że ​​nigdy nie powinieneś ich używać. (Parroting abstract Guruspeak uważany za szkodliwy). Nawet jeśli zastosujesz podejście Klasa / Obowiązki / Współpracownicy, nadal ujawniasz komuś informacje lub prezentacje informacji; chodzi o to, aby zminimalizować pole powierzchni splątania.

Zaletą właściwości jest to, że bardzo łatwo jest skorzystać z innego obiektu. Minusem właściwości jest to, że bardzo łatwo jest skorzystać z innego obiektu i nie można temu łatwo zapobiec.

Mutacja obiektowa ma sens w warstwie kontrolera, na przykład w architekturze MVC. To twój współpracownik. Twój pogląd jest także współpracownikiem, ale nie powinien bezpośrednio mutować twoich obiektów, ponieważ ma różne obowiązki. Wstawianie kodu prezentacji do obiektów biznesowych niekoniecznie jest dobrym sposobem na uniknięcie programów pobierających / ustawiających.

Równanie zmienia się nieco, jeśli używasz funkcjonalnych, a nie czystych OO, abstrakcji, co sprawia, że ​​robienie kopii obiektu „rekordowego” z kilkoma zmianami jest dość trywialne, choć nie wolne. I hej, jeśli próbujesz uzyskać gwarancje wydajności, właściwości są ogólnie bardziej przewidywalne niż leniwe przebudowywanie niezmiennej kolekcji.

Innym ważnym powodem w mojej książce do używania właściwości jest to, że mogą one znacznie zwiększyć czytelność.

account.setBalance(Account.getBalance()+deposit);

jest po prostu znacznie mniej czytelny niż

account.Balance += deposit;

Masz prawie przeciwny religijny punkt widzenia do mnie :)

Kiedy przeniosłem się z Delphi na Javę, brak właściwości był dla mnie ogromnym afrontem. Byłem przyzwyczajony do deklarowania właściwości i albo kierowania jej bezpośrednio do zmiennej prywatnej, albo pisania (chronionego) gettera i settera, a następnie „podłączania” ich do właściwości. To zamknęło właściwość i kontrolowało, w jaki sposób należy do niej uzyskać dostęp w wyraźny, jednoznaczny sposób. Możesz mieć właściwość tylko do odczytu, która oblicza sumę po uzyskaniu dostępu i nazywa ją „Suma” nie „_getTotal ()” lub podobne ballochs. Oznaczało to również, że można ograniczyć dostęp do właściwości, chroniąc je w abstrakcyjnej klasie bazowej, a następnie przenosząc je do publicznych lub publikowanych w podklasach.

Dla mnie właściwości są bardziej naturalnym i ekspresyjnym sposobem ustawiania i uzyskiwania stanu obiektu. Poleganie na niewymuszonych konwencjach kodowania jest bardziej „zapachem kodu” niż czymkolwiek, za co krytykuje się właściwości. Ponadto, jak powiedzieli inni, wymyślanie źle zaprojektowanego użycia właściwości i wykorzystywanie jego wad do wypróbowania i odrzucenia koncepcji właściwości w ogóle jest wyjątkowo złą formą. Możliwe, że widziałeś tylko złe wykorzystanie właściwości i zakładam, że tak właśnie jest, ale powinieneś zrobić więcej badań, zanim staniesz się zbyt dogmatyczny.

Jednym z powodów, dla których właściwości zostały wprowadzone w Java Beans Framework, było umożliwienie integracji z IDE - możesz przeciągnąć te komponenty do IDE i edytować właściwości za pomocą edytorów właściwości.

(wtedy byli zwykłymi pobieraczami i seterami - i zostali zdefiniowani tylko przez konwencję nazewnictwa - i to rzeczywiście pachniało)

Obecnie jest jeszcze więcej przypadków, w których właściwości są uzyskiwane i modyfikowane nie za pomocą zwykłego kodu - na przykład podczas debugowania.

Z jednej strony - naprawdę pochodzą z VB. Pamiętaj, że w mrocznych czasach XX wieku, kiedy wymyślono platformę .NET, główny nacisk położono na to, że była to łatwa, zastępcza wymiana VB, dzięki czemu programiści VB mogli po prostu przeciągać i upuszczać elementy na formularze internetowe. VB miał właściwości, więc trzeba było zachować tę funkcję, aby wszystko dobrze się tłumaczyło.

Istnieją co najmniej dwa cele dotyczące nieruchomości:

• Są one koncepcyjnie identyczne z polami, nawet jeśli są zaimplementowane inaczej. Getter nie powinien zmieniać stanu obiektu i nie powinien mieć żadnych skutków ubocznych. Seter powinien zmieniać stan tylko w sposób koncepcyjnie podobny do modyfikowania pola i nie wywoływać innych skutków ubocznych.

• Są one składniowo identyczne z polami publicznymi (prawdopodobnie tylko do odczytu). Oznacza to, że pole publiczne można zmienić na właściwość bez przerywania wywołujących na poziomie źródła.