Prywatne medoty statyczne, pola finalne

1. Jeżeli metoda prywatna w klasie nie potrzebuje dostępu do stanu obiektu to lepiej aby była statyczna
   czy nie ma to znaczenia? Jedyne co mi przychodzi do głowy to, że niejawnie this nie jest przekazywany
   więc de facto mniej stosu zużywamy z tym, że to jest tylko 8 bajtów więc kto by liczył.
   A może powinniśmy unikać prywatnych metod statycznych i wyciągać je do jakichś publicznie dostępnych
   utilsow tak aby nie powielać logiki?

2. Jest taka zasada, że zmienne, które mogą być final powinny być final.
   Czy stosujecie się do tego zawsze np. w parametrach metod też dajecie, że są final?
   Jakie jest wasze podejście do tej zasady? Osobiście pola w klasie zawsze robię final
   jeżeli takie mogą być natomiast zmienne w metodach rzadko przeważnie tylko wtedy
   gdy metoda jest dłuższa i realizuje jakiś algorytm wtedy np. na jej początku mam stałe
   i później to jest pomocne bo niżej przez przypadek nie nadpiszę.

Ad.1. Nie ma żadnego stosu. Tak, że bajtami sie nie przejmuj. (Tzn. Niby jest, ale nie ma. This prawie zawsze poleci Ci w rejestrze, a stosem nie ma sie co przejmowac. Chyba, ze ostra rekurencja bedzie szła).
Ogólnie odpowiedz na oba pytania to : kwestia smaku.
Ja robie te finale, ale nie ma to żadnego sensu. Takie prywatne wyżywanie sie na javie.

Static vs private nie jestem konsekwentny. Robie i tak i tak.
(Ale tak po prawdzie to raczej robiłem jak kiedyś pisałem w javie).

1. Prawie nigdy nie robię static, potem jak okazuje się że trzeba sięgnąć do pola to trzeba się bawić w usuwanie static.
   Jeżeli metoda nie dotyka żadnego z pól klasy to jest to też code-smell że może jednak nie jest ona umieszczona we właściwej klasie.
   Najczęściej łamana jest tutaj zasada http://principles-wiki.net/principles:single_level_of_abstraction

2. Nienawidzę jak ktoś obsrywa final parametry metod. Takiego kodu nie da się potem po prostu czytać. Nie wiem czy tych ludzi ręce nie bolą, czy może płacą im od ilości znaków?

final ma swoje zastosowania, przede wszystkim są to pola w klasach. W metodach nie stosuje, bo piszę krótkie i na pierwszy rzut oka widać co się zmienia a co nie. A dużo się w ogóle nie zmienia. Od javy 10 (a możę 11?) jest var warto korzystać, ale nawet tam spieprzyli final nie można sobie napisać final foo = "blah"; trzeba dawać final var foo = "blah"; (https://openjdk.java.net/projects/amber/LVTIFAQ.html)

lookacode1 napisał(a):

Czy stosujecie się do tego zawsze np. w parametrach metod też dajecie, że są final?

Parametry final, to subtelność / ułomność jak w środku jest kod klas anonimowych, jak robiłem we frameworku który je miał, kompilator sam się darł o final
Nie pamiętam, abym z dobrej woli dał.

Powiedziałbym nawet, ze przy pobieżnym czytaniu kodu myli, jeśli będący parametrem obiekt jest mutowalny, sugeruje coś innego, niż jest

Im bardziej ktoś pozna języki gdzie jest prawdziwa niemutowalność, tym bardziej śmieszy javove final. A już całkiem śmiesznie jest final List .... list; list.add(..). Albo tworzą objekt final a w następnej linijce jeb mu setterem. Argument jest podobny co tabs vs spaces - kompletnie bez różnicy ale niektórzy są gotowi bronić go jak niepodległości.
Jednak pracując w zespole trzeba się przygotować na takie fetysze u niektórych i zamiast się kłócić o pierdoły to trzeba pchać ten wózek.

Jeśli dobrze rozumiem to final jest odpowiednikiem readonly w C#. Faktycznie, dla kogoś przyzwyczajonego do pełnej niemutowalności może to wyglądać dziwnie, ale bierze się to trochę z pewnej nadinterpretacji i błędnego przeświadczenia że wszędzie chodzi o niemutowalność. Podam przykład z C#, ale sens ten sam co przy użyciu final:

class SomeClass
{
  private readonly _myService;

  public SomeClass(MyService myService)
  {
    _myService = myService ?? throw new ArgumentNullException();
  }

  public void DoSomething()
  {
    _myService...
  }
}

Tutaj readonly nie służy do zapewnienia że mam niemutowalny obiekt, tylko że zależność jest gotowa do użycia (co jest zapewnione przez konstruktor) oraz że nie może zostać w innym miejscu zmieniona (np. poprzez przypisanie null do pola).

. Albo tworzą objekt final a w następnej linijce jeb mu setterem. Argument jest podobny co tabs vs spaces - kompletnie bez różnicy ale niektórzy są gotowi bronić go jak niepodległości.

Bo final jest na wartość referencji a nie na wartość listy. Jak ktoś rozumie działanie pamieci w Javie to wtedy to wtedy final nie jest śmieszny.