Jaki jest poprawny sposób wymuszania ograniczeń na wartości klas przypadków?

Question

Rzucanie wyjątków w czasie budowy jest ogólnie postrzegane jako mało grzeczne, ale nie jestem pewien, jak tego uniknąć, próbując wymusić ograniczenia na wartości klas przypadków .

Powiedzmy na przykład, że muszę reprezentować zakres i że obie granice muszą być dodatnie. Natychmiastowa realizacja będzie:

case class Range(from: Int, to: Int) 

To jednak nie upewnić się, że zarówno from i to są pozytywne, ani że to jest większa niż from.

Moim pierwszym odruchem jest wdrożenie go w następujący sposób:

case class Range(from: Int, to: Int) { 
    require(from >= 0) 
    require(to >= 0) 
    require(to >= from) 
} 

To jednak sprawia, że ​​konstruktor Range „s niebezpieczne.

Czy istnieje wspólny wzorzec zachowania łatwości użycia klas przypadków, wymuszania ograniczeń wartości i unikania wyjątków wyrzucania?

Answer 1

To dość subiektywne, ale spróbuję.

To zależy od tego, jak zbudowana jest twoja klasa. W przypadku prostej klasy zakresu użyteczności używanej zwyczajowo w wewnętrznym kodzie, każdy programista używający jej powinien prawdopodobnie być świadomy, że podawanie nieprawidłowych wartości zakresu może prowadzić do dziwnych wyników. Możesz założyć, że rozsądne użycie klas naprawdę nie napotyka tego problemu, a wyrzucenie wyjątku w tych rzadkich przypadkach może nie być złym zwyczajem, aby zasygnalizować komuś naprawdę spieprzone. Jeśli z kontekstu jest oczywiste, jakie wartości należy podawać klasie, nie uważam, że szczególnie źle jest rzucać wyjątki, jeśli ludzie nie spełniają oczekiwań wobec zdrowia psychicznego.

Porównaj to zachowanie z NullPointerException s lub ArithmethicException s, które czasami zdarzają się w Scali. Czasem po prostu nie ma sensu programować defensywnie, gdy spotyka się wystarczająco "szaleństwo".

Z drugiej strony, jeśli twoja klasa jest wypełniona wartościami, nad którymi masz mniej kontroli, tj. Są bezpośrednią konsekwencją wprowadzania danych przez użytkownika, musisz po prostu przejąć większą kontrolę nad swoją konstrukcją. Tworzenie obiektu towarzysz z funkcją, która zwraca Option lub Either:

object Range { 
    def createSafe(from: Int, to: Int): Option[Range] = { 
     if(from >= 0 && to >= 0 && to >= from) 
      Some(Range(from, to)) 
     else 
      None 
    } 
} 

Można wtedy nawet ponowne wykorzystanie logiki walidacji w konkretyzacji swojej klasie przypadku nadrzędnymi apply jako druga odpowiedź sugeruje.

object Range { 
    def createSafe ... 
    def apply(from: Int, to: Int): Range = { 
     createSafe(from, to).getOrElse(throw new IllegalArgumentException(...)) 
    } 
} 

Answer 2

Należy uwzględnić programowanie typu. Niestety nie ma krótkiej odpowiedzi. Mam jednak blogu serię na temat niedawno, że myślę, że może pomóc w rozwiązaniu tego typu problemu: http://proseand.co.nz/2014/02/17/type-programming-shifting-from-values-to-types/

Answer 3

Można przeciążać operatora w obiekcie towarzysz apply aby osiągnąć to, co chcesz zrobić:

object Range{ 
    def apply(from: Int, to: Int) ={ 
    val _from = Math.max(0, from) 
    val _to = Math.max(0, to) 
    if(_from < _to) new Range(_from, _to) 
    else new Range(_to, _from) 
    } 
} 

Należy pamiętać, że używanie to jako nazwy zmiennej może prowadzić do pewnych "interesujących" wyników.