Czy nadmiarowy kod jest akceptowalny, jeśli poprawia czytelność?

Question

Mam następujący kod, aby sprawdzić, czy jednostka gry jest graczem lub wrogiem. To są tylko dwie kategorie. Mógłbym usunąć metodę isEnemy i uruchomić wszystkie kontrole dla wroga tak, jakby (! IsPlayer), ale osobiście uważam, że jeśli (isEnemy) cel jest wyraźniejszy. Czy istnieją ustalone style kodowania, które mają cokolwiek do powiedzenia na temat tego rodzaju sytuacji?

public boolean isPlayer(Unit unit) { 
    return unit == player; 
} 

public boolean isEnemy(Unit unit) { 
    for (Unit e : enemies) { 
     if (unit.equals(e)) 
      return true; 
    } 
    return false; 
} 

Answer 1

Myślę, że posiadanie obu metod jest do przyjęcia. ! Jeśli isEnemy() == isPlayer() Chciałbym rozważyć wdrożenie isEnemy() jako:

public boolean isEnemy(Unit unit) { 
    return !isPlayer(unit); 
} 

W ten sposób można zyskać czytelności mające dwa specyficzne metody, ale niekoniecznie powtarzając sobie, jak gdyby można dostosować isPlayer() i wpływa na obie metody.

Answer 2

Moim zdaniem jest to całkowicie dopuszczalne. Zwłaszcza w dużym projekcie czytelność jest bardzo ważna. Weź również pod uwagę, że jeśli dodasz trzecią rolę w przyszłości, nie będziesz mógł użyć, jeśli (! IsPlayer).

Answer 3

Osobiście zaimplementuję isEnemy() jako !isPlayer(), ale mam assert, który uruchamia pętlę, aby upewnić się, że naprawdę jest wrogiem.

Answer 4

W twoim przypadku masz tylko dwa możliwe stany - są albo wrogami, albo graczami. Jeśli są graczem, nie są wrogami. Najczystszym sposobem na wyrażenie tego byłby !isPlayer.

Jeśli miałeś inne możliwe stany, możesz chcieć przyjrzeć się wyliczeniom na temat innych stanów.

Zgodnie z ogólną zasadą: Don't Repeat Yourself. Jeśli jedna część twojego kodu ulegnie duplikacji (może naprawić błąd), musisz zmienić każde wystąpienie tego błędu. Może przekształcić się w koszmar utrzymania.

Answer 5

Patrząc na swój kod, identyfikujesz wroga, jeśli jest on obecny w kolekcji "wrogowie". Więc wróg nie jest w zasadzie kimś, kto nie jest graczem. Jeśli chcesz wymusić to semantyczne, nie sądzę, że powinieneś uciec z metodą isEnemy().

Innym powodem, dla którego możesz potrzebować metody isEnemy() jest, jeśli widzisz możliwość, aby inny typ powiedział Ally. Posiadanie metody isEnemy() sprawi, że dodanie będzie prostsze i czystsze.

Ale jeśli powyżej 2 warunków nie są ważne, pozbądź się go. Jak mówią YAGNI :)