Kodlama Kuralları: Sistem Oluşturmaktan Nesnelerle Çalışmaya

Cümleten iyi günler! Bugün sizlerle iyi kod yazmaktan bahsetmek istiyoruz. Tabii ki, herkes Temiz Kod gibi kitapları hemen çiğnemek istemez, çünkü çok miktarda bilgi içerirler, ancak ilk başta pek bir şey net değildir. Ve okumayı bitirdiğinizde, tüm kodlama arzunuzu öldürebilirsiniz. Tüm bunları göz önünde bulundurarak, bugün size daha iyi kod yazmanız için küçük bir rehber (küçük bir dizi öneri) sunmak istiyorum. Bu yazıda, bir sistem oluşturmak ve arayüzler, sınıflar ve nesnelerle çalışmakla ilgili temel kural ve kavramların üzerinden geçelim. Bu makaleyi okumak fazla zamanınızı almayacak ve umarım sizi sıkmaz. Baştan aşağı, yani bir uygulamanın genel yapısından en ince detaylarına kadar kendi yolumu çizeceğim.

Sistemler

Aşağıdakiler genellikle bir sistemin istenen özellikleridir:

• Minimum karmaşıklık. Aşırı karmaşık projelerden kaçınılmalıdır. En önemli şey basitlik ve netliktir (daha basit = daha iyi).
• Bakım kolaylığı. Bir uygulama oluştururken, bakımının yapılması gerektiğini unutmamalısınız (bakımından kişisel olarak sorumlu olmayacak olsanız bile). Bu, kodun açık ve net olması gerektiği anlamına gelir.
• Gevşek kaplin. Bu, programın farklı bölümleri arasındaki bağımlılık sayısını en aza indirdiğimiz anlamına gelir (OOP ilkelerine uygunluğumuzu en üst düzeye çıkarırız).
• Tekrar Kullanılabilirlik. Sistemimizi, bileşenleri başka uygulamalarda yeniden kullanabilme yeteneği ile tasarlıyoruz.
• taşınabilirlik Bir sistemi başka bir ortama uyarlamak kolay olmalıdır.
• Üniforma tarzı. Sistemimizi çeşitli bileşenlerinde tek tip bir stil kullanarak tasarlıyoruz.
• Genişletilebilirlik (ölçeklenebilirlik). Sistemi temel yapısını bozmadan geliştirebiliriz (bir bileşen eklemek veya değiştirmek diğerlerini etkilememelidir).

Değişiklikler veya yeni işlevler gerektirmeyen bir uygulama oluşturmak neredeyse imkansızdır. Beyin çocuğumuzun zamana ayak uydurmasına yardımcı olmak için sürekli olarak yeni parçalar eklememiz gerekecek. Ölçeklenebilirlik burada devreye giriyor. Ölçeklenebilirlik, temelde uygulamayı genişletmek, yeni işlevler eklemek ve daha fazla kaynakla (veya başka bir deyişle daha büyük bir yükle) çalışmaktır. Yani yeni mantık eklemeyi kolaylaştırmak için modülerliği artırarak sistemin kaplinini azaltmak gibi bazı kurallara bağlı kalıyoruz.

Görüntü Kaynağı

Bir sistem tasarlamanın aşamaları

1. Yazılım sistemi. Uygulamayı genel olarak tasarlayın.
2. Alt sistemlere/paketlere bölünme. Mantıksal olarak farklı parçaları tanımlayın ve aralarındaki etkileşim kurallarını tanımlayın.
3. Alt sistemlerin sınıflara bölünmesi. Sistemin parçalarını belirli sınıflara ve arayüzlere ayırın ve aralarındaki etkileşimi tanımlayın.
4. Sınıfların yöntemlere bölünmesi. Atanan sorumluluğa göre bir sınıf için gerekli yöntemlerin eksiksiz bir tanımını oluşturun.
5. Yöntem tasarımı. Tek tek yöntemlerin işlevselliğinin ayrıntılı bir tanımını oluşturun.

Genellikle sıradan geliştiriciler bu tasarımı, uygulamanın mimarı ise yukarıda açıklanan noktaları ele alır.

Sistem tasarımının genel ilkeleri ve kavramları

