Wkładam tę odpowiedź, aby uzupełnić odpowiedź Rogera Alsinga na temat niezmienników z innych powodów.
semantyczna informacji
Roger wyraźnie wyjaśnił, że setery własności nie posiadają informacje semantyczne. Zezwalanie na ustawianie dla właściwości takiej jak Post.PublishDate może powodować zamieszanie, ponieważ nie możemy być pewni, czy post został opublikowany, czy tylko, jeśli ustawiono datę publikacji. Nie możemy wiedzieć na pewno, że to wszystko, co jest potrzebne do opublikowania artykułu. Obiekt "interfejs" wyraźnie nie pokazuje "zamiaru".
Uważam jednak, że właściwości takie jak "Włączone" przenoszą wystarczającą ilość znaczeń semantycznych zarówno dla "otrzymywania", jak i "ustawiania". Jest to coś, co powinno być natychmiast skuteczne i nie widzę potrzeby stosowania metod SetActive() lub Activate()/Deactivate() z samego powodu brakującej semantyki w ustawiaczu właściwości.
Niezmienniki
Roger mówił również o możliwości zerwania niezmienników przez ustawiaczy własności. Jest to absolutnie słuszne i należy tworzyć właściwości, które działają w tandemie, aby zapewnić "kombinowaną niezmienną wartość" (jako kąty trójkąta, aby użyć przykładu Rogera) jako właściwości tylko do odczytu i utworzyć metodę, aby ustawić je wszystkie razem, co może sprawdź wszystkie kombinacje w jednym kroku.
inicjalizacji zamówienie nieruchomości/ustawienia zależności
ten jest podobny do problemu z niezmienników gdyż powoduje problemy z właściwościami, które powinny być zatwierdzone/zmienionych razem. Wyobraź sobie następujący kod:
public class Period
{
DateTime start;
public DateTime Start
{
get { return start; }
set
{
if (value > end && end != default(DateTime))
throw new Exception("Start can't be later than end!");
start = value;
}
}
DateTime end;
public DateTime End
{
get { return end; }
set
{
if (value < start && start != default(DateTime))
throw new Exception("End can't be earlier than start!");
end = value;
}
}
}
Jest to naiwny przykład sprawdzania poprawności "settera", który powoduje zależności kolejności dostępu. Poniższy kod ilustruje ten problem:
public void CanChangeStartAndEndInAnyOrder()
{
Period period = new Period(DateTime.Now, DateTime.Now);
period.Start = DateTime.Now.AddDays(1); //--> will throw exception here
period.End = DateTime.Now.AddDays(2);
// the following may throw an exception depending on the order the C# compiler
// assigns the properties.
period = new Period()
{
Start = DateTime.Now.AddDays(1),
End = DateTime.Now.AddDays(2),
};
// The order is not guaranteed by C#, so either way may throw an exception
period = new Period()
{
End = DateTime.Now.AddDays(2),
Start = DateTime.Now.AddDays(1),
};
}
Ponieważ nie możemy zmienić datę rozpoczęcia przeszłości dacie zakończenia okresu na obiekcie (chyba że jest to „pusty” okres, w obu terminach określonych domyślnych (DateTime) - tak, to nie jest świetny projekt, ale masz na myśli to, co mam na myśli ...), próbując ustawić datę początkową jako pierwszy, wyrzucisz wyjątek.
To staje się poważniejsze, gdy używamy inicjalizatorów obiektów. Ponieważ C# nie gwarantuje żadnej kolejności przypisania, nie możemy podać żadnych bezpiecznych założeń, a kod może lub nie może wyrzucać wyjątek w zależności od wyboru kompilatora. ZŁY!
Jest to ostatecznie problem z DESIGNem klas. Ponieważ właściwość nie może "wiedzieć", że aktualizujesz obie wartości, nie może "wyłączyć" sprawdzania poprawności, dopóki obie wartości nie zostaną faktycznie zmienione. Powinieneś albo uczynić obie właściwości tylko do odczytu, i dostarczyć metodę do ustawienia w tym samym czasie (utratę funkcji inicjalizatorów obiektów) lub usunąć kod walidacji z właściwości łącznie (być może wprowadzając inną właściwość tylko do odczytu, taką jak IsValid, lub sprawdzając poprawność gdy jest to konieczne).
ORM "uwodnienie" *
Hydration, w uproszczonym widzenia oznacza uzyskanie danych trwało powrotem do obiektów. Dla mnie jest to naprawdę największy problem z dodawaniem logiki za ustawianiem właściwości.
Wiele/większość ORM odwzorowuje utrwaloną wartość na właściwość. Jeśli posiadasz logikę lub logikę walidacji, która zmienia stan obiektu (inne elementy) wewnątrz ustawiaczy właściwości, spróbujesz zweryfikować obiekt "niekompletny" (który wciąż jest ładowany). Jest to bardzo podobne do problemu inicjalizacji obiektu, ponieważ nie można kontrolować porządku, w którym pola są "nawodnione".
Większość ORMów pozwala mapować trwałość na prywatne pola zamiast właściwości, a to pozwoli na uwodnienie obiektów, ale jeśli logika walidacji znajduje się głównie w ustawieniach nieruchomości, może być konieczne skopiowanie jej gdzie indziej, aby sprawdzić, czy załadowany obiekt jest ważny lub nie.
Ponieważ wiele narzędzi ORM obsługuje leniwe ładowanie (podstawowy aspekt ORM!) Poprzez użycie właściwości (lub metod) wirtualnych mapowanie do pól spowoduje, że ORM nie będzie mógł wczytać obiektów odwzorowanych w pola.
Wnioski
Więc w końcu, aby uniknąć powielania kodu, pozwalają ORMs wykonywać najlepiej jak mogli, zapobiegania zaskakujące wyjątki w zależności od kolejności pola są ustawione, dobrze jest przenieść logikę z dala od właścicieli nieruchomości.
Wciąż zastanawiam się, gdzie powinna być ta logika "walidacji". Gdzie sprawdzamy niezmienne aspekty obiektu? Gdzie umieszczamy walidacje wyższego poziomu? Czy używamy haków na ORMach do sprawdzania poprawności (OnSave, OnDelete, ...)? Itd. Itd. Itd. Ale to nie jest zakres tej odpowiedzi.
, więc w twoim przykładzie powinniśmy użyć jednej funkcji, takiej jak 'period.setDateBoundries (startDate, endDate)' aby uniknąć seterów? pojedyncza funkcja, która ma znaczenie biznesowe zamiast ustawiania manekinów? – Songo
@Songo to właśnie bym zrobił. Ale wtedy można by narzekać na obie daty, aby zmienić tylko jedną (wyobraź sobie, że gdybyśmy chcieli przedłużyć termin, musielibyśmy podać obie daty! ... ale potem, hej, dlaczego nie stworzymy metody Extend ?) Pomyślmy tak: kiedy kończysz na własności zależnej od innej, dobrym pomysłem może być wprowadzenie metod ich zmiany lub metod, które dodadzą więcej wartości semantycznych (jak np. Okres.)! – Loudenvier
Zastanawiam się tylko nad przekazywaniem tablic. Nie jest to dobre dla podpowiedzi IDE, ale pozwala mi przekazywać dane w dowolnej kolejności. Mogę również dodawać lub pomijać dane w zależności od okoliczności (np. Pełny zakres dat lub tylko jedna data). Sprawdzanie poprawności odbywa się w każdym razie, więc nie wydaje się zbyt dużym obciążeniem, aby sprawdzić, czy parametr został podany lub pominięty. – prograhammer