OOP'deki dokümanlar bir “alıcı” nın herhangi bir hesaplama yapıp yapmadığını belirlemekten kaçınmalıdır?

Okulumun CS programı, nesne yönelimli programlamanın herhangi bir sözünden kaçınır, bu yüzden ek olarak kendi başıma okudum - özellikle de Bertrand Meyer tarafından Nesneye Yönelik Yazılım Yapımı .

Meyer, sınıfların uygulamaları hakkında mümkün olduğunca fazla bilgi saklaması gerektiği ve bu da mantıklı olduğu anlamına geliyor. Özellikle, tekrar tekrar özniteliklerin (yani sınıfların statik, hesaplanmayan özellikleri) ve yordamlarının (işlev / prosedür çağrılarına karşılık gelen sınıfların özellikleri) birbirinden ayırt edilemez olması gerektiğini savunur.

Bir sınıf Örneğin, Personniteliği vardır age, o olsun, gösterimden, söylemek mümkün olması gerektiğini iddia Person.agetekabül içten gibi bir şey return current_year - self.birth_dateya da sadece return self.age, self.agesabit bir özellik olarak tanımlanmıştır. Bu bana mantıklı geliyor. Ancak, aşağıdakileri talep etmeye devam ediyor:

Sınıfın kısa formu olarak bilinen bir sınıf için standart müşteri dokümantasyonu, verilen bir özelliğin bir özellik mi yoksa bir fonksiyon mu olduğunu ortaya çıkarmayacak şekilde tasarlanacaktır.

yani, sınıf için olan belgelerin bile bir “alıcı” nın herhangi bir hesaplama yapıp yapmadığını belirtmekten kaçınması gerektiğini iddia eder .

Bunu takip etmiyorum. Dokümantasyon, kullanıcıları bu ayrım konusunda bilgilendirmenin önemli olacağı bir yer değil mi? PersonNesnelerle dolu bir veritabanı tasarlayacak olsaydım, Person.agepahalı bir arama olup olmadığını bilmek önemli olmaz mıydı , o yüzden bunun için bir önbellek kullanıp kullanmayacağına karar verebilirdim? Ne dediğini yanlış mı anladım, yoksa OOP tasarım felsefesinin özellikle aşırı bir örneği mi?

Meyer'in meselesi, pahalı bir operasyonunuz olduğunda kullanıcıya söylememeniz gerektiği anlamına gelmiyor. Eğer fonksiyonunuz veritabanına çarpacaksa veya bir web sunucusuna bir istek yapacaksa ve birkaç saat hesaplamak için harcayacaksanız, diğer kodun bunu bilmesi gerekecektir.

Ancak sınıfınızı kullanan kodlayıcının uygulayıp uygulamadığınızı bilmesi gerekmez:

return currentAge;

veya:

return getCurrentYear() - yearBorn;

Bu iki yaklaşım arasındaki performans özellikleri o kadar azdır ki önemli olmamalıdır. Sınıfınızı kullanan kodlayıcı gerçekten hangisine sahip olduğunuzu önemsememelidir. Bu meyer'in amacı.

Ancak bu her zaman böyle değildir, örneğin, bir kapta bir boyut yönteminizin olduğunu varsayalım. Uygulanabilir:

return size;

veya

return end_pointer - start_pointer;

ya da olabilir:

count = 0
for(Node * node = firstNode; node; node = node->next)
{
    count++
}
return count

İlk ikisi arasındaki fark gerçekten önemli olmamalı. Ancak sonuncunun ciddi performans sonuçları olabilir. STL, örneğin, diyor nedeni budur .size()olduğunu O(1). Boyutun tam olarak nasıl hesaplandığı belgelenmiyor, ancak bana performans özelliklerini veriyor.