Tembel başlatma. Bu programlama deyiminde, uygulama gerçekten kullanılana kadar bir nesne yaratmakla vakit kaybetmez. Bu, başlatma sürecini hızlandırır ve çöp toplayıcı üzerindeki yükü azaltır. Bununla birlikte, bunu çok ileri götürmemelisiniz çünkü bu, modülerlik ilkesini ihlal edebilir. Belki de tüm inşaat örneklerini belirli bir bölüme, örneğin ana yönteme veya bir fabrika sınıfına taşımaya değer . İyi kodun bir özelliği, tekrar eden standart kodun olmamasıdır. Kural olarak, bu tür bir kod gerektiğinde çağrılabilmesi için ayrı bir sınıfa yerleştirilir.

AOP

En boy yönelimli programlamaya da dikkat çekmek isterim. Bu programlama paradigması tamamen şeffaf mantığı tanıtmakla ilgilidir. Yani, tekrarlayan kod sınıflara (aspects) konur ve belirli koşullar sağlandığında çağrılır. Örneğin, belirli bir ada sahip bir yöntemi çağırırken veya belirli bir türdeki bir değişkene erişirken. Kodun nereden çağrıldığı hemen belli olmadığından bazen yönler kafa karıştırıcı olabilir, ancak bu yine de çok kullanışlı bir işlevselliktir. Özellikle önbelleğe alırken veya günlüğe kaydederken. Sıradan sınıflara ek mantık eklemeden bu işlevselliği ekliyoruz. Kent Beck'in basit bir mimari için dört kuralı:

1. Etkileyicilik — Bir sınıfın amacı açıkça ifade edilmelidir. Bu, uygun adlandırma, küçük boyut ve tek sorumluluk ilkesine bağlı kalma yoluyla elde edilir (aşağıda daha ayrıntılı olarak ele alacağız).
2. Minimum sınıf ve yöntem sayısı — Sınıfları olabildiğince küçük ve dar odaklı hale getirme arzunuzda çok ileri gidebilirsiniz (bu da av tüfeği ameliyatı anti-paterniyle sonuçlanır). Bu ilke, sistemi kompakt tutmayı ve fazla ileri gitmemeyi, olası her eylem için ayrı bir sınıf oluşturmayı gerektirir.
3. Yineleme yok — Karışıklık yaratan ve yetersiz sistem tasarımının bir göstergesi olan yinelenen kod ayıklanır ve ayrı bir konuma taşınır.
4. Tüm testleri çalıştırır — Tüm testleri geçen bir sistem yönetilebilir. Herhangi bir değişiklik, bir testin başarısız olmasına neden olabilir ve bize, bir yöntemin iç mantığındaki değişikliğimizin sistemin davranışını da beklenmedik şekillerde değiştirdiğini gösterir.

SAĞLAM

Bir sistem tasarlarken iyi bilinen SOLID ilkeleri göz önünde bulundurulmaya değer:

S (tek sorumluluk), O (açık-kapalı), L (Liskov ikamesi), I (arayüz ayrımı), D (bağımlılık tersine çevirme).

Her bir ilke üzerinde durmayacağız. Bu, bu makalenin kapsamını biraz aşar, ancak daha fazlasını buradan okuyabilirsiniz .

Arayüz

İyi tasarlanmış bir sınıf oluşturmanın belki de en önemli adımlarından biri, iyi bir soyutlamayı temsil eden iyi tasarlanmış bir arayüz oluşturmak, sınıfın uygulama ayrıntılarını gizlemek ve aynı anda birbiriyle açıkça tutarlı bir grup yöntem sunmaktır. SOLID ilkelerinden biri olan arabirim ayrımına daha yakından bakalım: istemciler (sınıflar), kullanmayacakları gereksiz yöntemleri uygulamamalıdır. Diğer bir deyişle, arayüzün tek işini yapmaya yönelik en az sayıda yöntemle arayüz oluşturmaktan bahsediyorsak (ki bu bence tek sorumluluk ilkesine çok benziyor), bunun yerine birkaç küçük tane oluşturmak daha iyidir. şişirilmiş bir arayüzün. Neyse ki, bir sınıf birden fazla arayüz uygulayabilir. Arayüzlerinizi düzgün bir şekilde adlandırmayı unutmayın: isim, atanan görevi olabildiğince doğru bir şekilde yansıtmalıdır. Ve elbette, ne kadar kısa olursa, o kadar az kafa karışıklığına neden olur. Dokümantasyon yorumları genellikle arayüz seviyesinde yazılır. Bu yorumlar, her yöntemin ne yapması gerektiği, hangi argümanları aldığı ve ne döndüreceği hakkında ayrıntılar sağlar.

