Sağlam denilmesi iltifattır. Kelime, güvenilirlik ve saygınlık gibi olumlu kavramları taşır. Hepimiz bir olmayı amaçlamalıyız.

Bir yazılım mühendisiyseniz veya olmak istiyorsanız, yolunuza rehberlik edecek bir dizi SOLID ilkesi olduğu için şanslısınız.

SOLID, yazılım mühendisliği mesleğinde bir kısaltmadır. Anlamı:

• Tek Sorumluluk ilkesi
• O kalem kapalı prensibi
• L iskov İkame ilkesi
• Arayüz ayrımı ilkesi
• Bağımlılık ters çevirme ilkesi

Bu ilkelere daha ayrıntılı olarak bakalım.

Tek Sorumluluk

Her sınıfın tek bir sorumluluğu olmalıdır.

An , e-posta göndermekle ve sipariş durumunu güncellemekle EmailServicedeğil, yalnızca e-posta göndermekle ilgilenmelidir .

Bir Carsınıf sadece arabalarla ilgili olmalı, diğer motorlu araçlarla ilgili olmamalıdır. Elektrikli bir arabayı tarif etmemiz gerekirse, o zaman gibi bir alt sınıf , elektrikli ve benzinli araba özelliklerine ElectricCarsahip aşırı yüklemeden daha uygundur .Car

Aç-kapa prensibi

Bir modül genişletme için açık, değişiklik için kapalı olmalıdır

Yeni gönderilen e-postaya geri çağırma özelliği ekleyen EmailServicebir özellik ile genişletilebilir .RecallableEmailService

içini ElectricCardeğiştirmeden elektrikli özellikler ekler Car.

Liskov ikamesi

Alt sınıflar, temel sınıflarının yerine kullanılabilir olmalıdır

Nesne yönelimli tasarım bağlamında, bir temel sınıfın örneğini kabul eden bir sınıf veya yöntem, kendi alt sınıfının herhangi bir örneğini alabilmelidir.

An OrderService, EmailServiceörneğin gerçek sınıfının EmailServicekendisi veyaRecallableEmailService

An , elektrikli veya benzinli bir arabayı temsil edip etmediğini bilmeden bir rota belirlemek için UrbanTripPlannerherhangi bir örneğini kullanabilmelidir .Car

Arayüz ayrımı

İstemciye özel birçok arayüz, genel amaçlı bir arayüzden daha iyidir

An'a OrderServicegerek yok recallEmail(...). EmailServiceBu nedenle, yalnızca e-posta göndermeye bağlıdır , değilRecallableEmailService

Benzer şekilde an, an yöntemine UrbanTripPlannerihtiyaç duymaz . Yalnızca tarafından sağlanan arabirime bağlıdırrecharge(...)EletricCarCar

Bağımlılık ters çevirme

Soyutlamalara bağlıdır. Somutluklara güvenmeyin.

Prosedürel bağımlılık mekanizması tepeden başlar, kademeli olarak genişler ve somut uygulama detaylarına bağlıdır .

Nesne yönelimli programlamada bağımlılık tersine çevrilir . Bağımlılıkların çoğu soyutlamalar üzerine olmalıdır. Ve uygulamanın olduğu yerde, soyutlama ile ilişkisi tersine döner . Doğrudan bağımlı olmak yerine, uygulama artık soyutlamaya bağlıdır.

An , IMAP veya POP uygulaması OrderServicetarafından sağlanan arabirime bağlıdır .EmailService

An , Tesla veya Toyota uygulamasına değil, UrbanTripPlannertarafından sağlanan arayüze bağlıdır.Car

Çözüm

SOLID kısaltmasının kökenini inceledik ve her birine 2 nesne yönelimli tasarım kullanım durumuyla ayrıntılı olarak baktık.

Geçmişte bu ilkelerden bazılarını bilmeden izlemiş olabilirsiniz, çünkü bunlar iyi uygulamalardır. Kapsülleme, bence, Aç-kapa ilkesini takip ediyor .

Siz de bazılarını uygulamış olabilirsiniz çünkü işler böyledir. Sözdizimsel olarak, bir ElectricCarnesne her zaman bir parametre yerine geçebilir Car, dolayısıyla Liskov ikame ilkesi izlenir . Dependency Injection'ı kullandıysanız, Dependency Inversion ilkesini zaten takip etmiş olursunuz .

Diğer ilkeler biraz düşünmeyi gerektirir. Tek Sorumluluk ilkesi , yöntemi/sınıfı/modülü temiz ve yalın tutmak için iyi bir OO modeline ihtiyaç duyar. Arayüz Ayrımı ilkesini takip ederken ayrımın ne kadar derin olması gerektiğini belirlemek için sağduyuya ihtiyacınız olabilir .

Referanslar

• Tasarım İlkeleri ve Tasarım Modelleri belgesi
• OOD makalesinin ilkeleri
• Temiz Mimari: Bir Zanaatkarın Yazılım Yapısı ve Tasarımı Kılavuzu
• https://en.wikipedia.org/wiki/SOLID

Bu dizideki diğer makaleler:

• SOLID geliştiricisi olmak
• SOLID Eylem Halinde — Tek Sorumluluk İlkesi
• SOLID in Action — Açık-kapalı prensibi
• SOLID İş Başında — Liskov İkame ilkesi: planlı
• SOLID Eylemde — Arayüz Ayrımı ilkesi: planlandı
• SOLID Eylemde — Bağımlılığı Tersine Çevirme ilkesi: planlı

Teşekkürler.