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.Length
jest ł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.)
type GetFoo() void SetFoo()
dziesięć tysięcy razy. Przez cały czas pisania kodu C # nigdy nie byłem zdezorientowany przez właściwość.