Yani : performans sorunlarını belgelemek. Uygulama detaylarını belgelendirmeyin. Std :: sort'in işleri düzgün bir şekilde ve verimli bir şekilde yaptığı sürece nasıl sıraladığı umurumda değil. Sınıfınız ayrıca bir şeyi nasıl hesapladığını da belgelememelidir, ancak eğer bir şey beklenmeyen bir performans profiline sahipse, bunu belgeleyin.

Bir akademisyen ya da CS uzmanı görüşüne göre, elbette bir özelliğin uygulanmasının içindekilerine ilişkin herhangi bir şeyi belgelerde açıklamak bir başarısızlıktır. Çünkü sınıfın kullanıcısı, sınıfın iç uygulaması hakkında herhangi bir varsayımda bulunmamalıdır. Uygulama değişirse, ideal olarak hiçbir kullanıcı bunu farketmez - özellik bir soyutlama yaratır ve iç kısımlar tamamen gizli tutulmalıdır.

Ancak, çoğu gerçek dünya programları Joel Spolsky`s muzdarip "sızıntılı soyutlamalar Kanunu" diyor ki,

“Tüm önemsiz soyutlamalar, bir dereceye kadar sızdırıyor.”

Bu, karmaşık özelliklerin tam bir kara kutu soyutlamasını oluşturmak neredeyse imkansız demektir. Ve bunun tipik bir belirtisi performans sorunlarıdır. Bu nedenle, gerçek dünya programları için, hangi çağrıların pahalı ve hangilerinin pahalı olmadığı çok önemli olabilir ve iyi bir dokümantasyon bu bilgileri içermelidir (veya bir sınıf kullanıcısının performans hakkında varsayımlar yapmasına izin verilen ve nerede olmadığı konusunda ).

Bu yüzden benim tavsiyem: gerçek dünyadaki bir program için dokümanlar yazarsanız potansiyel pahalı çağrılar hakkındaki bilgileri dahil edin ve herhangi bir performans konusunun dikkate alınması gerektiğine bağlı olarak, yalnızca CS kursunuzun eğitim amaçlı yazdığınız bir program için hariç tutun kasten kapsam dışı.

Belirli bir aramanın pahalı olup olmadığını yazabilirsiniz. Daha iyisi, getAgehızlı erişim ve loadAgeveya fetchAgepahalı arama gibi bir adlandırma kuralı kullanın . Yöntem herhangi bir GÇ gerçekleştiriyorsa, kullanıcıyı kesinlikle bilgilendirmek istersiniz.

Belgelerde verdiğiniz her ayrıntı, sınıf tarafından onurlandırılması gereken bir sözleşme gibidir. Önemli davranışlar hakkında bilgi vermelidir. Genellikle, büyük O gösterimi ile karmaşıklık göstergesi göreceksiniz. Fakat genellikle kısa ve öz olmak istersiniz.

Person nesneleriyle dolu bir veritabanı tasarlayacak olsam, Person.age'in pahalı bir çağrı olup olmadığını bilmek önemli olmaz mıydı?

Evet.

Bu yüzden bazen Find()onu aramanın bir süre alabileceğini belirtmek için işlevler kullanıyorum . Bu her şeyden çok bir kongredir. Orada programcılar arasında rağmen getiri bir işlev veya özellik için gerekli süre, programa hiçbir fark (kullanıcıya olabilir gerçi) yapar olduğu bir özellik olarak ilan edilirse, maliyet olmalıdır adlandırmak, bu bir beklenti düşük.

Her durumda, kodun kendisinde bir şeyin bir işlev mi yoksa öznitelik mi olduğunu saptamak için yeterli bilgi bulunmalıdır, bu nedenle belgelerde bunu söyleme gereğini görmüyorum.

Bu kitabın ilk basımının 1988'de, OOP'un ilk günlerinde yazıldığı unutulmamalıdır. Bu insanlar, günümüzde yaygın olarak kullanılan daha saf nesneye yönelik dillerle çalışıyorlardı. Bugün en popüler OO dillerimiz - C ++, C # & Java - dillerin erken, daha saf OO dillerinin çalışmasından oldukça önemli farklar var.

C ++ ve Java gibi bir dilde, bir özniteliğe erişme ile bir yöntem çağrısı arasında ayrım yapmanız gerekir. Arasındaki fark bir dünya var instance.getter_methodve instance.getter_method(). Biri aslında senin değerini alır, diğeri almaz.

Smalltalk veya Ruby iknalarının daha saf bir OO diliyle çalışırken (bu kitapta kullanılan Eyfel dili olduğu anlaşılıyor) mükemmel bir şekilde tavsiye edilir. Bu diller dolaylı olarak sizin için yöntemleri arayacaktır. Arasında fark yoktur hale gelir instance.attributeve instance.getter_method.

Bu noktayı terletmem ya da dogmatik olarak düşünmem. Amaç iyi - sınıfınızın kullanıcılarının ilgisiz uygulama detayları hakkında endişelenmesini istemiyorsunuz - ama pek çok modern dilin sözdizimine açıkça çevrilmiyor.

Bir kullanıcı olarak, bir şeyin nasıl uygulandığını bilmenize gerek yoktur.

Performans bir sorunsa, sınıf uygulamasının içinde bir şey yapılmalı, onun etrafında değil. Bu nedenle, doğru eylem, sınıf uygulamasını düzeltmek ya da bir hata sahibine dosyalamaktır.

Programcıları rutinlerin / yöntemlerin karmaşıklığı konusunda bilgilendiremeyen programcıya yönelik herhangi bir belge parçası kusurludur.

• Yan etki göstermeyen yöntemler üretmek istiyoruz.

• Bir yöntemin yürütülmesi, çalışma zamanı karmaşıklığına ve / veya hafıza karmaşıklığına sahip değilse O(1), hafıza veya zaman kısıtlı ortamlarda, yan etkilerin olduğu kabul edilebilir .

• En az sürpriz prensibi bu durumda, hafızayı hogging veya CPU vakit - Bir yöntem tamamen beklenmedik bir şey yaparsa ihlal edilmektedir.

Bence onu doğru anlamışsın ama aynı zamanda iyi bir noktaya sahip olduğunu düşünüyorum. eğer Person.agepahalı bir hesaplama ile uygulanan, o zaman ben de belgelerinde görmek istiyorum düşünüyorum. Tekrar tekrar çağırmak (ucuz bir işlemse) veya bir kez çağırmak ve değeri önbelleğe almak (eğer pahalıysa) arasındaki farkı yaratabilir. Kesin olarak bilmiyorum, ama bu durumda Meyer belgelere bir uyarının eklenmesi gerektiği konusunda hemfikir olabilir .

Bununla başa çıkmanın başka bir yolu, adı uzun bir hesaplamanın (örneğin Person.ageCalculatedFromDB) gerçekleşebileceğini ima eden ve daha sonra Person.agesınıf içinde önbelleğe alınmış bir değer döndüren yeni bir özellik tanıtmak olabilir , ancak bu her zaman uygun olmayabilir ve fazla karmaşık görünüyor. şeyler bence.

Nesne yönelimli sınıflar için dökümantasyon genellikle sınıfın kullanıcılarına tasarımını değiştirebilme esnekliği vermek yerine sınıfın tüketicilerinin potansiyelini tam olarak kullanmalarını sağlamak arasında değişmezlik içerir. Sabit bir sınıfı, belirli bir olacaktır özellikleri bir dizi olacaksa tesisinin (birbirleriyle ilişki, örneğin Left, RightveWidthBir tamsayı koordinat ızgarası hizalanmış dikdörtgenin özellikleri), biri sınıfı iki öğenin herhangi bir birleşimini saklamak ve üçünü hesaplamak için tasarlayabilir veya biri üçünü de saklamak için tasarlayabilir. Arabirim hakkında hiçbir şey hangi özelliklerin saklandığını netleştirmezse, sınıfın programcısı bir nedenden ötürü yardımcı olacağını ispat etmesi durumunda tasarımı değiştirebilir. Buna karşılık, örneğin özelliklerin ikisi finalalan olarak gösteriliyorsa ve üçüncü değilse, sınıfın gelecekteki sürümleri her zaman "temel" olarak aynı iki özelliği kullanmak zorunda kalacak.

(Onlar çünkü örneğin özellikleri kesin bir ilişki yoksa floatveya doubleyerine int), o zaman özelliklerini bir sınıf değerini "define" belgesine gerekli olabilir. Örneğin, Leftartı Widthdeğerinin eşit olması gerekmesine rağmen Right, kayan nokta matematiği genellikle yanlış. Örneğin, Rectanglehangisinin kullandığını Floatkabul edelim Leftve Widthyapıcı parametreleri Leftolarak 1234567fve Widtholarak verilen ile oluşturulduğunu varsayalım 1.1f. floatToplamın en iyi gösterimi 1234568.125 [1234568.13 olarak gösterilebilir]; bir sonraki küçük float1234568.0 olacaktır. Sınıf gerçekten depolarsa LeftveWidthgenişlik değerini belirtildiği gibi bildirebilir. Ancak yapıcı olarak hesaplanır Eğer Rightiçinde geçti dayalı Leftve Widthdaha sonra, ve bilgisayarlı Widthdayalı Leftve Rightbu şekilde genişliğini rapor verecek 1.25fziyade geçti-deki gibi 1.1f.

Değişken sınıflarda, birbiriyle ilişkili değerlerden birindeki değişiklik, en az bir diğerinde değişiklik anlamına geleceği için işler daha da ilginç olabilir, ancak hangisinin olduğu her zaman net olmayabilir. Bazı durumlarda, bu gibi hangi "set", tek bir özellik yöntemleri zorunda kalmamak için iyi olmaması, onun yerine ya ör yöntemleri olabilir SetLeftAndWidthveya SetLeftAndRightözellikleri belirtilmiş olan ve değişen onlarda hangi, ya da başka marka temizleyin (örn MoveRightEdgeToSetWidth, ChangeWidthToSetLeftEdgeya MoveShapeToSetRightEdge) .

Bazen hangi özelliklerin değerlerinin belirlendiğini ve diğerlerinden hesaplanan bir sınıfın olması yararlı olabilir. Örneğin, "zamandaki bir an" sınıfı, mutlak bir zaman, yerel bir zaman ve bir zaman dilimi uzaklığı içerebilir. Bu tür pek çok tipte olduğu gibi, herhangi iki bilgi parçası verildiğinde, biri üçüncü bilgiyi hesaplayabilir. Hangisini bilmekAncak, bilgi parçası hesaplandı, ancak bazen önemli olabilir. Örneğin, bir etkinliğin "17:00 UTC, saat dilimi -5, yerel saat 12:00" de kaydedildiğini ve bir saatin saat diliminin -6 olması gerektiğini keşfettiğini varsayalım. Birisi UTC'nin bir sunucudan kaydedildiğini biliyorsa, kayıt "18:00 UTC, saat dilimi -6, yerel saat 12:00"; Birisi bir saat yerel saatte anahtarlanmışsa "17:00 UTC, saat dilimi -6, yerel saat 11:00" olmalıdır. Küresel veya yerel zamanın “daha ​​inanılır” olarak değerlendirilmesinin gerekip gerekmediğini bilmeden, hangi düzeltmenin uygulanması gerektiğini bilmek mümkün değildir. Bununla birlikte, kayıt hangi zamanın belirtildiğini takip ettiğinde, zaman diliminde yapılan değişiklikler diğerini değiştirirken onu yalnız bırakabilir.

Sınıflarda bilginin nasıl gizleneceğine dair tüm bu kurallar, sınıfın kullanıcıları arasında, iç uygulamaya bağımlılık yaratma hatası yapacak birisine karşı korunma ihtiyacı olduğu varsayımını mükemmel bir şekilde anlamıştır.

Sınıf böyle bir izleyici kitlesine sahipse, böyle bir korumaya dahil olmak iyidir. Ancak kullanıcı, sınıfınızdaki bir işleve çağrı yazdığında, yürütme zamanı banka hesabıyla size güveniyordur.

İşte çok gördüğüm bir şey:

1. Nesnelerin, bir anlamda güncel olmadıklarını söyleyen "değiştirilmiş" bir biti vardır. Yeterince basit, ama sonra alt nesneler var, bu yüzden "değiştirilmiş" olan tüm alt nesneler üzerinde toplanan bir işlev olmasını sağlamak kolaydır. Daha sonra birden fazla alt nesne katmanı varsa (bazen aynı nesneyi bir kereden fazla paylaşıyorsanız), basitçe "modifiye edilmiş" özelliğin "Get" sleri, yürütme süresinin sağlıklı bir bölümünü alarak sonuçlanabilir.

2. Bir nesne bir şekilde değiştirildiğinde, yazılımın etrafına dağılmış diğer nesnelerin "bildirilmesi" gerektiği varsayılır. Bu, farklı programcılar tarafından yazılan ve bazen korunmaları gereken sonsuz özyinelemelerde yinelenen birden çok veri yapısı, pencere vb. Katmanları üzerinde gerçekleşebilir. Bu bildirim işleyicilerinin tüm yazarları zaman kaybetmemek konusunda oldukça dikkatli olsalar bile, bileşik bileşimin tamamı öngörülemeyen ve acı verici bir şekilde yürütme süresinin büyük bir kısmını kullanarak sona erebilir ve bunun basitçe "gerekli" olduğu varsayımıyla birlikte yapılır.

SO, dış dünyaya güzel ve temiz bir soyut arabirim sunan sınıfları görmeyi seviyorum, ancak yalnızca bana hangi işi kurtardıklarını anlamak için nasıl çalıştıkları hakkında bir fikir vermeyi seviyorum. Fakat bunun ötesinde, "daha azının daha iyi" olduğunu hissetme eğilimindeyim. İnsanlar daha iyi olduğunu düşündükleri veri yapısından çok etkilendiler ve performans ayarladığımda performans problemlerinin evrensel büyük sebebi, insanlara öğretildiği şekilde yapılan şişirilmiş veri yapılarına yapışmayı slavik bir şekilde bağlı tutmak.

Öyleyse git figürü.

"Hesapla ya da ol" ya da "performans bilgisi" gibi uygulama detaylarını eklemek, kodu ve dokümanı senkronize etmeyi daha zorlaştırır .

Örnek:

"Performans pahalı" bir yönteminiz varsa, "pahalı" yöntemi kullanarak yöntemi kullanan tüm sınıfları da belgelemek ister misiniz? ya uygulamayı daha pahalı hale getirmeyecek şekilde değiştirirseniz. Bu bilgiyi tüm tüketicilere de güncellemek ister misiniz?

Elbette bir kod sorumlusu için kod dökümantasyonundan tüm önemli bilgileri almak güzel, fakat artık geçerli olmayan bir şey talep eden dökümantasyon gibi bir şey yapmıyorum (kodla senkronize değil)

Kabul edilen cevap ise sonuç olarak:

Yani: performans sorunlarını belgelemek.

ve kendi kendine belgelenen kodun, yöntem adının olağandışı herhangi bir performans sonucunu belirtmesi gerektiğini izleyen belgelere göre daha iyi olduğu düşünülür .

Yani hala Person.ageiçin return current_year - self.birth_dateama yöntem yaşı hesaplamak için bir döngü kullanıyorsa (evet):Person.calculateAge()