Yazılım programlamada biraz deneyime sahip olan herkes, kariyer yoluna dayalı yargı parametrelerini kullanarak başkaları tarafından yazılan yazılım kodunu yargılar.
Profesyonel kariyerim boyunca birçok geliştirici tanıdım ve binlerce satır kod gördüm ve bir geliştiricinin becerisini değerlendirmem gerektiğinde esas olarak iki faktöre bakıyorum:
Neyse ki, kodlamada daha iyi olmayı kolaylaştıran bazı temel ilkeler veya ilkeler var.
SOLID kısaltması şu anlama gelir:
S: tek sorumluluk ilkesi
O: açık-kapalı prensibi
L: Liskov ikame ilkesi
I: Arayüz ayırma prensibi
D: Bağımlılıkları Tersine Çevirme İlkesi
İlk SOLID prensibine, yani
Bir sınıfın (veya modülün) değişmesi, gelişmesi için yalnızca bir nedeni olmalıdır.
Kavramın kendisi çok basittir, ancak bu basitliği elde etmek için uygulama yolu çok karmaşık olabilir. Bir sınıfın değişmesi için yalnızca bir nedeni olmalıdır.
Ama neden?
Değişmek için tek bir nedene sahip olmak neden bu kadar önemli?
Örneğin, değiştirmek için iki farklı neden varsa, iki farklı ekibin aynı kod üzerinde iki farklı nedenle çalışabileceği düşünülebilir. Her birinin, derlenmiş bir dil (C ++, C # veya Java gibi) olması durumunda, diğer ekiplerle veya uygulamanın diğer bölümleriyle uyumsuz modüllere yol açabilecek kendi çözümlerini uygulaması gerekecektir.
Başka bir örnek, yorumlanmış bir dil kullanıyorsanız, aynı sınıfı veya modülü farklı nedenlerle yeniden test etmeniz gerekebilir. Bu, kalite kontrol için daha fazla çalışma, zaman ve çaba anlamına gelir.
Bir sınıf veya modülün sahip olması gereken bir özelliği belirlemek, testleri çalıştırmak için bir kontrol listesine bakmaktan çok daha karmaşıktır.
Ama daha az teknik bir bakış açısıyla düşünmeye çalışalım, yani sınıfımızın veya modülümüzün kullanıcısını, yani onu kimin kullanacağını analiz etmeye çalışalım. Her zaman aklımızda tutmamız gereken temel bir husus, geliştirdiğimiz uygulamanın veya sistemin belirli bir modül tarafından hizmet verilen kullanıcılarının modifikasyon talep eden kişiler olacağı gerçeğidir. Hizmet verenler sınıfı veya modülü değiştirmelerini isteyeceklerdir.
Bazı modül örnekleri ve kullanımları:
Dolayısıyla, ilk adım modül ile muhatap rolü üstlenen aktörleri veya aktörü aramaksa, bireyleri tüm rollerle ilişkilendirmek zor olabilir. Küçük bir şirkette bir kişi birden fazla rol oynayabilirken, büyük bir şirkette tek bir role sahip birden fazla kişi olabilir.
İnsanlardan veya kullanıcılardan ziyade rolleri belirlemek daha mantıklı görünüyor.
Sonra:
Hadi bazı örneklere bakalım
Bir kitap kavramını ve işlevselliğini özetleyen bir Kitap sınıfımız olduğunu varsayalım.
sınıf Kitap {
function getTitle () {
“Büyük Bir Kitap” ı iade edin;
}
function getAuthor () {
“Alessandro Baricco” ya dönüş;
}
function nextpage () {
// sonraki Sayfa
}
function printCurrentPage () {
echo “mevcut sayfanın içeriği”;
}
}
Bu çok normal bir sınıftır. Bir kitabımız var ve sınıf bize başlığı verebilir, bize yazarı verebilirler ve devam edebilirler. Son olarak, mevcut sayfayı ekrana yazdırabilir.
Ancak küçük bir sorun var.
Kitap nesnesinin yönetimine dahil olan aktörler hakkında düşündüğünüzde, bunlar kim olabilir?
Burada iki farklı oyuncuyu rahatlıkla düşünebiliriz: Kitap yönetimi (olarak kütüphaneci) Ve Veri gönderme mekanizması (kullanıcıya nasıl içerik sunmak istediğimiz gibi: ekran üzeri, grafik kullanıcı arayüzü, salt metin kullanıcı arayüzü, belki baskı).
Bu nedenle sınıfla etkileşime giren çok farklı iki aktörümüz var.
Özetle, bu sınıf aşağıdakiler arasında bir karışım oluşturur:
tek sorumluluk ilkesini (SRP) ihlal ettiği için bu bir sorun olabilir.
Tek sorumluluk ilkesine saygı duymak için bu kuralları nasıl değiştirebiliriz, nasıl geliştirebiliriz?
Aşağıdaki koda bir göz atın:
sınıf Kitap {
function getTitle () {
"Oceano Mare" dönüş;
}
function getAuthor () {
“Alessandro Baricco” ya dönüş;
}
function dönüş sayfası () {
// sonraki Sayfa
}
function getCurrentPage () {
echo “mevcut sayfanın içeriği”;
}
}
arayüzü Yazıcı {
function printPage ($ sayfa);
}
StampaLibro sınıfı Yazıcıyı uygular {
function printPages ($ page) {
echo $ sayfa;
}
}
sınıf HtmlPrinter Yazıcıyı uygular {
function printPages ($ page) {
Eko ' '. $ sayfa. ' ';
}
}
Bu çok basit örnek, sunumun iş mantığından nasıl ayrılacağını gösterir ve SRP ile uyumlu olarak projemizin esnekliğinde büyük avantajlar sunar.
Başka bir örneğe bakalım:
Yukarıdakine benzer bir örnek, bir nesnenin kendisini sunumdan kaydedip geri alabildiği zamandır.
sınıf Kitap {
function getTitle () {
"Oceano Mare" dönüş;
}
function getAuthor () {
“Alessandro Baricco” ya dönüş;
}
function dönüş sayfası () {
// sonraki Sayfa
}
function getCurrentPage () {
"geçerli sayfanın içeriği" döndürülür;
}
function kaydet () {
$ dosyaadı = '/ belgeler /'. $ this-> getTitolo (). '-'. $ this-> getAuthor ();
file_put_contents ($ dosyaadı, serileştirme ($ this));
}
}
Daha önce olduğu gibi, burada da farklı aktörleri belirleyebiliriz. Kitap yönetimi (olarak kütüphaneci) Ve Kalıcılık. Sayfadan sayfaya gitme şeklimizi ne zaman değiştirmek istersek, bu sınıfı değiştirmemiz gerekir. Değişim için birkaç nedenimiz olabilir.
sınıf Kitap {
function getTitle () {
"Oceano Mare" dönüş;
}
function getAuthor () {
“Alessandro Baricco” ya dönüş;
}
function dönüş sayfası () {
// sonraki Sayfa
}
function getCurrentPage () {
"geçerli sayfanın içeriği" döndürülür;
}
}
sınıf SimpleFilePersistence {
function save (Book $ book) {
$ dosyaadı = '/ belgeler /'. $ kitap-> getTitle (). '-'. $ kitap-> getAuthor ();
file_put_contents ($ dosyaadı, serileştirme ($ kitap));
}
}
Kalıcılık operasyonunu başka bir sınıfa taşımak sorumlulukları açıkça ayıracak ve Kitap sınıfımızı etkilemeden kalıcılık yöntemlerini değiş tokuş etmekte özgür olacağız. Örneğin, bir DatabasePersistence sınıfının uygulanması önemsiz olacaktır ve kitap işlemleri etrafında oluşturulan iş mantığımız değişmeyecektir.
İkinci prensibi Açık / Kapalı okumaya devam edin ->
Ercole Palmeri
Boyama yoluyla ince motor becerilerini geliştirmek, çocukları yazma gibi daha karmaşık becerilere hazırlar. Renklendirmek…
Denizcilik sektörü, 150 milyarlık bir pazara doğru yol alan gerçek bir küresel ekonomik güçtür...
Geçen Pazartesi Financial Times, OpenAI ile bir anlaşma yaptığını duyurdu. FT, birinci sınıf gazeteciliğine lisans veriyor…
Milyonlarca insan aylık abonelik ücreti ödeyerek akış hizmetleri için ödeme yapıyor. Yaygın kanaat şu ki…
