Giriş

Robert L. Glass, teoriden ziyade pratiğin önce geldiğini savundu. Özellikle yazılım geliştirmede, uygulama teoriden önce gelir; geliştiriciler, en çok ellerini kirleterek somut kodlarla uğraştıklarında öğrenirler. Bu nedenle teori ve kavramları bir kenara bırakıp, basit bir programı inceleyeceğiz.

Bilet Satış Uygulaması Oluşturmak

• Küçük bir tiyatronun tanıtımı için küçük bir etkinlik düzenliyoruz.
  • Etkinlik içeriği: Kura çekilişiyle seçilen izleyicilere ücretsiz gösteri izleme davetiyesi gönderilecek
• Etkinlikte kazanan ve kazanamayan izleyiciler ayrılmalıdır.
  • Etkinlik kazananları: Davetlerini bilete çevirebilirler
  • Etkinlik kaybedenleri: Bileti parayla satın alabilirler

Uygulama kodu: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step01

Sorun Nedir?

Robert Martin, bir yazılım modülünün (boyutundan bağımsız olarak, bir sınıf, paket veya kütüphane gibi bir programı oluşturan herhangi bir öğe) sahip olması gereken üç işlev hakkında konuşur.

• Çalışma zamanında düzgün çalışır.
• Değişim için vardır.
  • Basit bir eylemle değiştirilebilmelidir.
• Kodu okuyan kişilerle iletişim kurar.
  • Geliştiriciler tarafından kolayca okunabilir ve anlaşılabilir olmalıdır.

Yukarıdaki bilet satış uygulaması, düzgün çalıştığına dair ilk kısıtlamayı karşılasa da, değişiklik kolaylığı ve iletişim hedeflerini karşılamıyor.

Beklentileri Bozan Kod

İletişim hedefini karşılayamadığı nedenlerine bakalım.

• Theater sınıfının enter() yönteminin yaptığı şey
  • Tiyatro, izleyicinin çantasını açıp içinden davetiye olup olmadığına bakar.
  • Çantada davetiye varsa, satıcıya gişede saklanan bileti izleyicinin çantasına taşımasını söyler.
  • Çantada davetiye yoksa, izleyicinin çantasından bilet bedelini çıkarır, bileti satın alır ve bileti çantasına koyar.
• İzleyici açısından, üçüncü bir taraf olan tiyatronun çantasını istediği gibi karıştırmasına, parayı almasına ve bileti koymasına şahit olmak zorunda kalır.
• Satıcı açısından, üçüncü bir taraf olan tiyatronun izni olmadan gişedeki bilet ve nakdin değerini değiştirmesine şahit olmak zorunda kalır.
• Anlaşılabilir kod, işleminin beklentilerimizi çok fazla aşmadığı bir kodu ifade eder; yukarıdaki tiyatro, beklentilerimizi aşmaktadır.
  • İzleyici, kendi çantasından parayı çıkarıp satıcıya ödeyerek bileti almalıdır.
  • Satıcı, gişede bulunan bileti doğrudan alıp izleyiciye vermeli ve izleyiciden parayı alıp gişede saklamalıdır.
• Ayrıca, enter() yöntemini anlamak için birçok ayrıntıyı hatırlamak zorundayız.
  • Audience, Bag'e sahiptir.
  • Bag'in içinde nakit ve bilet vardır.
  • TiketSellet, TicketOffice'ten bilet satar ve TicketOffice'in içinde para ve bilet bulunur.

Değişime Duyarlı Kod

enter() yöntemi iki koşulu varsayar.

• İzleyici, nakit ve davetiyeyi saklamak için her zaman bir çanta taşır.
• Satıcı, bileti yalnızca gişeden satar.

Peki ya aşağıdaki durumlar?

• İzleyicinin çantası olmayabilir.
• İzleyici, nakit yerine kredi kartı kullanabilir.
• Satıcı, gişeden dışarıda bilet satabilir.

Örneğin, ilk gereksinimi karşılamak için Audience'ın Bag nesnesini kaldırmalı ve bununla bağlantılı Theater sınıfının enter() yöntemini düzeltmeliyiz. Bunun nedeni, Theater sınıfının izleyicinin bir çanta taşıdığı ve satıcının yalnızca gişeden bilet sattığı konusunda aşırı ayrıntılı bir bilgiye dayanmasıdır. Bu ayrıntılardan biri bile değişirse, ilgili sınıfı ve ona bağımlı sınıfları (örneğin Theater) değiştirmemiz gerekir.

