Mam czasem takie klasy, które służą za konfiguracje, gdzie trzeba konfigurować z paluszka właściwości, właściwie to większość pracy wtedy polega ^C^V i zmiany części właściwości na inne.
Wyobraźmy sobie taki kod, gdzie trzeba na przykład generować jakieś dokumenty i chcemy mieć ładne “trzcionki” 🤦♂️(na wypadek, gdyby ikona była za mało sugerująca).
Pewnie jest na to jakaś fachowa nazwa. Jeśli ją znasz, daj mi proszę znać – jak nie umiem tego nazwać, znaleźć konkretnej nazwy wzorca.
I aby oprogramować kilka różnych wersji należy za każdym razem podawać rodzaj, rozmiar, czy dodatkowy styl:
Co powoduje sporą ilość duplikacji kodu – nie moje gusta. Kiedyś kolega powiedział mi, skoro wiem jaka to będzie wartość, to można ją od razu ustawić i nie trzymać zmiennej. Można więc dołożyć kilka klas, które będą mówić kim/czym są, a jednocześnie będą potrzebować mniejszej ilość parametrów wejściowych podczas tworzenia obiektu. Tak to może wyglądać:
Mając tak zdefiniowane klasy inicjalizacja się skraca do takich kodów:
No i tyle. Jest krócej. Jest czytelniej. Tym razem moje gusta. Sprawy do dyskusji to czy ArialItalicFont czy AlternativeArialBoldFont bo to już zależy od tego co kto lubi bardziej.
Czy te specyficzne klasy do osobnych plików (klasa-per-plik) czy jednak okej, na te krótkie klaski. Czy enum w foncie czy na zewnątrz. Czy puste klamry konstruktora inline, czy w osobnych – ale to wszystko nie ważne.
Jeśli jest dużo możliwych kombinacji (nazwa rodziny fontów, rozmiar, style), to rozwiązaniem poprawiającym czytelność, a jednocześnie redukującym ilość klas byłoby użycie buildera (albo inaczej assemblera). Wtedy można by uzyskać coś takiego: `var font = new FontBuilder().WithFamily(“Arial”).WithBoldStyle();` Aczkolwiek to raczej by było bardziej pomocne przy większej ilości parametrów albo w przypadku jakichś powiązań między parametrami (np. że Comic Sans nie może być bold).
Jasne. Można iść daleko w las szukając coraz to lepszych rozwiązań. Ja pokazałem to, które robi u mnie robotę i wymaga mniejszej ilości kodu. U Ciebie jest jeszcze bardziej opisowo (na plus), ale tak jak piszesz będzie to przydatne przy bardziej skomplikowanych rozwiązaniach.
To o czym napisał Robert to Fluent Builder Pattern. Moim zdaniem bardzo czyste i rozsądne rozwiązanie opisywanego problemu nawet przy tylko trzech możliwych parametrach 🙂
Pozdrawiam!
Błagam, tylko nie trzcionki…
A ikonka sie obok sie nie wyswietlila?
Cześć 🙂 nie mam pojęcia jak to nazwać, ale wydaje mi się że dokładnie ten sam mechanizm udostępnia Python jako funkcję “partial” – https://mmazurek.dev/partial-w-pythonie-zastosowanie-przyklady/
Zgadzasz się że to to samo?
Jeśli tak to może nazwiemy ten wzorzec… Partial 🙂
Kto ma tworzyć ten świat IT jak nie My? 😀
Partial byłby fajny, niestety jest już zajęty 😪
W C# jest takie słowo kluczone i umożliwia rozłożenie definicja klasy po kilku plikach/miejsca w projekcie. W samym javascript też widzialem takie coś przez użycie domknięć.
Natomiast jeśli chcesz możemy to nazwać PartialEx, Partial2, PartialPol – daj znać, którą nazwę wybieramy 🖖
A może CodePartial? Tylko jak to sprytnie przetłumaczyć na polski?
KodCzęść? CzęśćKod? Brzmi trochę jak facebook – twarzo książką. Pewne rzeczy powinny zostać w oryginale. Bo czy międzymordzie coś mówi?
O rany.. niby takie proste a łatwo się zgubić, zwłaszcza gdy ktoś nie jest wyszkolony i nie jest to jego główne zadanie. Warto pójść na jakiś kurs wtedy wszystko jest jakoś bardziej przyswajalne 🙂
Działa? działa! 🙂 “less code more power” :))
Nie dość, że mniej kodu to dla mnie jest on czytelniejszy 🙂