Sınıf

Görüntü Kaynağı

Sınıfların dahili olarak nasıl düzenlendiğine bir göz atalım. Daha doğrusu ders yazarken uyulması gereken bazı bakış açıları ve kurallar. Kural olarak, bir sınıf, belirli bir sıradaki değişkenlerin bir listesiyle başlamalıdır:

1. genel statik sabitler;
2. özel statik sabitler;
3. özel örnek değişkenleri.

Daha sonra, en az argümana sahip olanlardan en fazla argümana sahip olanlara doğru çeşitli kurucular gelir. Bunları en genelden en özele doğru yöntemler takip eder. Genel olarak, kısıtlamak istediğimiz bazı işlevlerin uygulanmasını gizleyen özel yöntemler en alttadır.

Sınıf boyutu

Şimdi sınıfların büyüklüğünden bahsetmek istiyorum. SOLID ilkelerinden birini, tek sorumluluk ilkesini hatırlayalım. Her nesnenin tek bir amacı (sorumluluğu) olduğunu ve tüm yöntemlerinin mantığının bunu gerçekleştirmeyi amaçladığını belirtir. Bu bize büyük, şişirilmiş sınıflardan (aslında Tanrı nesnesi anti-kalıptır) kaçınmamızı söyler ve eğer bir sınıfa sıkıştırılmış her türden farklı mantığa sahip birçok yöntemimiz varsa, onu parçalara ayırmayı düşünmemiz gerekir. birkaç mantıksal parça (sınıf). Bu da, herhangi bir sınıfın yaklaşık amacını bilirsek, her bir yöntemin amacını anlamamız uzun sürmeyeceğinden, kodun okunabilirliğini artıracaktır. Ayrıca, içerdiği mantığı yansıtması gereken sınıf adına da dikkat edin. Örneğin, adında 20'den fazla kelime bulunan bir sınıfımız varsa, yeniden düzenlemeyi düşünmemiz gerekiyor. Kendine saygısı olan herhangi bir sınıf bu kadar çok dahili değişkene sahip olmamalıdır. Aslında, her yöntem bir veya birkaç tanesiyle çalışır ve sınıf içinde çok fazla uyuma neden olur (bu tam olarak olması gerektiği gibidir, çünkü sınıf birleşik bir bütün olmalıdır). Sonuç olarak, bir sınıfın uyumunu artırmak, sınıf mevcudunun küçülmesine ve tabii ki sınıf sayısının artmasına neden olur. Belirli bir büyük görevin nasıl çalıştığını görmek için sınıf dosyalarını daha fazla incelemeniz gerektiğinden, bu bazı insanlar için can sıkıcıdır. Hepsinden önemlisi, her sınıf, diğerleriyle asgari düzeyde ilişkili olması gereken küçük bir modüldür. Bu yalıtım, bir sınıfa ek mantık eklerken yapmamız gereken değişiklik sayısını azaltır. her yöntem bir veya birkaç tanesiyle çalışır ve sınıf içinde çok fazla uyuma neden olur (sınıfın birleşik bir bütün olması gerektiğinden bu tam olarak olması gerektiği gibidir). Sonuç olarak, bir sınıfın uyumunu artırmak, sınıf mevcudunun küçülmesine ve tabii ki sınıf sayısının artmasına neden olur. Belirli bir büyük görevin nasıl çalıştığını görmek için sınıf dosyalarını daha fazla incelemeniz gerektiğinden, bu bazı insanlar için can sıkıcıdır. Hepsinden önemlisi, her sınıf, diğerleriyle asgari düzeyde ilişkili olması gereken küçük bir modüldür. Bu yalıtım, bir sınıfa ek mantık eklerken yapmamız gereken değişiklik sayısını azaltır. her yöntem bir veya birkaç tanesiyle çalışır ve sınıf içinde çok fazla uyuma neden olur (sınıfın birleşik bir bütün olması gerektiğinden bu tam olarak olması gerektiği gibidir). Sonuç olarak, bir sınıfın uyumunu artırmak, sınıf mevcudunun küçülmesine ve tabii ki sınıf sayısının artmasına neden olur. Belirli bir büyük görevin nasıl çalıştığını görmek için sınıf dosyalarını daha fazla incelemeniz gerektiğinden, bu bazı insanlar için can sıkıcıdır. Hepsinden önemlisi, her sınıf, diğerleriyle asgari düzeyde ilişkili olması gereken küçük bir modüldür. Bu yalıtım, bir sınıfa ek mantık eklerken yapmamız gereken değişiklik sayısını azaltır. Uyum, sınıf mevcudunda bir azalmaya yol açar ve tabii ki sınıf sayısı artar. Belirli bir büyük görevin nasıl çalıştığını görmek için sınıf dosyalarını daha fazla incelemeniz gerektiğinden, bu bazı insanlar için can sıkıcıdır. Hepsinden önemlisi, her sınıf, diğerleriyle asgari düzeyde ilişkili olması gereken küçük bir modüldür. Bu yalıtım, bir sınıfa ek mantık eklerken yapmamız gereken değişiklik sayısını azaltır. Uyum, sınıf mevcudunda bir azalmaya yol açar ve tabii ki sınıf sayısı artar. Belirli bir büyük görevin nasıl çalıştığını görmek için sınıf dosyalarını daha fazla incelemeniz gerektiğinden, bu bazı insanlar için can sıkıcıdır. Hepsinden önemlisi, her sınıf, diğerleriyle asgari düzeyde ilişkili olması gereken küçük bir modüldür. Bu yalıtım, bir sınıfa ek mantık eklerken yapmamız gereken değişiklik sayısını azaltır.

