Więcej klas, mniej kodu.

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.

8 thoughts on “Więcej klas, mniej kodu.

  1. 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).

    1. 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.

    1. 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 🖖

        1. KodCzęść? CzęśćKod? Brzmi trochę jak facebook – twarzo książką. Pewne rzeczy powinny zostać w oryginale. Bo czy międzymordzie coś mówi?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.