Sınıflarımı ve yöntemlerimi mümkün olduğunca küçük tutuyor musunuz?

Birkaç gün önce, Yazılım Mühendisliği doktora adayıyla konuşuyordum ve bir noktada bana şöyle dedi:

Sınıflarınızı ve yöntemlerinizi mümkün olduğunca küçük tutun

Ve bunun her zaman iyi bir uygulama olup olmadığını merak ediyorum.

Demek istediğim, içinde sadece 2 özelliğe sahip bir sınıfa layık mı? Örneğin, bazı yöntemlerde çalışmak için tamsayı çiftine ihtiyacım var. Bir "PairOfIntgers" sınıfı yazmalı mıyım?

Bu düşünme şekli kodu çok fazla parçaya "kırabilir" mi?

Bu tavsiyede bir gerçek doğrusu vardır, ancak IMHO çok iyi ifade edilmemiştir, bu nedenle yanlış anlaşılması ve / veya aptal bir uç noktaya götürülmesi kolaydır. Her halükarda, bu sert yasalardan ziyade temel bir kural olmalıdır. Ve her zaman bu kurallarda "makul sınırlar dahilinde" veya "ancak sağduyunuzu kullanmayı unutmayın" ifadesini ima etmelisiniz :-)

Gerçeğin taneciği, pratikte, sınıfların ve yöntemlerin her zaman doğası gereği küçülme eğilimi göstermesidir . Buradaki bir hata düzeltmesi, orada küçük bir özellik uzantısı, orada özel bir durum ele alıyor ... ve voila, bir zamanlar temiz ve küçük sınıfınız şişmeye başlıyor. Zaman içinde, kodunuz neredeyse kaçınılmaz olarak, yeniden düzenleme yoluyla bu eğilimde aktif olarak savaşmazsanız, korkunç bir spagetti karmaşası olma eğilimindedir . Yeniden düzenleme neredeyse her zaman birkaç büyük sınıftan daha küçük sınıflar / yöntemler üretir. Ancak elbette, minyatürleştirmenin mantıklı bir sınırı var. Yeniden düzenleme noktası, daha küçük sınıflara ve yöntemlere sahip olmak değil, kodunuzu daha temiz, anlaşılması ve bakımı daha kolay hale getirmektir.. Belirli bir noktada, yöntemlerinizi / sınıflarınızı küçültmek okunabilirliği artırmak yerine onu azaltmaya başlar. Optimum olanı hedefleyin. Bu bulanık ve hareketli bir hedef alandır, bu yüzden onu vurmanıza gerek yoktur. Sadece onunla bazı sorun fark ne zaman kod biraz geliştirmek .

Burada vurgulanması gereken en önemli konu iyi soyutlamalar yaratmaktır . Gevşek bağlanmış ve yüksek kohezyona sahip küçük sınıflar iyi soyutlamaların ürünüdür .

Bazen bir sınıfta iki tamsayıyı kapsüllemek mükemmel olur. Özellikle de bu özniteliklerin nasıl manipüle edilebileceğini ve bunları değiştiren programın diğer bölümlerinden koruduğunuzdan emin olmak için bu sınıfa 'eklenmiş' yöntemlerin olmasını istiyorsanız.

Bu durumda bir sınıf oluşturmak için bir başka pozitif, sınıfın bir Harita veya Liste gibi daha düşük seviyeli bir veri yapısı diyelim.

Üçüncüsü, iyi bir soyutlama okunabilirliği büyük ölçüde artırabilir. SRP'ye bağlı sınıfları bir insan tarafından anlamak genellikle anlamayan sınıflardan çok daha kolaydır.

Ve son bir not olarak ... ne kadar iyi bir öğrenci olursanız olun ... OOP ve iyi soyutlamaları anlamak ve bunları ne zaman kullanacağınız için deneyime ihtiyacınız vardır. Kötü kod yazmanız ve korumak için acıdan geçmeniz gerekir. Diğerlerinin 'iyi' ve çizginin altında bir sorun ne olacağına dair bilginizi geliştirmek için iyi kod yazdığını görmeniz gerekir ... Yani hemen almazsanız kendinizi dövmeyin.

Tanrı Nesnesi anti-paterni muhtemelen onunla ilgili olduğu şeydir. Sınıf açıklamamda "ve" varsa, iki sınıfımın olması gerektiğini düşünüyorum. Bir yöntem / işlevde ondan fazla kod satırı varsa, o zaman onu parçalamak gerekir. Korsan kodu olarak, bunlar kurallardan daha kılavuzdur.

