Jeśli anti-pattern ze stałym interfejsem jest takim przestępstwem, dlaczego Swing to robi?

Question

Robiłem aplikację do swingowania i zdałem sobie sprawę, że mam kilka klas, które wymagają dostępu do tego samego zestawu stałych. Nie mogłem zmusić się do ogłoszenia jednego z głównych posiadaczy i umieszczenia ich tam wszystkich, a inni powinni o tym wspomnieć; Pomyślałem, hej, poproszę, żeby wszystkie dziedziczyły z jakiegoś wspólnego miejsca, ale Java nie robi wielokrotnego dziedziczenia, ALE mogę umieszczać nieskończone interfejsy na rzeczach. Tak więc przyszedł do mnie pomysł, aby zrzucić je wszystkie na interfejs (to prawda, naturalnie przyszło mi to do głowy, nie robiąc żadnych badań).

Później dowiedziałem się, że to jest herezja. "W rzeczywistości jest to taki zły pomysł, że istnieje nazwa dla niego: Antypaństwowy Interfejs Stałego" - as discussed here (wraz z alternatywnym rozwiązaniem (które zdecydowałem się zatrudniać)).

byłem po prostu w porządku z tym aż Szukałem w kodzie źródłowym JDialog i JFrame, który odczytany wygląda następująco:

public class JDialog extends Dialog implements WindowConstants, 
               Accessible, 
               RootPaneContainer, 
           TransferHandler.HasGetTransferHandler 
{ 
... 

i

public class JFrame extends Frame implements WindowConstants, 
              Accessible, 
              RootPaneContainer, 
          TransferHandler.HasGetTransferHandler 
{ 
... 

Może to tylko ja, ale na pewno zobacz tam stały interfejs. Jeszcze bardziej interesująca była jedna z deklaracji autora w JDialog, tj. James Gosling. Ojciec języka zezwalał na ten rzekomy błąd na swoim zegarku?

(Innym godnym uwagi przykładem - SwingConstans)

Jeśli stała antywzorzec projektowy interfejs jest taki zły pomysł, to dlaczego jest tak mocno zatrudniony w jednej z najbardziej znanych pakietów języka (tj huśtawka)?

Answer 1

Lepsze rozwiązanie z użyciem static import nie było dostępne przed wersją Java 5. Do tej pory nadużywanie interfejsów do importowania stałych było uważane za dopuszczalne, ponieważ nie było lepszej alternatywy. Po podjęciu decyzji, że JDialog implementuje WindowConstants (i zapewnia to w dokumentach), nie można tego cofnąć bez łamania wstecznej zgodności. Przykład:

JDialog d = new JDialog(); 
int flag = d.DISPOSE_ON_CLOSE; 

Chociaż prawdopodobnie nie dobry styl, to nie jest tak niezwykłe i pęknie, jeśli chcemy zmienić JDialog użyć importu statyczne zamiast wdrażania WindowConstants.