nesneler

kapsülleme

Burada ilk olarak bir OOP ilkesinden bahsedeceğiz: kapsülleme. Uygulamayı gizlemek, değişkenleri yalıtmak için bir yöntem oluşturmak anlamına gelmez (kapsüllemenin tüm noktası kaybolduğu için iyi olmayan, bireysel yöntemler, alıcılar ve ayarlayıcılar yoluyla erişimi düşüncesizce kısıtlamak). Gizli erişim, soyutlamalar oluşturmayı amaçlar, yani sınıf, verilerimizle çalışmak için kullandığımız paylaşılan somut yöntemler sağlar. Ve kullanıcının bu verilerle tam olarak nasıl çalıştığımızı bilmesine gerek yok - çalışıyor ve bu kadarı yeterli.

Demeter Kanunu

Demeter Yasasını da düşünebiliriz: sınıf ve yöntem düzeyinde karmaşıklığı yönetmeye yardımcı olan küçük bir kurallar dizisidir. Diyelim ki bir Araba nesnemiz var ve bunun bir move(Object arg1, Object arg2) yöntemi var. Demeter Yasasına göre, bu yöntem şu çağrılarla sınırlıdır:

• Car nesnesinin kendisinin yöntemleri (başka bir deyişle, "bu" nesne);
• move yöntemi içinde oluşturulan nesnelerin yöntemleri ;
• argüman olarak iletilen nesnelerin yöntemleri ( arg1 , arg2 );
• dahili Car nesnelerinin yöntemleri (yine "bu").

Başka bir deyişle, Demeter Yasası, ebeveynlerin bir çocuğa söyleyebilecekleri bir şeydir: "Arkadaşlarınla ​​konuşabilirsin ama yabancılarla konuşamazsın".

Veri yapısı

Bir veri yapısı, ilgili öğelerin bir koleksiyonudur. Bir nesneyi veri yapısı olarak ele alırken, yöntemlerin üzerinde çalıştığı bir dizi veri öğesi vardır. Bu yöntemlerin varlığı dolaylı olarak varsayılır. Yani, bir veri yapısı, amacı saklanan verileri depolamak ve bunlarla çalışmak (işlemek) olan bir nesnedir. Normal bir nesneden en önemli farkı, sıradan bir nesnenin dolaylı olarak var olduğu varsayılan veri öğeleri üzerinde çalışan bir yöntemler topluluğu olmasıdır. Anlıyor musunuz? Sıradan bir nesnenin ana yönü yöntemlerdir. Dahili değişkenler doğru çalışmalarını kolaylaştırır. Ancak bir veri yapısında, burada çok önemli olan saklanan veri öğeleriyle çalışmanızı desteklemek için yöntemler vardır. Bir tür veri yapısı, bir veri aktarım nesnesidir (DTO). Bu, genel değişkenlere sahip bir sınıftır ve veritabanlarıyla çalışırken, soketlerden gelen mesajları ayrıştırırken vb. verileri aktarmak için kullanılan hiçbir yöntem içermez (veya yalnızca okuma/yazma için yöntemlerdir). Veriler genellikle bu tür nesnelerde uzun süre saklanmaz. Uygulamamızın çalıştığı varlık türüne neredeyse anında dönüştürülür. Bir varlık da bir veri yapısıdır, ancak amacı, uygulamanın çeşitli düzeylerinde iş mantığına katılmaktır. Bir DTO'nun amacı, verileri uygulamaya/uygulamadan taşımaktır. DTO örneği: aynı zamanda bir veri yapısıdır, ancak amacı, uygulamanın çeşitli düzeylerinde iş mantığına katılmaktır. Bir DTO'nun amacı, verileri uygulamaya/uygulamadan taşımaktır. DTO örneği: aynı zamanda bir veri yapısıdır, ancak amacı, uygulamanın çeşitli düzeylerinde iş mantığına katılmaktır. Bir DTO'nun amacı, verileri uygulamaya/uygulamadan taşımaktır. DTO örneği:

