Açıkladığım gibi, açık / kapalı prensip bir kez yazılı kodun değiştirilmemesi gerektiğini (hata düzeltmeleri dışında) belirtir. Ancak işletme kurallarım değişirse, bu değişiklikleri uygulayan kodu değiştirmemeli miyim? Bana prensip olarak bir şey anlamadığımdan şüpheleniyorum çünkü bu bana mantıklı gelmiyor.
Yanıtlar:
Bu muhtemelen açıklanması en katı prensiplerden biridir. İzin ver deneyeyim. Mükemmel çalışan ve hiçbir hata bulunmayan bir Fatura sınıfı yazdığınızı hayal edin. Bir faturanın PDF'sini yapar.
Sonra birisi, içinde bağlantı bulunan bir HTML faturası istediklerini söylüyor. Bu isteği yerine getirmek için Faturada hiçbir kodu değiştiremezsiniz. Bunun yerine, şimdi istediklerini yapan başka bir sınıf HTMLInvoice yaparsınız. Mirastan yararlanırsınız, böylece HTMLInvoice'da pek çok yinelenen kod yazmak zorunda kalmazsınız.
Eski Faturayı kullanan eski kod bozuk veya hiçbir şekilde etkilenmiyor. Yeni kod HTMLInvoice'i kullanabilir. (Ayrıca , katı L sınıfı olan Liskov Yerine koyma özelliğini de yaparsanız , HTMLInvoice örneklerini, Fatura örneklerini bekleyen mevcut koda verebilirsiniz.) Herkes sonsuza dek mutlu bir şekilde yaşıyor.
Fatura değişikliğe kapalı, uzatma için açık. Ve bunun işe yaraması için Faturayı önceden düzgün bir şekilde yazmak zorundasınız,
Okuduğunuz Open-Kapalı Prensibi ObjectMentor de Bob Amcanın arkadaşı tarafından makalesine? Bence orada daha iyi açıklamalardan biri.
Nesneye yönelik tasarımla ilgili birçok sezgisel tarama vardır. Örneğin, “tüm üye değişkenleri özel olmalı” veya “global değişkenlerden kaçınılmalıdır” veya “çalışma zamanı tür tanımlamasını kullanmak (RTTI) tehlikelidir”. Bu sezgisel taramaların kaynağı nedir? Onları gerçek kılan ne? Onlar mı hep doğrudur? Bu sütun, bu sezgisel araştırmanın altında yatan tasarım ilkesini - açık-kapalı prensibi - inceler.
Ivar Jacobson'ın dediği gibi: “Tüm sistemler yaşam döngüleri boyunca değişir. İlk versiyondan daha uzun sürmesi beklenen sistemler geliştirilirken bu akılda tutulmalıdır. ”Değişim karşısında kararlı olan ve ilk versiyondan daha uzun sürecek tasarımları nasıl oluşturabiliriz? Bertrand Meyer, 1988'de, şimdiye kadar ünlü açık-kapalı prensibini icat ettiği zaman bize rehberlik etti. Onu felç etmek için:
YAZILIM GİRİŞLERİ (SINIFLAR, MODÜLLER, FONKSİYONLAR, VB.) UZATMA AÇILMALI, DEĞİŞTİRME İÇİN KAPALI OLMALIDIR.
Bir programda yapılan tek bir değişiklik, bağımlı modüllerde bir değişiklik basamağıyla sonuçlandığında, bu program “kötü” tasarımla ilişkilendirdiğimiz istenmeyen nitelikleri gösterir. Program kırılgan, katı, öngörülemez ve tekrar kullanılamaz hale geliyor. Açık-kapalı ilke, buna çok basit bir şekilde saldırır. Asla değişmeyen modüller tasarlamanız gerektiğini söylüyor . Gereksinimler değiştiğinde, zaten çalışan eski kodu değiştirerek değil, yeni kod ekleyerek bu tür modüllerin davranışını genişletirsiniz.
Açıklama
Açık-kapalı prensibe uygun olan modüller iki temel özelliğe sahiptir.
- Onlar “Uzantıya Açık” tır.
Bu, modülün davranışının uzatılabileceği anlamına gelir. Modülün, uygulamanın gereksinimleri değiştikçe yeni ve farklı şekillerde davranmasını sağlayabilir veya yeni uygulamaların gereksinimlerini karşılayabiliriz.- Onlar “Değişikliğe Kapalı”.
Böyle bir modülün kaynak kodu inviolate. Hiç kimse kaynak kodu üzerinde değişiklik yapamaz.Bu iki özelliğin birbiriyle çelişkili olduğu görülüyor. Bir modülün davranışını genişletmenin normal yolu, o modülde değişiklik yapmaktır. Değiştirilemeyen bir modülün normal olarak sabit bir davranışı olduğu düşünülmektedir. Bu iki karşıt nitelik nasıl çözülebilir?
Soyutlama Anahtardır ...
Kate Gregory tarafından cevap çok iyidir, ama yeni bir gereklilik mevcut nispeten küçük değişiklikle tatmin edilebilir farklı bir durum düşünün Invoicesınıfta. Örneğin, Fatura PDF'sine yeni bir alanın eklenmesi gerektiğini varsayalım. OCP'ye göre, yeni alan mevcut uygulamada birkaç kod satırı değiştirilerek eklenebilse bile yeni bir alt sınıf oluşturmalıyız.
Anladığım kadarıyla OCP, projelerin çoğu zaman sürüm kontrolünü kullanmadığı, 90'ların ve 90'ların başındaki gerçeğini yansıtıyor, daha az otomatik regresyon testleri veya karmaşık yeniden düzenleme araçlarının yararı vardı. OCP, manuel olarak test edilip üretime sokulan kod kırma riskinden kaçınmaya çalıştı. Bugün, çalışan yazılımların kırılma riskini yönetmek için daha iyi yollarımız var (yani sürüm kontrol sistemleri, TDD ve otomatik test ve yeniden düzenleme araçları).
Şahsen ben bu ilkenin bir tutam tuzla alınması gerektiğini düşünüyorum. Kod organiktir, işletmeler zaman geçtikçe değişir ve bir işletmenin ihtiyaçlarına göre kod değişir.
Soyutlamanın anahtar olduğu konusunda kafamı karıştırmak çok zor. Ya soyutlama başlangıçta yanlıştıysa? İşletme işlevi önemli ölçüde değiştiyse ne olur?
Bu prensip esasen, bir tasarımın ORİJİNAL niyetlerinin ve davranışlarının asla değişmemesini sağlar. Bu muhtemelen herkese açık API'leri olanlar ve müşterileri için yeni sürümlere ve diğer bazı yeni durumlara ayak uydurmakta zorlanıyor. Ancak, bir şirketin TÜM koduna sahip olması durumunda, bu ilkeye itiraz ediyorum.
Kodunuzun iyi test kapsamına sahip olması, kod tabanınızı yeniden düzenlemeyi bir esinti yapmalıdır. İşlerin yanlış gitmesi tamam demektir - testleriniz daha iyi bir tasarım için size rehberlik edecektir.
Söylemek gerekirse, herhangi bir test yoksa, o zaman bu ilke sağlamdır.