Mevcut cevapların her ikisi de sadece kısmen işarete çarpıyor gibi görünüyor ve temel fikri bulanıklaştıran örneklere odaklanıyorlar. Bu aynı zamanda (yalnızca) bir OOP ilkesi değil, genel olarak bir yazılım tasarım ilkesidir.
Bu cümle içinde "değişken" olan şey koddur. Christophe bir şey genellikle olduğunu söyleyerek noktada olduğunu olabilir sık sık olduğu değişir tahmin bu. Amaç, koddaki gelecekteki değişikliklerden kendinizi korumaktır. Bu, bir arayüze karşı programlama ile yakından ilgilidir . Ancak, Christophe bunu "uygulama detayları" ile sınırlandırmak konusunda yanlış. Aslında, bu tavsiyenin değeri genellikle gereksinimlerdeki değişikliklerden kaynaklanmaktadır .
Bu sadece dolaylı olarak kapsülleyici devletle ilgilidir, ki David Arno'nun düşündüğü şey bu. Bu tavsiye her zaman (ancak genellikle) kapsülleme durumunu önermez ve bu tavsiye de değişmez nesneler için de geçerlidir. Aslında, sadece sabitleri isimlendirmek, değişeni enkapsüle etmenin (çok temel) bir şeklidir.
CandiedOrange, "neyin değiştiğini" "ayrıntılarıyla" açıkça birleştirir. Bu sadece kısmen doğrudur. Değişen herhangi bir kodun bir anlamda "detaylar" olduğunu kabul ediyorum, fakat "detay" değişmeyebilir (bu tautolojik yapmak için "detaylar" tanımlanmadıkça). Değişmeyen detayların kapsüllenmesi için sebepler olabilir, ancak bu karar bir değildir. Kabaca söylemek gerekirse, "köpek", "kedi" ve "ördek" ile uğraşmanız gereken tek tip olacağından çok eminseniz, bu belirti CandiedOrange'in yeniden yapılanmasını önermez.
CandiedOrange'in örneğini farklı bir bağlamda yayınlamak, C gibi bir prosedür diline sahip olduğumuzu varsayalım:
if (pet.type() == dog) {
pet.bark();
} else if (pet.type() == cat) {
pet.meow();
} else if (pet.type() == duck) {
pet.quack()
}
Bu kod parçasının gelecekte değişeceğini makul bir şekilde bekleyebilirim. Yeni bir prosedür tanımlayarak onu "kapsülleyebilirim":
void speak(pet) {
if (pet.type() == dog) {
pet.bark();
} else if (pet.type() == cat) {
pet.meow();
} else if (pet.type() == duck) {
pet.quack()
}
}
ve kod bloğu yerine bu yeni prosedürün kullanılması (yani bir "özütleme yöntemi" yeniden düzenleme). Bu noktada bir "inek" tipi veya sadece speakprosedürün güncellenmesini gerektiren herhangi bir şey eklemek . Tabii ki, bir OO dilinde bunun yerine CandiedOrange'in cevabının gerektirdiği şekilde dinamik gönderimden yararlanabilirsiniz. petBir arayüz üzerinden erişirseniz , bu doğal olarak gerçekleşecektir . Koşullu mantığın dinamik gönderim yoluyla ortadan kaldırılması, bu prosedürsel yorumlamayı neden yaptığımın bir parçası olan ortogonal bir kaygıdır. Ayrıca bunun OOP'a özgü özellikler gerektirmediğini vurgulamak istiyorum. Bir OO dilinde bile, neyin değişebileceğini kapsama almak mutlaka yeni bir sınıf veya arayüzün oluşturulması gerektiği anlamına gelmez.
Daha iyi bir örnek olarak (OO'ya daha yakın fakat tamamen OO değil), kopyaları bir listeden silmek istediğimizi söylüyoruz. Diyelim ki, başka bir listede gördüğüm öğeleri takip ederek ve gördüğümüz tüm öğeleri kaldırarak listeyi değiştirerek uygularız. En azından performans nedenleriyle, görülen öğeleri takip etme biçimimizi değiştirmek istediğimizi değiştirmek isteyebileceğimizi varsaymak mantıklıdır. Neyin değişebileceğini kapsülleme diktumu, görülen öğeler kümesini temsil etmek için soyut bir veri türü oluşturmamız gerektiğini öne sürmektedir. Algoritmamız şimdi bu soyut Set veri türüne göre tanımlanmıştır ve bir ikili arama ağacına geçmeye karar verirsek, algoritmamızın değişmesi veya bakımı gerekmez. Bir OO dilinde, bu soyut veri tipini yakalamak için bir sınıf veya arayüz kullanabiliriz. SML / O 'gibi bir dilde
Gereksinim odaklı bir örnek için, bazı iş mantıklarıyla ilgili bazı alanları doğrulamanız gerektiğini söyleyin. Şu anda özel gereksinimleriniz olsa da, onların değişeceğinden şüphelisiniz. Mevcut mantığı kendi yordamını / işlevini / kuralını / sınıfını içine alabilirsiniz.
Bu, "değişken olanı kapsüllemek" in bir parçası olmayan ortogonal bir kaygı olmasına rağmen, şimdi kapsüllenmiş mantığı ile parametreleştiren soyutlamak doğaldır. Bu tipik olarak daha esnek bir koda yol açar ve kapsüllenmiş mantığı değiştirmek yerine alternatif bir uygulamada yer değiştirerek mantığın değiştirilmesine izin verir.