Konstruktor lub właściwości: który z nich jest lepszym wyborem podczas przypisywania wartości

Question

Kiedy należy używać konstruktora nad właściwościami lub odwrotnie podczas przypisywania wartości.

Answer 1

Konstruktor to bardzo wygodny i skuteczny rodzaj umowy - sposób na wymóg, aby konsumenci dostarczali pewnych informacji , zanim będą mogli nawet użyć obiektu. Aby uzyskać informacje niezbędne do prawidłowego działania instancji, należy użyć parametrów konstruktora. Jest to podstawowa koncepcja zastrzyku uzależnienia - wszystko, czego jesteś zależny od wykonywania swojej pracy, musi zostać wstrzyknięte (dostarczone) przed rozpoczęciem.

Właściwości mogą stanowić interesujący problem. Ogólnie rzecz biorąc, doświadczenie nauczyło mnie, że w miarę możliwości, właściwości powinny być tylko do odczytu, a obiekty powinny być na ogół tak niezmienne jak to tylko możliwe. Dodanie setera publicznego do właściwości jest mnożnikiem złożoności dla twojej klasy. Są oczywiście zawsze typy obiektów - przykłady są dobrym przykładem - gdzie setery mają sens. Jednak w przypadku większości obiektów wzorzec "write-to via constructor"/"read-from via properties" dla stanu znacznie zmniejszył złożoność i ryzyko błędów w aplikacjach, za które byłem odpowiedzialny.

Answer 2

Używasz konstruktora, gdy potrzebujesz arbitralnych początkowych wartości i właściwości, jeśli chcesz później zmienić wartości.

Answer 3

Użyj konstruktora, jeśli wartości parametrów są rzeczywiście wymagane do skonstruowania obiektu (bez nich obiekt nie może zacząć żyć). Użyj właściwości dla parametrów, które mają akceptowalną wartość domyślną, więc nie należy ich w ogóle przypisywać. Możesz dostarczyć dodatkowych konstruktorów, którzy przypiszą niektóre właściwości jako skrót, dzięki uprzejmości twoich użytkowników.

Answer 4

Istnieje kilka przypadków, w których właściwości Zmienne mogą być preferowane:

1. uzyskać „czysty” modyfikowalnych obiektów danych, gdzie tylko ustawienie właściwości może mieć żadnych skutków ubocznych. Na przykład może istnieć obiekt, który reprezentuje pewną jednostkę w bazie danych, ale modyfikowanie jej właściwości nie będzie miało żadnego wpływu, dopóki nie zostanie jawnie wykonana operacja zatwierdzania. Obiekt jest pakietem do przechowywania danych, ale nic nie reaguje bezpośrednio na zmiany danych.

2. Jeśli masz dużo konfigurowalnego stanu, który wpłynie na niektóre operacje, a wiele konfigurowalnych właściwości ma znaczące wartości domyślne. Jeśli są to właściwości klasy, która wykonuje operację, typowe jest posiadanie pewnego pojęcia "zamrożenia" stanu, aby zmienne właściwości generowały wyjątki podczas działania operacji.

3. Jeśli tworzysz klasę, która zostanie wykorzystana przez projektanta wizualnego lub inny system, który polega na odbiciu nad właściwościami. Na przykład system łączenia danych w WPF szeroko wykorzystuje zmienne właściwości jako sposób komunikacji interakcji UI. Dzięki odpowiedniemu projektowi do zarządzania tymi mutacjami, możesz stworzyć bardzo potężne i responsywne interfejsy.