Cześć,
Mam taki dylemat:
"Komponent" to może być np klasa, angularowy @Component, war, api (oddzielić na początku dla różnych typów klientów czy jedno z ifem gdzieś na dole). Interesuje mnie czym się kierują wybierający 2.
Nie wiem jak jest w Angularze, ale:
Co jest optymalne - to zależy od przypadku. Zazwyczaj jednak podejście "jeden duży komponent na wszystko" kończy się czymś takim: https://en.wikipedia.org/wiki/God_object i wtedy utrzymywanie czegoś takiego to koszmar.
też nie w Angularze ale jeżeli mają część wspólną to niektórych skłania do robienia jednego dużego obiektu bo wydaje im się że tak łatwiej niż powielać logikę przez copy&paste. Czasem jednak powielają i wtedy koszt wprowadzenia jednej małej zmiany do tej logiki mocno rośnie.
Podejście jakie ja preferuje to albo wydzielenie tej logiki do osobnej klasy i korzystanie z jej obiektów w tych komponentach
albo zastosowanie jakiejś formy dziedziczenia
Czasem jednak powielają i wtedy koszt wprowadzenia jednej małej zmiany do tej logiki mocno rośnie.
Wydzielanie to nie zawsze jest rozwiązanie. Czasem lepiej jest poczekać.
Jeśli Twoja abstrakcja będzie nieszczelna wtedy ponosi się jeszcze większy koszt.
Zostawiam do poczytania: https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction
a co ma z tym wspólnego że lepiej poczekać? I co mamy robić w czasie tego czekania, które podejście z pierwszego posta jest lepsze i dlaczego?
Wstrzymanie samo w sobie nie jest rozwiązaniem, ale daje przestrzeń na przygotowanie rozwiązania. Od teraz masz powód, by obserwować, wychodzić z różnymi pytaniami, perspektywami jakie może pozwolą Ci zobaczyć więcej niż na początku widziałeś. To podejście umożliwi Ci podjąć właściwie działanie, i poznać odpowiedź która rozwiąże problem.
Przy wydzielaniu unikaj biznesowego myślenia. Biznes jak przedstawia historyjkę do zaimplementowania to zawsze robi to od strony interaktywnej. Oni mówią co się ma wydarzyć, jakie efekty chcą zobaczyć w programie, bo właśnie te efekty są dla nich wartością tworzonego programu.
Jak zaczniesz pracę od koncentracji na efektach, wtedy różne konteksty zaczną się nakładać na Twoją pracę. Nie ogarniesz ich zbiorczo. Jeśli będziesz próbował je uogólniać to za każdym uzyskasz nieszczelną abstrakcje, ponieważ nigdy nie będziesz miał kontroli nad wymaganiami jakie otrzymasz od klienta.
Tutaj co mogę wskazać to powrót do podstaw: najprostsze w kontroli są te abstrakcje które są skupione wyłącznie na jednym kontekście.
Pomyśl jak proste jest napisanie kodu, który liczy sumę? Albo jak proste jest zapisanie kodu, który tylko zajmuje się zapisaniem tekstu do dowolnego miejsca, albo jak proste jest iterowanie gdy nawet nie znasz kolekcji itp - jeśli chodzi o pracę nad jednym kontekstem, my programiści mamy tutaj ogromną swobodę zarówno do wyrażania osi obrotu, jak i błyskawicznej oceny czy ona ma dla naszego probemu sens.
Tutaj nie ma pół środków. Wystarczy tylko dwa konteksty na raz i już tracimy kontrolę, wybrany fragment kodu przypomina niechlujny skrypt niż pomyślany kod. Przykladowo jeśli Twój komponent coś wylicza i wyświetla, to już tego warto nie uogólniać (mimo, że kusi), bo jeśli to zrobisz to każda zmiana dotycząca wyliczeń i każda zmiana dotycząca wyświetlania może zacząć wyciekać, to zaraz popsuje Ci interfejs i wpłynie na wszystkie inne miejsca które są od niego zależne.
Podsumowując buduj wyrafinowane i piękne abstrakcje oddolnie, a do góry wypychaj rzeczy nad którymi nie możesz mieć kontroli.
@pan_krewetek: czyli zakładasz że nie mamy wiedzy o systemie ani możliwości jej zdobycia a tylko jeżeli zbierze się dostatecznie wiele różnych historyjek zaczniemy coś rozumieć. Ja pisałam z punktu widzenia osoby która ma jakieś pojęcie o całości, oczywiście ta całość może się zmienić z przyczyn niezależnych np. zmiana przepisów, ale pewną informację na start już się ma.
Zakładam tylko, że coś może się zmienić, a zwłaszcza coś na co nie mam wpływu lub coś czego jeszcze nie wiem.
jeżeli zbierze się dostatecznie wiele różnych historyjek zaczniemy coś rozumieć
Jak myślisz, w jaki sposób rodzą się wartościowe abstrakcje, biblioteki, narzędzia, języki? Ktoś sobie siada pije kawkę, wymyśla sobie nieistniejący i nikomu niepotrzebny problem i próbuje go rozwiązać?
Jest odwrotnie. Musisz mieć dużo spokrewnionych problemów (najlepiej takie, które bolą!) i dopiero wtedy widać więcej, to też więcej możesz zrozumieć, i łatwiej tak zwracasz uwagę na to co ma znaczenie[0]. Połączenie wiedzy wraz ze zdobytym doświadczeniem umożliwia spojrzenie na sprawę z wielu perspektyw, dzięki temu określasz płaszczyznę na której warto określić problem, na której warto stoczyć z nim bój.
[0] - zwrócenie uwagi na to co ma znaczenie to punkt w którym wszystko się zmienia, ponieważ przy wyznaczaniu abstrakcji musisz z czegoś zrezygnować, coś odrzucić (czasem to trudne, bo trzeba zrezygnować z czegoś co było dla Ciebie fundamentalne), by uzyskać korzyść w miejscu, które ma dla Ciebie większą wartość.