Pracuje z niechlujami

LukeJL napisał(a):

masz klocek lego A. Wczepiasz go w klocek B.
Złamanie zasady OC przez modyfikację klocka (np. podmiana tych kubików na górze - z okrągłych na kwadratowe) [...]

Klocek jest tworem materialnym, program - niematerialnym. Mają inne właściwości. O ile porównywanie do przedmiotów materialnych być może ma jakąś wartość w rozmowach z nie-programistami (piszę - być może - bo wcale nie jestem co do tego przekonany), o tyle w rozmowach z programistami jest bez sensu.

Jeden przykład co mi teraz przychodzi do głowy, w jaki sposób OCP będzie powodował gorszy kod, to bardzo typowe w świecie programowania zjawisko zmieniających się w czasie wymagań odnośnie programu. Mamy jakieś początkowe szczególne wymaganie, później dochodzą wymagania podobne, ale nieco inne, aż w końcu oczekiwania ewoluują na tyle, że pierwotne wymaganie jest już zupełnie nieaktualne. Jeśli stosowało się OCP, to wyrzucenie z kodu obsługi pierwotnego wymagania, pozostawiając jednocześnie obsługę wymagań podobnych, ale przedstawionych później, wymaga dużej przeróbki. Tę legendarną i krytykowaną drabinkę if-ów wystarczy wtedy lekko edytować, dzięki czemu łatwiej zachować jej czystość.

Pijany Krawiec napisał(a):

Widzę, że krecimy sie w kółko. Ja pisałem o nieistotności celów OCP, a ty stawiasz chochoła, że OCP ~= wzorce projektowe z OO, których podobno nie stosuję. To jest jeden z większych zarzutów wobec SOLID, że jest tyle interpretacji, ilu programistów.

Ja wyjaśniałem na czym polega i jakie narzędzia są uzywane do osiągnięcia OCP na poziomie kodu.

Troll anty OOP napisał(a):

Jeśli stosowało się OCP, to wyrzucenie z kodu obsługi pierwotnego wymagania, pozostawiając jednocześnie obsługę wymagań podobnych, ale przedstawionych później, wymaga dużej przeróbki.

Nie wymaga żadnej przeróbki, po prostu pewien fragment kodu nie jest już dłużej używany.