@Setter
@Getter
@NoArgsConstructor
public class UserDto {
    private long id;
    private String firstName;
    private String lastName;
    private String email;
    private String password;
}

Her şey yeterince açık görünüyor, ancak burada melezlerin varlığını öğreniyoruz. Melezler, önemli mantığı işlemek, dahili öğeleri depolamak için yöntemleri olan ve ayrıca erişimci (get/set) yöntemlerini içeren nesnelerdir. Bu tür nesneler dağınıktır ve yeni yöntemler eklemeyi zorlaştırır. Onlardan kaçınmalısınız, çünkü ne işe yaradıkları açık değil - öğeleri depolamak mı yoksa mantık yürütmek mi?

Değişken oluşturma ilkeleri

Değişkenler hakkında biraz düşünelim. Daha spesifik olarak, bunları oluştururken hangi ilkelerin geçerli olduğunu düşünelim:

1. İdeal olarak, bir değişkeni kullanmadan hemen önce bildirmeli ve başlatmalısınız (bir tane oluşturup unutmayın).
2. Mümkün olduğunda, başlatma sonrasında değerlerinin değişmesini önlemek için değişkenleri final olarak bildirin.
3. Genellikle bir çeşit for döngüsünde kullandığımız sayaç değişkenlerini unutmayın . Yani, onları sıfırlamayı unutmayın. Aksi takdirde tüm mantığımız bozulabilir.
4. Yapıcıdaki değişkenleri başlatmayı denemelisiniz.
5. Bir nesneyi referanslı veya referanssız ( new SomeObject() ) kullanma arasında bir seçim varsa , referanssız seçeneğini seçin, çünkü nesne kullanıldıktan sonra bir sonraki çöp toplama döngüsü sırasında silinecek ve kaynakları boşa gitmeyecektir.
6. Bir değişkenin ömrünü (değişkenin oluşturulması ile son başvurulduğu zaman arasındaki mesafe) mümkün olduğu kadar kısa tutun.
7. Bir döngüde kullanılan değişkenleri, döngüyü içeren yöntemin başında değil, döngüden hemen önce başlatın.
8. Daima en sınırlı kapsamdan başlayın ve yalnızca gerektiğinde genişletin (mümkün olduğunca bir değişkeni yerel yapmaya çalışmalısınız).
9. Her değişkeni yalnızca bir amaç için kullanın.
10. Gizli bir amaca sahip değişkenlerden kaçının, örneğin iki görev arasında bölünmüş bir değişken — bu, türünün bunlardan birini çözmek için uygun olmadığı anlamına gelir.

Yöntemler

"Yıldız Savaşları: Bölüm III - Sith'in İntikamı" filminden (2005)

Doğrudan mantığımızın uygulanmasına, yani yöntemlere geçelim.

1. Kural 1 — Kompaktlık. İdeal olarak, bir yöntem 20 satırı geçmemelidir. Bu, bir genel yöntem önemli ölçüde "şişerse", mantığı parçalara ayırmayı ve onu ayrı özel yöntemlere taşımayı düşünmeniz gerektiği anlamına gelir.