Nesne yönelimli programlamada, tek sorumluluk ilkesi her nesnenin tek bir sorumluluğa sahip olması gerektiğini ve bu sorumluluğun tamamen sınıf tarafından kapsüllenmesi gerektiğini belirtir. Sınıfınız çok büyürse genellikle birden fazla şey yaparsınız. Sizin durumunuzda sınıf, sadece tamam olan verileri tutan bir veri sınıfıdır. PairOfInteger sınıfını adlandırmamalısınız. Tamsayılar ne tanımlar? Senaryonuza bağlı olarak, bir Tuple (C # gibi) de yeterli olabilir. Ve sınıf yerine dikme hakkında düşünmek isteyebilirsiniz.

Sýnýflarý küçük tutmaya çalýţ. Ve yöntemler daha da küçük. Belki 10 Satır?!? Şu anda, sınıfları küçük tutmaya yardımcı olan akış tasarımı ve olay tabanlı bileşenleri kullanmaya çalışıyorum. İlk olarak birçok sınıfa gitmek için endişelendim ama gerçekten işe yarıyor !!! http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03/19/flow-design-cheat-sheet-ndash-part-i-notation.aspx http://geekswithblogs.net/theArchitectsNapkin/archive/2011/03 /20/flow-design-cheat-sheet-ndash-part-ii-translation.aspx

İşleri olabildiğince basitleştirin, ancak daha basit değil. Bu benim yapmaya çalıştığım kural. Bazen, bir sınıfın, ortak bir temayla ilgili olması durumunda , kesinlikle konuşmanın birden fazla şey anlamına gelmesi aslında bir anlam ifade eder . .NET'e bakın; her biri kendi gerekli üyeleri olan çok sayıda arabirim uygulayan tonlarca sınıf var. Bir yöntem, hepsi birbirine bağlı olan ve böylece daha fazla yeniden düzenleme için çok iyi borç vermeyen bir dizi ara adımla karmaşık bir şey yaparsa, biraz uzun olması gerekebilmektedir. (Yöntemleri kısa tutmak için yeniden düzenleme nihayetinde okunabilirlik ve sürdürülebilirlikle ilgili olmalıdır; uzun yöntem kısa bir yöntemden daha okunabilir ve / veya sürdürülebilirse, diğer her şey eşitse, uzun olanı her gün alacağım.)

Bence sadece "sınıfları ve yöntemleri olabildiğince küçük yapmak" yanlış yönlendiriliyor. Asıl zorluk, @c_maker'in işaret ettiği gibi, iyi soyutlamalar sağlamaktır. İki sayıyı birlikte gruplama örneğiniz harika, örneğin karmaşık sayıların aritmetik bir uygulaması üzerinde çalışıyorsanız veya bir Unix sisteminde bir kullanıcı / grup bağlamına başvurmanız gerekiyorsa. Numaraların örneğin bir fatura kimliğini ve bu faturaya eklenecek bir ürün kimliğini temsil etmesi çok az mantıklıdır.

Bu iyi bir tavsiye, ama biraz akıllıca uygulanması gerekiyor. Kesinlikle körü körüne takip etmeyin.

Koduma baktığımda bir yöntemin çok büyük olup olmadığını biliyorum. Çok fazla şey yapıyorsa ve okumak çok zorsa, o zaman refactor zamanı.

İşte iyi bir örnek: bir döngünüz var ve bu yöntemde belki 60 satır kodunuz var. Bu durumda, muhtemelen bu yöntemde çok fazla şey yaptığınız için yeniden düzenleme zamanı.

Ancak bu zor ve hızlı bir kural değildir. Sadece yaparak öğrenebileceğiniz bir şey. Ve birlikte çalıştığınız diğer geliştiriciler her zaman aynı fikirde değilim ve bir kod incelemesinde ya da her neyse sizi arayabilir.

Bob Amca, yöntemleri küçültmek imkansız olana kadar yöntemlerinizi yeniden düzenlemeniz / bölmeniz / çıkartmanız gerektiğini söylüyor . Bu genellikle her biri 3 veya 4 satırlı çeşitli yöntemlere sahip olmakla biter. Çok fazla yöntem elde ettiğinizde daha fazla sınıf yapmanız gerekir.

SRP'yi ve yöntem başına bir soyutlama düzeyini takip etmeye çalışırsanız, bu kurallar size iyi hizmet eder. En azından bana iyi hizmet ediyorlar. "Mümkün olduğunca küçük" kelimesini hedeflemek, genellikle amacı kısa sürdüğüm için bana makul küçük yöntemler sağlar.

Ve daha küçük sınıfları anlamak her zaman daha kolaydır. Devam edin, "Kodu Temizle" yi okuyun