SOLID zasady i ciężko konfiguracja kod wewnątrz klasy

Question

zauważyłem w partii kodu ostatnio, że ludzie umieścić zakodowanego konfiguracji (takie jak numery portów, etc.) wartości głęboko wewnątrz klas/metod, przez co trudno znaleźć, a także nie można go konfigurować.

Czy jest to naruszenie zasad Solid? Jeśli nie, czy istnieje inna "zasada", którą mogę przytoczyć członkom mojego zespołu, dlaczego nie jest to dobry pomysł? Nie chcę po prostu powiedzieć "źle, bo mi się nie podoba", ale mam problem z dobrym argumentem.

Answer 1

Dobrym argumentem przeciwko hardcoding numer portu TCP w klasie byłoby naruszenie „niezależność Context”. Od GOOS z moim naciskiem:

Kontekst Niepodległości

... „kontekst niezależność” reguła pomaga nam zdecydować, czy obiekt ukrywa zbyt dużo lub ukrywa błędne informacje. System jest łatwiejszy do zmiany , jeśli jego obiekty są niezależne od kontekstu; to znaczy, jeśli każdy obiekt nie ma wbudowanej wiedzy o systemie , w którym wykonuje on. Pozwala to nam na przyjęcie jednostek zachowań (obiektów) i zastosowanie ich w nowych sytuacjach: . Aby być niezależnym od kontekstu, niezależnie od tego, jaki obiekt potrzebuje, aby uzyskać informacje o większym środowisku, które jest uruchomione w , należy je przekazać w.

W tym konkretnym przypadku Context Independence nazwałbym to "niezależnością środowiskową". Innymi słowy klasa z zakodowanym numerem portu ma nieodpowiednią zależność od środowiska wykonawczego systemu operacyjnego, zasadniczo mówiąc: "Wiem, że port 7778 zawsze będzie dostępny", co jest oczywiście błędne.

Answer 2

Zasady SOLID obejmują projektowanie klas.

Podejrzewam pomysł, że należy zapisać konfigurację w plikach konfiguracyjnych nie jest zwykle uważany za dość kontrowersyjny, aby uzasadnić wynalezienie specjalną zasadę, aby przekonać ludzi! :)

Większość ludzi po prostu ustalić to z doświadczenia, po raz pierwszy starają się oprogramowanie działa w miejscu innym niż własnej stacji roboczej rozwoju.

Answer 3

ile nie jest to bezwzględnie SOLID, inna zasada OOD jest The Common Closure Principle, w którym stwierdza się, że klasy, które zmieniają się wraz są pakowane razem. Chociaż nie jest to dokładnie klasa, możesz rozciągnąć ten pomysł na informacje o konfiguracji. Ponieważ np. numery portów zmieniają się na podstawie innych kryteriów niż otaczający kod, wydaje się to naruszać.

Answer 4

Zasada pojedynczej odpowiedzialności (S w SOLID) określa, że ​​klasa powinna mieć tylko jeden powód do zmiany. This article podaje przykład interfejsu modemu i omawia, w jaki sposób szczegóły połączenia i zawieszenia są oddzielną odpowiedzialnością za komunikację danych i prawdopodobnie ulegną zmianie z różnych powodów. Możesz użyć tego, by zrobić podobny przypadek, dlaczego numery portów są dodatkowym "powodem zmiany", niezależnie od głównej odpowiedzialności klasy.