2. Kural 2 — if , else , while ve diğer ifadeler yoğun şekilde iç içe geçmiş bloklara sahip olmamalıdır: çok sayıda iç içe geçme, kodun okunabilirliğini önemli ölçüde azaltır. İdeal olarak, ikiden fazla iç içe geçmiş {} bloğunuz olmamalıdır .

   Ayrıca, bu bloklardaki kodun kompakt ve basit tutulması da arzu edilir.

3. Kural 3 — Bir yöntem yalnızca bir işlem gerçekleştirmelidir. Yani, bir metot her türlü karmaşık mantığı gerçekleştiriyorsa, onu alt metotlara ayırırız. Sonuç olarak, yöntemin kendisi, amacı diğer tüm işlemleri doğru sırayla çağırmak olan bir cephe olacaktır.

   Peki ya işlem ayrı bir yönteme konulamayacak kadar basit görünüyorsa? Doğru, bazen serçelere top atmak gibi gelebilir, ancak küçük yöntemler bir dizi avantaj sağlar:

   • Daha iyi kod anlama;
   • Geliştirme ilerledikçe yöntemler daha karmaşık hale gelme eğilimindedir. Bir yöntemin başlaması basitse, işlevselliğini karmaşık hale getirmek biraz daha kolay olacaktır;
   • Uygulama detayları gizlidir;
   • Daha kolay kod yeniden kullanımı;
   • Daha güvenilir kod.

4. Düşürme kuralı - Kod yukarıdan aşağıya okunmalıdır: ne kadar aşağı okursanız, mantığa o kadar derinden inersiniz. Tersine, ne kadar yükseğe çıkarsanız, yöntemler o kadar soyut olur. Örneğin, switch deyimleri oldukça kompakt değildir ve istenmez, ancak bir switch kullanmaktan kaçınamıyorsanız, onu mümkün olduğu kadar aşağıya, en düşük seviyeli yöntemlere taşımaya çalışmalısınız.

5. Yöntem bağımsız değişkenleri — İdeal sayı nedir? İdeal olarak, hiç :) Ama bu gerçekten oluyor mu? Bununla birlikte, mümkün olduğunca az argümana sahip olmaya çalışmalısınız, çünkü ne kadar az argüman varsa, bir yöntemi kullanmak o kadar kolay ve onu test etmek o kadar kolay olur. Şüpheye düştüğünüzde, yöntemi çok sayıda girdi parametresiyle kullanmak için tüm senaryoları tahmin etmeye çalışın.

6. Ek olarak, bir girdi parametresi olarak bir boole bayrağına sahip yöntemleri ayırmak iyi olur, çünkü bu tek başına yöntemin birden fazla işlem gerçekleştirdiğini ima eder (doğruysa bir şey yapın; yanlışsa başka bir şey yapın). Yukarıda yazdığım gibi, bu iyi değil ve mümkünse kaçınılmalıdır.

7. Bir yöntemin çok sayıda girdi parametresi varsa (en uç nokta 7'dir, ancak gerçekten 2-3'ten sonra düşünmeye başlamalısınız), argümanlardan bazıları ayrı bir nesnede gruplandırılmalıdır.

8. Birkaç benzer (aşırı yüklenmiş) yöntem varsa, benzer parametrelerin aynı sırayla iletilmesi gerekir: bu, okunabilirliği ve kullanılabilirliği artırır.

9. Parametreleri bir yönteme ilettiğinizde, hepsinin kullanıldığından emin olmalısınız, aksi halde neden onlara ihtiyacınız var? Kullanılmayan tüm parametreleri arayüzden çıkarın ve onunla işinizi bitirin.

10. try/catch doğası gereği pek hoş görünmüyor, bu yüzden onu ayrı bir ara yönteme (istisnaları ele almak için bir yöntem) taşımak iyi bir fikir olacaktır:

    
    public void exceptionHandling(SomeObject obj) {
        try {  
            someMethod(obj);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    

Yukarıda mükerrer koddan bahsetmiştim ama bir kez daha tekrar edeyim: Tekrarlayan kodlu birkaç metodumuz varsa onu ayrı bir metoda taşımamız gerekiyor. Bu, hem yöntemi hem de sınıfı daha kompakt hale getirecektir. Adları yöneten kuralları unutmayın: sınıfların, arabirimlerin, yöntemlerin ve değişkenlerin doğru şekilde nasıl adlandırılacağına ilişkin ayrıntılar makalenin bir sonraki bölümünde tartışılacaktır. Ama bugün senin için sahip olduğum tek şey bu.