Inżynieria oprogramowania, Kariera

Spotkania kształcą

Spotkania kształcą

mówi się, że podróże kształcą, jednym z elementów podróży są spotkania z ludźmi, często przypadkowymi.

Oko w Oko

Podczas spotkań, np związanych z pracą, można dowiedzieć się czegoś co nie koniecznie musi być popularne.

Mając okazję spotkania się w oko w oko z programistą, który miał sprawdzić moją techniczną wiedzę napotkałem na ciekawy przykład prostego rozwiązania, gdzie każdy ma jasność co to jest Single Responsibility ale nie każdy ma jasność jak w praktyce to zastosować.

Wiele młodych (cazsem również starych) nie doświadczonych programistów stosuje na ślepo pewne rozwiązania nie zastanawiając się nad duchową sferą programu, filozofi tworzenia.

Przykład

Kolekcja danych, która powinna przechowywać obiekty klasy.

Implementacja nr 1

Jak zdefiniować elementy wchodzące w jej skład, jak je sprawdzić?

Na drodze do rozwiązania stoją nieraz proste przeszkody jak konstruktor.

Czy tworząc instancję klasy, oczekujemy, że dane podane w konstruktorze będą opcjonalne?

Jeśli tak, to dlaczego są opcjonalne, być może można je stworzyć w innym miejscu, gdzie od początku bedą niezbędne? czy jest to zgodne z zasadami dobrego kodowania, jak wyżej, wzorzec Single responsibility?

Co jeśli okaże się, że w ogóle obiekt klasy jest opcjonalny?

Wówczas pytanie, po co w ogóle istnieje i zajmuje przestrzeń w pamięci?

Implementacja nr 2

Idąc w drugą stronę…

A co jeśli żaden parametr nie będzie opcjonalny?

Czy można dopuścić do zapisywania pustych tablic?

Czy tablica bez elementów jest tablicą którą oczekujemy?

Do czego jej potrzebujemy?

Po co wówczas tworzyć całą otoczkę kolekcji z implmentowaniem interfejsu Iterator?

Skoro dopuszcamy pustą klasę?

Wnioski

Myślę, że warto brać pod uwagę konsekwencje naszych działań.

Warto opierać Opierać je o zdarzenia, jakie następują w obrębie danej lokalnej sytuacji.

klasy

np. Klasy tworzymy z myślą o ich użyciu nie tylko jako silnej reprezentacji typu danych, ale również oczekiwanej strukturze, jeśli struktura ta w postaci np parametrów jest opcjonalna, to znaczy, że klasa jest niewystarczająco wyspecjalizowana.

Oczywiście tak jak w życiu codziennym w zależności od użycia danego narzędzia mamy wiele opcji ich użycia, ale w programowaniu sposób użycia powinno się definiować po wstrzyknięciu używając wzorca Dependency Injection a nie przy samym fakcie stworzenia objektu klasy.

Zmienne typy: array, integer

O ile globalne zmienne często mogą ulegać zmianie, o tyle lokalne tworzone pod konkretne zastosowanie powinny być ściśle określone.

Czy jeśli np. chcemy usunąć wszystkie elementy tablicy to chcemy w ogóle ją posiadać?

Może zamiast ją wypełniać na nowo, lepiej ją stworzyć nową instancję kolekcji?

… która i tak bedzie musiała mieć wszystkie inne parametry na nowo ustawione?

Podziękowania

Dziękuję za to spotkanie każdemu i zapraszam do podzielenia się Waszymi doswiadczeniami ze spotkania.

 

 

 

Tom
Latest posts by Tom (see all)
Tagi: , , , , , , , , , , , ,