Pytanie Grać! framework używa statyki


Waaah, gra! framework ma tak wiele metod statycznych. Tam, gdzie chodzę do szkoły, powiedziano nam nigdy aby użyć dowolnej statyki, a jednak Graj! używa go tak, jakby nie było jutra. Czy to w porządku? Jeśli tak, dlaczego?

My (7 osób i ja) zamierzamy skorzystać z gry! ramy dla projektu obejmującego aplikację internetową. Postanowiliśmy zrobić to za pomocą Play! ponieważ wygląda to całkiem zabawnie, wszyscy znamy już Javę, a zadanie jest dość trudne, dlatego chcieliśmy skupić się na samym zadaniu, a nie nauczyć się programowania w innym języku.

Zawsze nam mówiono, że NIGDY używać "statycznych" w każdym opracowanym przez nas oprogramowaniu Java, ale kiedy patrzę na Play! ... Cóż ... około połowa metod jest statyczna. </ przesada>

Przypuszczam, że moglibyśmy przynajmniej użyć obiektów singleton (używając Scala, na przykład ^^) w celu zaprogramowania naszego projektu, ale jestem bardzo zaniepokojony tym, ile statyki istnieje w samej strukturze.

Czy powinienem się tym przejmować? Czy sposób gry! programiści zaprogramowali go tak, aby wszystkie te statyki nie stanowiły problemu?

(Na przykład, ten wątek ma rant o tym, dlaczego należy unikać statycznych członków za wszelką cenę.)


76
2018-03-04 11:06


pochodzenie


Uh ... Powinieneś chyba zapytać swojego profesora, czy kogokolwiek. Dla reszty świata naturalne jest również to, że nie subskrybujesz tych samych pomysłów na temat dobrych i złych praktyk programistycznych, więc przywyknij do tego pomysłu. :) - unwind
@Sew choć korzystanie ze statyki jest odradzane, "NIGDY KIEDYKOLWIEK używaj statyki" jest przesadą - Suraj Chandran
<exaggeration> Tag nie jest widoczny. :) - Nishant
O to chodzi, nasz profesor jest OO-purystą. Zawsze ostrzega nas przed niebezpieczeństwami korzystania ze statyki i będzie miał nasze głowy za używanie statyki, chyba że będziemy w stanie podać przyzwoite wyjaśnienie, dlaczego wciąż ich używamy i nie boimy się konsekwencji. - Saew
@Hishant Teraz jest :) - jensgram


Odpowiedzi:


Gra używa metod statycznych tylko wtedy, gdy ma to sens:

  • w warstwie kontrolera, ponieważ kontrolery nie są zorientowane obiektowo. Kontrolery działają jako programy odwzorowujące pomiędzy światem HTTP (czyli bezstanowym i opartym na żądaniu / odpowiedzi) a warstwą modelu, która jest w pełni zorientowana obiektowo.
  • w warstwie modelu dla metod fabrycznych, takich jak findAll (), count (), create (), które oczywiście nie zależą od konkretnych przypadków
  • w niektórych klasach play.libs. *, które zapewniają wyłącznie funkcje użytkowe

95
2018-03-04 12:31



Oprócz tego głównym problemem są statyczne elementy, a nie metody statyczne. W grze są to tylko wątki wątkowe jako statyczne elementy. - niels
Korzystanie z statyczny validation członek  (widzieć przykład) w połączeniu z a ThreadLocal pokazuje, że statyczne nie jest właściwe we wszystkich przypadkach. - deamon
Jestem przyzwyczajony do posiadania kontrolerów, które mają zależności wstrzyknięte za pośrednictwem frameworka DI. Jak zaimplementować DI przy użyciu obiektów statycznych? - ripper234
@Guillaume Muszę się z tobą nie zgadzać, Play pokazuje najgorsze praktyki pisania Javy i nie powinno być żadnych wymówek do używania staticw kodzie Java, kiedykolwiek. Niestabilność nie jest wskazywana przez statykę, wręcz przeciwnie statyczne wskazuje stan współdzielony co jest prawie przeciwieństwem tego, co twierdzisz. Oczywiście istnieje również wiele zabawnych rzeczy, takich jak wywoływanie statycznej metody na niewłaściwym przykładzie, ponieważ metody statyczne nie są nawet sparowane z klasą, w której są zdefiniowane. Krótko mówiąc, static w Javie jest ogromny zapach kodu i nie powinien być obecny, jeśli chcesz napisać współczesną Javę. - Esko
@Esko Zdecydowanie się z tobą zgadzam, Play może być wartościowa w scala, ale w Javie zawiera listę złych praktyk. - Snicolas


Struktura gry nie jest dobrą demonstracją, kiedy stosujesz statykę, ani nie dowodzi, że Twój nauczyciel był w błędzie. Play to rodzaj oszustwa, rozwiązuje problemy statyki poza językiem Java.