Bu, nesneler arasındaki bağımlılık ile ilgili bir sorundur ve bağımlılık, değişikliklere ilişkin bir etkiyi ima eder. Ancak nesne yönelimli tasarım, birbirine bağımlı olarak işbirliği yapan nesnelerin bir topluluğunu oluşturmayı amaçladığı için, bağımlılığı tamamen ortadan kaldırmak yerine, uygulamanın işlevselliğini sağlamak için gerekenen az bağımlılığı korumakve gereksiz bağımlılıkları ortadan kaldırmak gerekir.

Nesneler arasındaki aşırı bağımlılık durumu, birleşmeolarak adlandırılır; iki nesne arasındaki birleşme ne kadar yüksekse, birlikte değişme olasılıkları da o kadar artar. Bu nedenle, tasarımın amacı, nesneler arasındaki birleşmeyi azaltarak değişiklik yapmayı kolaylaştıran bir tasarım oluşturmaktır.

Tasarımı Geliştirmek

İzleyicinin bir çantaya sahip olması ve satıcının gişeden bilet satması gerçeği, Theater tarafından bilinmesi gerekmez. Theater yalnızca izleyicinin tiyatroya girmesini ister. Bu nedenle, izleyici kendi çantasındaki nakit ve davetiyeyi işlesin ve satıcı da kendi gişesinin biletlerini ve satış fiyatını işlesin; yani onlara özerk bir varlık gibi davranın.

Özerkliği Artırın

Sadece yakından ilişkili işleri yapan ve ilişkisiz işleri başka nesnelere devreden nesneler, yüksek birleşmeye sahiptir. Kendi verilerini kendi başına işleyen özerk nesneler oluşturursak, birleşmeyi azaltır ve birleşmeyi artırabiliriz.

Prosedürel ve Nesne Yönelimli

• Prosedürel
  • Theater'ın enter() yöntemi bir işlemdir; Audience, TicketSeller, Bag ve TicketOffice verileridir.
  • İşlemleri ve verileri ayrı modüllere yerleştirme yöntemi, prosedürel programlama olarak adlandırılır.
  • Kodumuzda sezgiye aykırı birçok şey vardır. (örneğin, izleyici kendi parasını ve davetiyesini yönetir.)
  • Veri değişikliklerinin etkisini daraltmak zordur.
  • Sorumluluklar merkezi olarak yönetilir. (Theater her şeyi yönetir)
• Nesne Yönelimli
  • Verileri ve işlemleri aynı modülde bulundurma yöntemi, nesne yönelimli programlama olarak adlandırılır.
  • Sezgiye uygun kod yazabiliriz.
  • Veri değişikliklerinin etkisini, kapsülleme yoluyla etkili bir şekilde daraltabiliriz.
  • Her nesne kendini yönetir.
  • 
    

Uygulama kodu: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step02

Daha İyi Hale Getirebiliriz.

• Audience sınıfının Bag sınıfı hala Audience sınıfı tarafından taşınan pasif bir varlıktır; bu nedenle Bag sınıfını özerk bir nesne haline getirmemiz gerekir.
• TicketSeller sınıfının TicketOffice'i de TicketSeller tarafından istediği gibi yönetiliyor. TicketOffice'i özerk bir nesne haline getirmemiz gerekiyor.
  • Ancak değişiklikten sonra TicketOffice, Audience ile ek birleşme yarattı.
  • Bu nedenle, tasarımda ödünleşimler göz önünde bulundurulmalıdır. Bu durumda, Audience ile birleşmeyi azaltmak için TicketOffice'i biraz pasif bir nesne yapmaya karar verebiliriz.

Uygulama kodu: https://github.com/Java-Crew/objects-study/tree/jayon/src/main/java/chapter01/step03

Evet, Yalan!

• Gerçek dünyada, pasif bir varlık olsa bile, nesne yönelimli dünyaya girdiğinde her şey aktif ve özerk bir varlık haline gelir.
• Pasif nesneleri, gülümseyen, konuşan ve öfkelenen varlıklarmış gibi düşünmek için kişileştirmeyi kullanmak iyidir.

Nesne Yönelimli Tasarım

Tasarım Neden Gerekli?

• Tasarım, kodu yerleştirmektir.
• İyi bir tasarım, bugün ihtiyaç duyulan işlevleri tam olarak yerine getirirken yarının değişikliklerini sorunsuz bir şekilde kabul eden bir tasarımdır.

Nesne Yönelimli Tasarım

• Değiştirilebilir kod, anlaşılması kolay koddur.
• Nesne yönelimli paradigma, dünyayı gördüğümüz şekilde kod yazmamıza yardımcı olur.
• Nesne, kendi verilerinden sorumlu özerk bir varlıktır.
• Mükemmel bir nesne yönelimli tasarım, işbirliği yapan nesneler arasındaki bağımlılıkları uygun şekilde yöneten bir tasarımdır.

Kaynaklar

• Nesneler