I dokładnie taka moja funkcja jest. Zwraca kompletnie nowy obiekt, tylko że z lekko zmienionym "wnętrzem". Nie wiem skąd ten pomysł że zrobiłbym nie immutable obiekty.
Przepraszam, ale nie rozumiem. W takiej sytuacji - czyli gdy zwracasz nowy obiekt, zawierający podzbiór elementów pierwotnego obiektu spełniających pewien predykat - IMO to się powinno nazywać filter
. Ewentualnie subset
. W notacji Kotlinowej, bo Haskellowej nie znam a z Javową mi się nie chce, wyglądałoby to mniej więcej tak:
// jako extension function, żeby nie zaciemniać klasami
fun <T> Kasztan<T>.filter(predicate: (T) -> Boolean): Kasztan<T>
// jako pure function, żeby nie zaciemniać klasami
fun <T> filter(set: Kasztan<T>, predicate: (T) -> Boolean): Kasztan<T>
// z klasowym zaciemnianiem
interface Kasztan<T> {
fun filter (predicate: (T) -> Boolean): Kasztan<T>
}
Zresztą w jakichś szanujących się językach pewnie i tak pod spodem miałbyś prawilną kolekcję, zbiór lub cokolwiek na którym zrobiłbyś dokładnie to: filter
, przepychając dalej predykat :)
a use-case:
Entity c = new C();
Entity b = new B(new Entity(), c, new Entity());
A a = new A(b);
A cleanA1 = a.forEntity(x).substitute(c); // "x" to jakiś predykat, wyciągnie b
A cleanA2 = new A(c);
Dwie ostatnie linijki powinny mieć taki sam efekt.
cleanA1.getEntities(); // [c];
cleanA2.getEntities(); // [c];
Innymi słowy, dostaję new A(new B(new C()))
, i chcę użyć takiej funkcji na tym, żebym dostał new A(new C())
.
Prawdę mówiąc use case dość abstrakcyjny. Dlaczego właściwie predykat
nazywany jest Entity
, a nie po imieniu Predicate
? Łatwiej byłoby rozumować o tym use case. Ogółem jak dla mnie, przy obecnym nazewnictwie, absolutnie niejasne jest co ten kod robi bez czytania postów wyżej.