Sınıf yöntemlerinin sayısının sınırı nedir?

Okuduğum farklı tasarım kitaplarında, bazen bir sınıfın sahip olması gereken yöntemlere büyük önem verilmektedir (örneğin bir OO dili, örneğin java veya C # gibi). Genellikle bu kitaplarda bildirilen örnekler çok düzenli ve basittir, ancak nadiren “ciddi” veya karmaşık bir durumu ele alırlar.
Ancak bu aralık 5 ile 8 arasında görünüyor.

Bir projede özellikleri olarak nitelikleriyle birlikte bir "Not" sınıfı geliştirdim: Başlık, Tanımlama, Yaratma Tarihi, vb.
Sonra bazı temel yöntemler: getRelations (not farklı belgelere atanmışsa), getExpiryDate, ect.

Bununla birlikte, uygulamanın geliştirilmesine devam etmek için daha fazla işlevsellik ve bu nedenle daha fazla yöntem gerekliydi.

Bir sınıfın ne kadar az metodu varsa o kadar gevşek bir şekilde bağlanmış olduğunu biliyorum. Bu, modülerlik ve yeniden kullanılabilirlik açısından iyi bir avantaj, ayrıca düzenlemesi daha kolay.
Bu arada, bağlamımızda alt sınıflar yaratmaya gerek kalmaz ve hatta alt sınıflar oluşturmaya gerek kalmazsa ve gerekli tüm fonksiyonlar bu sınıfla ilişkiliyse, daha fazla kaç yöntem ekleyebiliriz?

15'ten fazla yönteme sahip olmanızın ardından belki biraz yeniden tasarım yapılması gerekebileceğini kabul ediyorum.
Ancak bu durumda bile, bazı yöntemlerin veya mirasın silinmesi bir seçenek değilse, hangisi doğru şekilde olur?

İhtiyacınız kadar çok yöntem var. Mümkünse, genel metotların sayısını 5-8 kuralına göre tutmaya çalışacağım. Dürüst olmak gerekirse, çoğu insan, daha az değil, daha fazla parçalanması gereken çılgın süper yöntemlerin olduğu zıt bir soruna sahiptir. Gerçekten ne kadar özel yardımcı yönteminiz olduğu önemli değil. Aslında, eğer Java'da 8 yöntemin altında kalsaydınız, yalnızca kurucu, toString ve 3 özellik için alıcı / ayarlayıcı olan bir sınıfla ... tam olarak sağlam bir sınıf olamazdı. Alt satırda, sınıfınızın kaç yöntem olduğu konusunda endişelenmeyin. Sınıfınızın alakasız endişeleri almadığından ve anlaşılması kolay yöntemleri olan makul bir ortak arayüze sahip olduğunuzdan emin olun.

Cevap gerçekten çok basit: Her şeyi sorumluluklarına ait bir sınıfa koyun, fakat sorumlulukları atarken dikkatli olun.

Bazen büyük bir sınıf, farklı sorumluluklara sahip daha küçük sınıfların bir birleşimidir.

Genel olarak, sınıf kullanımında veya bakımında güvensiz olduğunda sorumlulukları daha küçük sınıflara bölmeye çalışıyorum. Nadiren 500 çizgiden daha uzun sınıflarım var. En büyük sınıflarım yaklaşık 1.5k lokasyonda.

"Bir sınıf n ile m yöntemleri arasında olmalı" gibi genel bir kural belirtemezsiniz.

(OO tasarımında) yalnızca bu kadar çok yönteme sahip olmanın bir nedeni yoktur. Ayrıca, daha az yöntem içeren bir sınıfın daha iyi bir şekilde çözüldüğü de doğru değildir.

Örneğin, java.lang.String sınıfına bakın. Birçok yöntem var, çünkü dize ile yapılabilecek çok fazla şey var. Bununla birlikte, güçlü bir şekilde birleştirilmemiş.

Neden 15 gibi bir sihirli sayının iyi ve kötü tasarımı birbirinden ayırabildiğini merak ediyorum. Hayır, o kadar kolay değil.

PMD'de , TooManyMethods kuralının varsayılan davranışı, sınıfları potansiyel hatalar olarak 10 veya daha fazla yöntemle tanımlamak ve işaretlemektir. Bu, sadece keyfi bir sayı. Bir konfigürasyonda kolayca değiştirilir. Bu sayı ne olursa olsun, bir geliştiricinin bir sınıfa bakıp bir sorun olup olmadığını görmek için bir sorun olup olmadığını görmek için sadece bir bayrak.

Biraz daha somut olan bir şey 7 artı / eksi 2 kuralı olabilir . Bu, insan aklının hafızada 5 ile 9 arasında “nesne” tutabildiğini ve kavrayabildiğini belirtir. Belirli bir sınıfı okurken, nesneler büyük olasılıkla o sınıfı oluşturan yöntemler ve alanlar olacaktır. Erişimcilere, mutators ve herhangi bir standart işlemleri sayılmaz bile Ancak, sınıflar sık, 9'dan fazla alan ve yöntemleri vardır (örneğin, toString(), hashCode(), ve equals()Java).

En uygun önlemler, taraftar ve taraftar ile kuplaj ve uyum tartışmaları olacaktır . Tek sorumluluk ilkesi ve endişeleri ayrılması bir sınıf yapmak veya bir şeyi tek başına bir şey temsil etmeli - uygulanmalıdır. Bunlar, bir tasarım veya uygulamayı değerlendirirken, maksimum / minimum yöntem sayılarına numara atamaya çalışmaktan çok daha iyidir.