Czy mutowanie obiektów metodą void to dobra praktyka?

0

Hej.
Spotykam się często w pracy z kodem, w którym obiekty są mutowane metodami void. Na przykład zamiast zrobić mapper, który zwróci nową instancję pożądanego obiektu to tworzona jest voidowa metoda, która nadpisuje elementy już utworzonej instancji.
Np:

public ObjectA someMethod() {
ObjectA a = new Object(//some values);
ObjectB b = new Object(//some other values);
copyProperties(b,a);
return a;
}

private copyProperties(ObjectB source, ObjectA target) {
target.setSomeProp(source.getSomeProp);
// etc.
}

Czy to jest okej praktyka czy nie bardzo? Ja czuję, że to bardzo słaby pomysł i do tego mało czytelny. Czy się mylę?

6

Nie jest. Często ciężkie do testowania, niemożliwe to łatwego ogarnięcia kiedy coś się w obiekcie zmienia, trudne we wspólbieżnym kodzie.

2

A jeszcze jak taki obiekt jest przepychany przez parę warstw i tam modyfikowany to już w ogóle tragedia

0

No właśnie tak sobie siedzę, psioczę na kod, poprawiam kwiatki i musiałem się upewnić czy prawilnie psioczę :D

2

I tak, i nie. Łatwo w tym wpaść w pułapkę, ale samo podejście nie jest z definicji złe, a nawet jest w teorii podstawą OOP (wszak obiekt to tożsamość, zachowanie i stan, więc zmiana tego stanu jest nieodłącznym elementem życia obiektu). Historia pokazuje, że nie jest łatwo nad tym panować, powstają god objecty, kosmos przy programowaniu współbieżnym, testy polegające na prywatnym stanie. Z drugiej strony DDD wprowadza jakąś metodykę do tego, co pozwala panować nad zmieniającymi się obiektami.

Resumując: jak się wie, co się robi (i ma się doświadczenie), to może to działać. Jak się nie wie, to bardzo łatwo zepsuć.

0

Co słowa "metodą void" wprowadzają do wątku? Bo nie rozumiem.

2

Mutowanie to zło.
Metody void to zło.

Kumulacja.

1

Ten mem idealnie to opisuje

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