Jakie jest znaczenie i rozumowanie zasady otwartej / zamkniętej?

Oznacza to, że należy umieścić nowy kod w nowych klasach/modułach. Istniejący kod powinien być modyfikowany tylko w celu naprawy błędów. Nowe klasy mogą ponownie użyć istniejącego kodu poprzez dziedziczenie.

Zasada Open/closed ma na celu ograniczenie ryzyka przy wprowadzaniu nowych funkcjonalności. Ponieważ nie modyfikujesz istniejącego kodu, możesz mieć pewność, że nie zostanie on złamany. Obniża koszty konserwacji i zwiększa stabilność produktu.

Jest to odpowiedź na delikatny problem klas bazowych, który mówi, że pozornie niewinne modyfikacje klas bazowych mogą mieć niezamierzone konsekwencje dla dziedziców, które zależą od poprzedniego zachowania. Musisz więc uważać, aby enkapsować to, czego nie chcesz, aby klasy pochodne były zgodne z umowami zdefiniowanymi przez klasę bazową. A gdy Dziedzice istnieją, musisz być Naprawdę ostrożny z tym, co zmieniasz w klasie bazowej.

Dokładniej niż DaveK, zwykle oznacza to, że jeśli chcesz dodać dodatkową funkcjonalność lub zmienić funkcjonalność klasy, Utwórz podklasę zamiast zmieniać oryginał. W ten sposób każdy, kto korzysta z klasy rodzica, nie musi się martwić, że zmieni się ona później. Zasadniczo chodzi o kompatybilność wsteczną.

Inną naprawdę ważną zasadą projektowania obiektowego jest luźne sprzężenie poprzez interfejs metodyczny. Jeśli zmiana, którą chcesz wprowadzić, Nie wpływ na istniejący interfejs, to naprawdę jest dość bezpieczne, aby zmienić. Na przykład, aby algorytm był bardziej wydajny. Zasady zorientowane obiektowo też trzeba hartować zdrowym rozsądkiem:)

Jednostki oprogramowania powinny być otwarte dla rozszerzenia, ale zamknięte dla modyfikacji

Oznacza to, że każda klasa lub moduł powinny być napisane w sposób, który może być używany tak, jak jest, może być rozszerzony, ale neve zmodyfikowane

Zły przykład w Javascript

var juiceTypes = ['Mango','Apple','Lemon'];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}

exports.makeJuice = juiceMaker;

Teraz, jeśli chcesz dodać inny typ soku, musisz edytować sam moduł, w ten sposób łamiemy OCP .

Dobry przykład w Javascript

var juiceTypes = [];
function juiceMaker(type){
    if(juiceTypes.indexOf(type)!=-1)
        console.log('Here is your juice, Have a nice day');
    else
        console.log('sorry, Error happned');
}
function addType(typeName){
    if(juiceTypes.indexOf(typeName)==-1)
        juiceTypes.push(typeName);
}
function removeType(typeName){
  let index = juiceTypes.indexOf(typeName)
    if(index!==-1)
        juiceTypes.splice(index,1);
}

exports.makeJuice = juiceMaker;
exports.addType = addType;
exports.removeType = removeType;

Zasada ta oznacza, że dodawanie nowej funkcjonalności powinno być łatwe bez konieczności zmiany istniejącej, stabilnej i przetestowanej funkcjonalności, oszczędzając zarówno czas, jak i pieniądze.

Często polimorfizm, na przykład przy użyciu interfejsów, jest dobrym narzędziem do osiągnięcia tego celu.

Dodatkową zasadą zgodności z OCP jest uczynienie klas bazowych abstrakcyjnymi w odniesieniu do funkcjonalności dostarczanych przez klasy pochodne. Albo, jak mówi Scott Meyers, "uczyń klasy bez liści abstrakcyjne".

Oznacza to, że Nie zaimplementowano metod w klasie bazowej i zaimplementowano te metody tylko w klasach, które same w sobie nie mają podklas. Wtedy klient klasy bazowej nie może polegać na konkretnej implementacji w klasie bazowej, ponieważ jej nie ma.

Chcę tylko podkreślić ,że" Open/Closed", mimo że jest oczywiście użyteczny w programowaniu OO, jest zdrową metodą do wykorzystania we wszystkich aspektach programowania. Na przykład, z mojego własnego doświadczenia jest to świetny środek przeciwbólowy, aby używać "Open/Closed" jak najwięcej podczas pracy z zwykłym C.

/Robert

Oznacza to, że oprogramowanie OO powinno być budowane, ale nie zmieniane wewnętrznie. Jest to dobre, ponieważ zapewnia niezawodną, przewidywalną wydajność z klas bazowych.

Otrzymałem ostatnio dodatkowe wyobrażenie o tym, co ta zasada pociąga za sobą: że zasada otwarta-zamknięta opisuje jednocześnie sposób pisania kodu, a także efekt końcowy pisania kodu w odporny sposób.

Lubię myśleć o otwartym / zamkniętym podziale na dwie ściśle powiązane części:

• kod, który jest otwarty do zmiany, może albo zmienić swoje zachowanie, aby poprawnie obsłużyć jego dane wejściowe, albo wymaga minimalnej modyfikacji, aby zapewnić nowe scenariusze użycia.
• Kod to jest zamknięte Dla Modyfikacji nie wymaga wiele, jeśli jakakolwiek interwencja człowieka do obsługi nowych scenariuszy użytkowania. Potrzeba po prostu nie istnieje.

Tak więc kod, który wykazuje zachowanie Otwarte / Zamknięte (lub, jeśli wolisz, spełnia zasadę Open/Closed), wymaga minimalnej lub żadnej modyfikacji w odpowiedzi na scenariusze użycia wykraczające poza to, do czego został pierwotnie zbudowany.

Jeśli chodzi o wdrożenie? Stwierdzam, że powszechnie stwierdzona interpretacja: "Otwarte / Zamknięte odnosi się do kodu będącego polimorficznym!"być w najlepszym razie niekompletnym stwierdzeniem. Polimorfizm w kodzie jest jednym z narzędzi do osiągnięcia tego rodzaju zachowania; dziedziczenie, implementacja...tak naprawdę każda obiektowo zorientowana zasada projektowania jest niezbędna do napisania kodu, który jest odporny w sposób sugerowany przez tę zasadę.

W zasadzie konstrukcyjnej, SOLID – " O "W " SOLID" oznacza zasadę otwartą / zamkniętą.

Open Closed principle to zasada projektowania, która mówi, że Klasa, moduły i funkcje powinny być otwarte dla rozszerzenia, ale zamknięte dla modyfikacji.

Zasada ta mówi, że projektowanie i pisanie kodu powinno odbywać się w taki sposób, aby dodawać nowe funkcje przy minimalnych zmianach w istniejącym kodzie (testowanym kodzie). Projekt powinien być wykonany w sposób umożliwiający dodawanie nowych funkcjonalności jako nowych klas, zachowując jak najwięcej istniejącego kodu bez zmian.

Korzyści z zasady projektowania otwartego zamkniętego:

1. aplikacja będzie bardziej wytrzymała, ponieważ nie zmieniamy już przetestowanej klasy.
2. elastyczny, ponieważ możemy łatwo dostosować się do nowych wymagań.
3. łatwe do przetestowania i mniej podatne na błędy.

Mój wpis na blogu na to:

Http://javaexplorer03.blogspot.in/2016/12/open-closed-design-principle.html