Czy klasy będące strategią mogą mieć same metody statyczne, jeżeli są bezstanowe?

Ktoś mnie kiedyś nastraszył, że metody statyczne to zło i teraz mnie to prześladuje. Opinie w sieci jeżeli chodzi o same metody statyczne są podzielone:

One rule-of-thumb: ask yourself "does it make sense to call this method, even if no Obj has been constructed yet?" If so, it should definitely be static.

The basic issue with static methods is they are procedural code. I have no idea how to unit-test procedural code. Unit-testing assumes that I can instantiate a piece of my application in isolation. During the instantiation I wire the dependencies with mocks/friendlies which replace the real dependencies. With procedural programing there is nothing to "wire" since there are no objects, the code and data are separate

Właśnie siedzę nad wzorcami projektowymi i po prostu pasuje mi tutaj metoda statyczna.. mimo to na wszystkich stronach, gdzie ten pattern jest tlumaczony jest to zwykła klasa, którą instancjujemy.

Argument z testowaniem trochę do mnie nie przemawia, ale nie mam dużego doświadczenia w TDD, w zasadzie ucze się wszystkie na raz. Jeżeli np. mam strategie sortowania, to mogę przecież zrobić assercję na [1, 2, 3, 4, 5] i sprawdzić, czy po sortowaniu metoda zwraca mi tablicę posortowaną czy nie.

@Desu

1. Static jest ok ale w zasadzie tylko dla metod typu utils które zawsze działają i są oczywiste i proste i zwykle bardzo krótkie. Coś jak np. jakieś StringUtils. Jeśli coś jest bardziej złożone to lepiej zrobić z tego nowy serwis.
2. Static testuje się ciężko. Są frameworki jak Powermock które na to pozwalają, ale jest to dość skomplikowane. Jak chcesz mockować wywołanie tego swojego statica dla testu jednostkowego? Jak chcesz przetestować jakiś fragment systemu BEZ sprawdzania jednocześnie czy działa milion innych elementów systemu? Jak wszędzie używasz staticów to twój test też będzie je wołał i zamiast testować jedną metodę testujesz tą metodę plus kupę staticów. W efekcie testy mogą failować ze względu na zmiany w zupełnie innej części systemu, a to znaczy ze takie testy są słabe.
3. Kod ze staticami ciężko rozszerzać bo static nie jest polimorficzny. Nie można sobie łatwo podstawić innej implementacji pod interfejs bo dla static to nie zadziała. Więc nici zasady open-close.

Test który opisałeś to dość słaby test, taki raczej "sanity-test" i z testem jednostkowym niewiele ma wspólnego. Test może przechodzić mimo że metoda wcale nie działa a to czyni go malo użytecznym. Zgodnie z zasadą, że popsuty zegar dwa razy dziennie pokazuje dobrą godzinę...

Strategia to interfejs + jego implementacje. Czy język, w którym piszesz, pozwala na to, aby metodę z interfejsu implementować jako statyczną?

@Shalom dzięki za szczegółową odpowiedź.

@somekind, problem z głowy, dzięki. Tak mnie zaślepiła ta myśl o statycznych metodach, że kompletnie nie wpadłem na to, że jest to niemożliwe do zaimplementowania.