Uygulamada açık-kapalı ilkesine nasıl uyulur

Açık-kapalı prensibinin amacını anlıyorum. Değiştirmeden genişletmeyi denemenizi söyleyerek, değiştirirken zaten çalışan bir şeyi kırma riskini azaltmak içindir.

Ancak, bu prensibin uygulamada nasıl uygulandığını anlamakta zorlandım. Anladığım kadarıyla bunu uygulamanın iki yolu var. Olası bir değişiklikten önce ve sonra:

1. Önce: soyutlamalara programlayın ve 'geleceği tahmin edin' olabildiğince. Örneğin , gelecekte sisteme s eklenecekse bir yöntemin drive(Car car)değiştirilmesi Motorcyclegerekecektir, bu nedenle muhtemelen OCP'yi ihlal eder. Ancak yöntemin drive(MotorVehicle vehicle)gelecekte değişmesi daha az olasıdır, bu nedenle OCP'ye uyar.

   Ancak, geleceği tahmin etmek ve sistemde hangi değişikliklerin yapılacağını önceden bilmek oldukça zordur.

2. Sonra: bir değişiklik gerektiğinde, geçerli kodunu değiştirmek yerine bir sınıfı genişletin.

1 numaralı uygulamayı anlamak zor değil. Ancak nasıl uygulanacağını anlamada sorun yaşıyorum.

Örneğin (YouTube'da bir videodan aldı): en biz kabul eden bir sınıfta bir yöntemi var diyelim CreditCardnesneleri: makePayment(CraditCard card). VoucherSisteme bir gün s eklenir. Bu yöntem onları desteklemediğinden değiştirilmelidir.

Yöntemi ilk etapta uygularken geleceği ve programı daha soyut terimlerle tahmin edemedik (örneğin makePayment(Payment pay), şimdi mevcut kodu değiştirmemiz gerekiyor).

Uygulama # 2, işlevselliği değiştirmek yerine genişleterek eklememiz gerektiğini söylüyor. Bu ne anlama geliyor? Sadece varolan kodunu değiştirmek yerine varolan sınıfı alt sınıflara mı ayırmalıyım? Kodu yeniden yazmaktan kaçınmak için etrafına bir tür sarıcı yapmalı mıyım?

Ya da prensip 'işlevselliği doğru bir şekilde nasıl değiştirir / ekler' anlamına gelmez, daha ziyade 'ilk etapta değişiklik yapmaktan (yani soyutlamalara program yapmaktan) kaçınmak anlamına gelir mi?

Tasarım ilkeleri her zaman birbiriyle dengelenmelidir. Geleceği tahmin edemezsiniz ve çoğu programcı bunu denediğinde korkunç bir şekilde yapar. Bu nedenle , öncelikle çoğaltma ile ilgili olan, ancak diğer tasarım ilkeleri için de yeniden düzenleme için geçerli olan üç kuralı var .

Bir arayüzün yalnızca bir uygulamasına sahip olduğunuzda, herhangi bir uzantının nerede olacağı çok net olmadığı sürece OCP'yi fazla önemsemeniz gerekmez. Aslında, bu durumda aşırı tasarım yapmaya çalışırken genellikle netliği kaybedersiniz . Eğer bir kez uzatmak yaptığımızda, bunu dost OCP yapmak refactor eğer bunu yapmak için en kolay ve en net yoludur. Üçüncü bir uygulamaya genişlettiğinizde, biraz daha fazla çaba gerektirse bile OCP'yi dikkate alarak onu yeniden düzenlediğinizden emin olun.

Pratikte, yalnızca iki uygulamanız olduğunda, üçte birini eklediğinizde yeniden düzenleme yapmak genellikle çok zor değildir. O zamandan sonra büyümesine izin verdiğinizde, bakımı zahmetli hale gelir.

Bence geleceğe çok fazla bakıyorsun. Mevcut problemi açık / kapalı yapabilecek esnek bir şekilde çözün.

Diyelim ki bir drive(Car car)yöntem uygulamanız gerekiyor . Dilinize bağlı olarak birkaç seçeneğiniz vardır.

• Aşırı yüklemeyi (C ++) destekleyen diller için, drive(const Car& car)

  Bir noktada daha sonra ihtiyacınız olabilir drive(const Motorcycle& motorcycle), ancak buna müdahale etmez drive(const Car& car). Sorun değil!

• Aşırı yüklemeyi desteklemeyen diller için (Hedef C), yönteme tür adını ekleyin -driveCar:(Car *)car.

  Bir noktada daha sonra ihtiyacınız olabilir -driveMotorcycle:(Motorcycle *)motorcycle, ama yine de, müdahale etmez.

Bu, drive(Car car)modifikasyona kapatılmasına izin verir , ancak diğer araç tiplerine uzanmaya açıktır. Bugün iş yapmanıza izin veren ancak gelecekte kendinizi engellemenizi önleyen bu minimalist gelecek planlaması.

İhtiyacınız olan en temel türleri hayal etmeye çalışmak sonsuz gerilemeye yol açabilir. Segue, bisiklet veya Jumbo jet kullanmak istediğinizde ne olur? İnsanların içine girdiği ve hareketlilik için kullandığı tüm cihazları açıklayabilecek tek bir genel soyut türü nasıl oluşturuyorsunuz?

Açık-kapalı prensibinin amacını anlıyorum. Değiştirmeden genişletmeyi denemenizi söyleyerek, değiştirirken zaten çalışan bir şeyi kırma riskini azaltmak içindir.

Aynı zamanda, zaten var olan nesnelerin davranışını değiştirmeyerek bu yönteme güvenen tüm nesneleri kırmamakla da ilgilidir. Bir nesne davranış değiştirmenin reklamını yaptıktan sonra, diğer nesnelerin tam olarak ne beklediğini bilmeden, nesnenin bilinen ve beklenen davranışını değiştirdiğiniz için risklidir.

Bu ne anlama geliyor? Sadece varolan kodunu değiştirmek yerine varolan sınıfı alt sınıflara mı ayırmam gerekir?

Evet.

"Yalnızca kredi kartlarını kabul eder", genel arayüzü aracılığıyla söz konusu sınıfın davranışının bir parçası olarak tanımlanır. Programcı dünyaya bu nesnenin yönteminin sadece kredi kartı aldığını beyan etti. Bunu çok açık olmayan bir yöntem adı kullanarak yaptı, ama bitti. Sistemin geri kalanı buna güveniyor.

Bu o zaman mantıklı olabilirdi, ama şimdi değişmesi gerekiyorsa, kredi kartları dışında bir şeyleri kabul eden yeni bir sınıf yapmalısınız.

Yeni davranış = yeni sınıf

Bir yana - Geleceği tahmin etmenin iyi bir yolu, bir yöntem verdiğiniz adı düşünmektir. Tam olarak hangi ödemeyi yapabileceği konusunda yöntemde belirli kurallara sahip bir yönteme makePayment gibi gerçekten genel bir sondaj yöntemi adı verdiniz mi? Bu bir kod kokusu. Belirli kurallarınız varsa, bunlar yöntem adından açıkça belirtilmelidir - makePayment makeCreditCardPayment olmalıdır. Nesneyi ilk kez yazarken bunu yapın ve diğer programcılar bunun için size teşekkür edecektir.