Kluczowym problemem jest równoległe przetwarzanie wielu żądań HTTP, a pola statyczne są "globalne". Będziesz potrzebował jednej instancji na wątek (lub nawet lepiej, jednej instancji na żądanie HTTP) dla pewnych rzeczy, ale niektóre z tych rzeczy są zwracane przez statyczne metody w Grze. To działa, ponieważ Play! używa ThreadLocal-s mocno, więc rozwiązuje problem statyki poza językiem Java. Ale to nie wszystko. Niektórzy twierdzą, że metody kontrolerów są słusznie statyczne. Oczywiście, ale w zwykłej Javie byłoby to niewygodne, ponieważ wtedy nie można uzyskać dostępu do danych specyficznych dla żądania bez pewnego rodzaju prefiksu, na przykład req. w req.session, a następnie nadal musisz dostać req skądś, tak jak jako parametr metody sterownika statycznego, który jest jeszcze bardziej kłopotliwy. Jednak w Play możesz wprost napisać session i jak, oni są po prostu statycznymi polami. Dzieje się tak dlatego, że Play używa instrumentacji kodu bajtowego, aby zmienić wszystkie te odniesienia pola statycznego na coś mądrzejszego. Znowu rozwiązanie poza językiem Java. To nie są statyczne pola na końcu.

Tak więc, na ogół, unikaj nieostatecznej statyki. Gra jednak robi magię, więc nie bój się ich w tym przypadku.


34
2017-08-04 19:15





Z bardzo krótkiego punktu widzenia, powiedziałbym, że to ma sens: żądania internetowe są bezpaństwowcami, więc istnieje jest brak obiektu do otrzymania żądania (= metoda). Zatem mapowanie URI, takie jak "/ articles / archive? Date = 08/01/08 & page = 2" do statycznej metody o nazwie archive() Tak, myślę, że twoja klasa aplikacji ma sens.


15
2018-03-04 11:12





EDYTOWAĆ Teraz w Play 2.4, wstrzyknięcie odbywa się automatycznie. Więc wystarczy dodać @ na początku ścieżki kontrolera w pliku routes zrobi lewy:

GET     /                  @controllers.Application.index()

W starszych wersjach (od 2.1 do 2.3) będziesz musiał nadpisać getControllerInstance w klasie Global, jak wyjaśniono w Dokumentacja.


8
2017-12-14 01:59





Podobnie jak w przypadku wszystkich programów, nigdy nigdy nie jest właściwą odpowiedzią. Tak jak zawsze. Zawsze są wyjątki, a właściwą odpowiedzią jest zawsze "to zależy".

To prawda, że ​​w czystym OO (po którym jestem wszystkim) jest bardzo mało miejsca na statykę. Ale prawdą jest również, że czasami mają sens.

Klasycznym przykładem są metody użytkowe. Oczywiście, byłoby lepiej, gdybyśmy mogli po prostu dołączyć nasze abs() metoda do liczby całkowitej. Ale nie możemy; więc utknęliśmy Math.abs(int i).

Uważam, że poprawne jest uczynienie metody statyczną, gdy nie ma ona nic wspólnego z samą instancją. Na przykład w klasie Person, możesz mieć metodę, która pobiera listę osób i zwraca liczbę osób, które dzisiaj mają urodziny. Być może możesz to zrobić tylko w samej klasie, jeśli dane potrzebne do obliczenia są prywatne (coś, co zrozumiałby purystyczny OO);) jednak metoda ta wyraźnie nie ma związku z pojedynczą instancją Osoby.

Kolejną rzeczą są klasy wewnętrzne. Często chcesz, aby były statyczne, jeśli nie potrzebujesz relacji z typem zawierającym.

nigdy nie widziałem Grać! ale jeśli powiesz, że ponad 50% z nich jest statyczne, to domyślam się, że był źle zaprojektowany. To nie jest wyjątkiem; wiele frameworków. Nie pozwól, aby cię to zepsuło. Zdecydowanie nie ucz się od tego!
Ale jeśli to działa, nadal możesz z niego korzystać.


5
2018-03-04 12:11



Gra nie jest źle zaprojektowana, ale jest odejściem od sposobu zaprojektowania większości bibliotek Java. - Marcus Downing


Głównym problemem jest to, że statyczne metody mają tylko dostęp do innych statycznych metod i pól, co skutkuje "statycznym przylgnięciem", w którym statyczne metody muszą spotykać się z resztą aplikacji (która zawiera swoich współpracowników) za pośrednictwem wspólnego (-ych) pola (-ów) statycznego , co prowadzi do braku elastyczności.

Oświadczenie: Nie wiem zbyt wiele na temat "gry!"


4
2018-03-04 11:41





Metody kontrolerów statycznych są z pewnością przedmiotem zainteresowania Play! i po przeprowadzeniu testów jest to główny powód, dla którego nie gram Play! w projektach. Możesz to zobaczyć w projektach FOSS, w których grasz! Jest używane. Testowanie kontrolera jest niewielkie lub żadne. Powód, w przypadku metod statycznych, DI staje się trudny. To tam powinni spędzić jeszcze więcej czasu z ASP.NET MVC, skąd grać! już wymaga trochę inspiracji.

Zazwyczaj masz konstruktora takiego jak to:

public HomeController( IService service ) {
   _service = service;
}
public Index() {
   var data = _service.getData();
   return View( data );
}

Następnie użyj DI, aby wprowadzić implementację IService do kontrolera. Chodzi o to, że w twoich testach możesz utworzyć instancję IService tuż przed uruchomieniem kontrolera, a następnie przetestować wynik na podstawie właśnie wyprodukowanej IService.

W grze staje się to bardzo trudne. W ten sposób testowanie jednostek sterujących staje się trudne. To dla mnie istotny problem. W związku z tym starałbym się szukać innych frameworków niż Play! w świecie Java. Heck, czemu nie pójść z oryginałem i po prostu użyć JRuby?


4
2017-10-29 12:36