konstruktor i przypisanie wartości zmiennym

0

Mam pytanie o dobry sposób na przypisanie wartości zmiennym jakiegoś obiektu w czasie konstruowania lub zaraz po.
Chodzi mi dokładnie o taką sytuację, kiedy mam jakąś większą klasę z masą zmiennych definiujących jej "działanie".
Wiem, że mogę zdefiniować te zmienne poprzez konstruktor, jednak jeśli jest ich więcej to robi się to trochę nieczytelne:

obiekt jakiś = nowy obiekt(15, "text", true, 22, ...itd....) - o to mi się nie podoba

Można też skonstruować obiekt, a potem metodami ustawiać te zmienne, ale to mi wygląda na jeszcze więcej głupiej roboty...

Jak zrobić to najsprytniej ? (w Java...)

Widziałem gdzieś taki kod, który być może jest tym czego szukam, bo wygląda ciekawie, ale nie rozgryzłem o co tu chodzi... (czy to jest Java w ogóle??):

Configuration conf = new Configuration.Builder()
        .iterations(1)
        .weightInit(WeightInit.XAVIER)
        .activation("relu")
        .optimizationAlgo(OptimizationAlgorithm.STOCHASTIC_GRADIENT_DESCENT)
        .learningRate(0.05)
1

Tu masz dwa losowe artykuły o tym, to jest wzorzec projektowy i nazywa się builder. Korzystając z lomboka załatwia się to 1 adnotacją
https://www.javaworld.com/article/2074938/core-java/too-many-parameters-in-java-methods-part-3-builder-pattern.html
https://www.journaldev.com/1425/builder-design-pattern-in-java

Odpowiadając na twoje pytanie - to zależy. Jeżeli masz pola, które są wymagane do utworzenia obiektu poprawnego z punktu widzenia biznesowego to przekazujesz je przez konstruktor (lub np builder czy factory method, które i tak ten konstruktor wywołają za ciebie). Pozostałe pola możesz ustawić później.

Również losowy artykuł z sieci o factory method:
https://jlordiales.wordpress.com/2012/12/26/static-factory-methods-vs-traditional-constructors/

Po więcej możesz sięgnać do ksiązki Design Patterns: Elements of Reusable Object-Oriented Software lub po prostu pogooglować frazę design patterns/wzorce projetowe

3
hcubyc napisał(a):

Odpowiadając na twoje pytanie - to zależy. Jeżeli masz pola, które są wymagane do utworzenia obiektu poprawnego z punktu widzenia biznesowego to przekazujesz je przez konstruktor (lub np builder czy factory method, które i tak ten konstruktor wywołają za ciebie). Pozostałe pola możesz ustawić później.

I tu rodzą się pytania:

  1. czemu obiekt w ogóle ma pola, które nie są istotne?
  2. kiedy (bo to, że tak się stanie jest pewne) program się wywali, bo okaże się, że "nieistotne" pole jest jednak istotne?
  3. czemu konstruować obiekty tylko w połowie?
  4. czemu obiekt w ogóle ma tak dużo pól?

A builder daje tylko wygodne API do konstruowania, nie rozwiązuje problemu z obiektem prawdopodobnie łamiącym SRP albo jeszcze coś gorszego.

1 użytkowników online, w tym zalogowanych: 0, gości: 1