Giriş: Modülerliğin Peşinde - İki Temel İlke

Yazılım sistemleri büyüdükçe ve karmaşıklaştıkça, onları yönetilebilir, anlaşılabilir ve sürdürülebilir kılmak en büyük zorluklardan biri haline gelir. Bu zorluğun üstesinden gelmek için yazılım mühendisliği topluluğu, zaman içinde test edilmiş ve kanıtlanmış bir dizi tasarım prensibi geliştirmiştir. Bu prensipler arasında, sistemin farklı işlevsel veya teknik parçalarını birbirinden ayırarak modülerliği artırmayı hedefleyen iki ilke özellikle öne çıkar: Sorumlulukların Ayrılması (Separation of Concerns - SoC) ve Tek Sorumluluk Prensibi (Single Responsibility Principle - SRP).

Bu iki prensip, isimlerinden de anlaşılacağı gibi, "sorumluluk" kavramı etrafında döner ve genellikle birlikte anılırlar. Her ikisi de kodun daha temiz, daha odaklanmış ve bakımı daha kolay olmasına katkıda bulunur. Ancak, sıkça karıştırılmalarına rağmen, aynı şey değillerdir ve farklı soyutlama seviyelerinde veya farklı kapsamlarda faaliyet gösterirler.

Sorumlulukların Ayrılması (SoC): Daha genel ve daha üst düzey bir mimari prensiptir. Bir yazılım sistemini, her biri belirli bir "ilgi alanı" veya "endişe" (concern) ile ilgilenen, farklı, örtüşmeyen bölümlere veya katmanlara ayırma fikridir. Bu "ilgi alanları" genellikle daha geniştir; örneğin, kullanıcı arayüzü, iş mantığı, veri erişimi, günlükleme gibi. SoC, sistemin makro düzeydeki organizasyonuyla ilgilenir.

Tek Sorumluluk Prensibi (SRP): Daha spesifik ve genellikle sınıf veya modül düzeyinde uygulanan bir tasarım prensibidir. SOLID prensiplerinin 'S'sini oluşturur ve bir sınıfın (veya modülün) değişmek için yalnızca bir nedeni olması gerektiğini belirtir. Yani, bir sınıfın yalnızca tek bir sorumluluğu veya tek bir görevi olmalıdır. SRP, sistemin mikro düzeydeki yapı taşlarının tasarımıyla ilgilenir.

Bu iki prensip arasındaki ilişkiyi bir şehir planlaması analojisiyle düşünebiliriz:

SoC: Şehri farklı bölgelere ayırmaya benzer: yerleşim alanı, sanayi bölgesi, ticaret merkezi, parklar ve yeşil alanlar. Her bölgenin genel bir amacı ve işlevi vardır (Konut, Üretim, Ticaret, Rekreasyon). Bu, şehrin genel düzenini ve organizasyonunu sağlar.

SRP: Belirli bir bölge içindeki tek bir binanın tasarımına benzer. Örneğin, yerleşim alanındaki bir apartmanın sadece konut sağlama sorumluluğu olmalıdır. Aynı binanın hem konut hem de ağır sanayi fabrikası olarak hizmet vermeye çalışması SRP ihlali olurdu. Binanın tek bir amacı olmalı ve değişmek için tek bir nedeni (örneğin, konut standartlarındaki değişiklikler) bulunmalıdır.

Görüldüğü gibi, SoC genel yapıyı kurarken, SRP bu yapının içindeki daha küçük birimlerin nasıl tasarlanması gerektiğine odaklanır. İyi bir SoC uygulaması, genellikle SRP'ye uygun birimler oluşturmayı kolaylaştırır ve teşvik eder.

Bu kapsamlı makalede, SoC ve SRP arasındaki bu önemli ilişkiyi ve temel farklılıkları tüm yönleriyle ele alacağız. Her iki prensibin de tanımlarını, motivasyonlarını ve faydalarını ayrı ayrı inceleyeceğiz. Ardından, aralarındaki temel farkları (kapsam, soyutlama seviyesi, odak noktası) netleştirecek ve birbirlerini nasıl tamamladıklarını göstereceğiz. SoC'nin SRP'yi nasıl kapsadığını veya içerdiğini, ancak SRP'nin tek başına SoC'yi garanti etmediğini tartışacağız. Pratik kod örnekleriyle her iki prensibin nasıl uygulandığını ve ihlal edildiğinde ortaya çıkan sorunları göstereceğiz. Son olarak, bu iki prensibi birlikte etkili bir şekilde kullanarak nasıl daha modüler, bakımı kolay ve sağlam yazılım sistemleri tasarlayabileceğimize dair çıkarımlar yapacağız. Amacımız, bu iki temel tasarım ilkesi arasındaki nüansları aydınlatmak ve geliştiricilere sorumlulukları hem makro hem de mikro düzeyde doğru bir şekilde yönetmeleri için gerekli anlayışı sağlamaktır.

Bölüm 1: Sorumlulukların Ayrılması (SoC) - Büyük Resme Odaklanmak

SoC, yazılım mimarisinin temel taşlarından biridir ve sistemi daha yönetilebilir parçalara ayırmayı hedefler.

Tanım ve Kapsam:

SoC, bir bilgisayar programını veya sistemini, her biri belirli bir "ilgi alanı" (concern) ile ilgilenen farklı ve mümkün olduğunca bağımsız bölümlere ayırma prensibidir. Buradaki "ilgi alanı" veya "sorumluluk" genellikle geniş bir kavramdır ve sistemin farklı yönlerini veya işlevsel/teknik alanlarını temsil eder.

SoC'nin Odak Noktaları (Yaygın "Concern" Örnekleri):

Teknik Katmanlar:

Sunum (Presentation): Kullanıcı arayüzü, girdi/çıktı işlemleri.

İş Mantığı (Business Logic / Domain): Uygulamanın temel kuralları ve süreçleri.

Veri Erişimi (Data Access / Persistence): Verilerin saklanması ve alınması.

Uygulama (Application): Kullanım senaryoları (use cases), iş akışı koordinasyonu.

Altyapı (Infrastructure): Veritabanı bağlantısı, ağ iletişimi, günlükleme, güvenlik gibi teknik detaylar.

İşlevsel Alanlar (Features / Modules / Domains):

Kullanıcı Yönetimi

Ürün Yönetimi

Sipariş Yönetimi

Ödeme İşlemleri

Raporlama

Çapraz Kesen İlgiler (Cross-Cutting Concerns):

Günlükleme (Logging)

Kimlik Doğrulama / Yetkilendirme (Authentication / Authorization)

Önbellekleme (Caching)

İşlem Yönetimi (Transaction Management)

SoC, bu farklı ilgi alanlarının kodlarının birbirine karışmasını engellemeyi amaçlar. Örneğin, SQL sorgularının kullanıcı arayüzü kodunun içinde yer almaması veya iş kurallarının doğrudan veritabanı teknolojisine bağımlı olmaması gibi.

SoC'nin Hedefleri:

Modülerlik: Sistemi bağımsız veya yarı bağımsız modüllere ayırmak.

Düşük Bağımlılık (Low Coupling): Farklı bölümler arasındaki bağımlılığı azaltmak.

Yüksek Bağlılık (High Cohesion): Her bölümün kendi içinde tutarlı ve tek bir amaca odaklanmış olmasını sağlamak (örneğin, tüm veri erişim kodunun DAL'da toplanması).

Anlaşılabilirlik: Sistemin genel yapısını ve farklı bölümlerin rollerini anlamayı kolaylaştırmak.

Bakım Kolaylığı: Bir bölümde yapılan değişikliğin diğerlerini minimum düzeyde etkilemesini sağlamak.

Yeniden Kullanılabilirlik: Belirli bölümlerin (örneğin, bir veri erişim katmanı) başka projelerde potansiyel olarak yeniden kullanılabilmesi.

SoC Uygulama Yöntemleri:

SoC genellikle şu gibi mimari yaklaşımlar ve tekniklerle hayata geçirilir:

Katmanlı Mimari (Layered Architecture)

Model-View-Controller (MVC), MVP, MVVM gibi sunum desenleri

Modüler Monolitler

Mikroservis Mimarisi

Aspect-Oriented Programming (AOP) (Çapraz kesen ilgiler için)

SoC, sistemin makro düzeydeki organizasyonuna odaklanır ve farklı ilgi alanlarının nasıl ayrılacağıyla ilgilenir.

Bölüm 2: Tek Sorumluluk Prensibi (SRP) - Mikro Düzeyde Odaklanma

SRP, Robert C. Martin tarafından SOLID prensipleri kapsamında tanımlanan ve daha çok sınıf veya modül düzeyinde uygulanan bir ilkedir.

Tanım ve Kapsam:

SRP'nin en yaygın ifadesi şudur:

"A class should have only one reason to change."

(Bir sınıfın değişmek için yalnızca bir nedeni olmalıdır.)

Bu tanım, ilk bakışta biraz soyut gelebilir. Daha pratik bir yorumu ise şudur: Bir sınıfın yalnızca tek bir sorumluluğu veya görevi olmalıdır.

"Sorumluluk" ve "Değişim Nedeni" Ne Anlama Gelir?

Sorumluluk: SRP bağlamında sorumluluk, sınıfın yerine getirdiği belirli bir işlev veya üstlendiği roldür.

Değişim Nedeni: Bu, sorumluluğun daha somut bir ifadesidir. Bir sınıfın kodunun değiştirilmesini gerektirebilecek farklı dış etkenler veya paydaşlar (örneğin, farklı iş kuralları, farklı veri formatları, farklı raporlama gereksinimleri) düşünülür. Eğer bir sınıfın kodunu değiştirmek için birden fazla farklı neden (farklı aktörlerden veya farklı gereksinim alanlarından kaynaklanan) varsa, o sınıf muhtemelen birden fazla sorumluluğu üstlenmiştir ve SRP'yi ihlal ediyordur.

SRP'nin Odak Noktası:

SRP, bir sınıfın veya modülün içsel bağlılığına (cohesion) odaklanır. Bir sınıfın içindeki metotlar ve veriler ne kadar yakından ilişkili ve tek bir amaca hizmet ediyor? SRP, yüksek bağlılığa sahip sınıflar oluşturmayı hedefler. Bir sınıf birden fazla, birbiriyle ilgisiz sorumluluğu karıştırdığında, bağlılığı düşük olur.

SRP İhlali Örneği:

// SRP İhlali: Hem kullanıcı verisini yönetiyor hem de rapor formatlıyor
class UserProcessor {
private Database db;

public User findUser(int userId) {
    // ... veritabanından kullanıcı bulma mantığı ... (Veri Erişim Sorumluluğu)
    return db.queryUser(userId);
}

public void saveUser(User user) {
    // ... kullanıcıyı veritabanına kaydetme mantığı ... (Veri Erişim Sorumluluğu)
    db.save(user);
}

// !!! Farklı Sorumluluk !!!
public String generateUserReport(User user) {
    // ... kullanıcı bilgilerini alıp bir HTML raporu formatlama mantığı ... (Raporlama/Sunum Sorumluluğu)
    String report = "User Report";
    report += "Name: " + user.getName() + "";
    report += "Email: " + user.getEmail() + "";
    report += "";
    return report;
}



    Enter fullscreen mode
    


    Exit fullscreen mode
    




}Bu UserProcessor sınıfı SRP'yi ihlal eder çünkü değişmek için en az iki nedeni vardır:Veritabanı erişim mantığı değişirse (farklı bir ORM kullanmak, tablo yapısı değişmek vb.).Rapor formatlama mantığı değişirse (HTML yerine PDF istenmesi, rapora yeni alanlar eklenmesi vb.).Bu iki sorumluluk (veri yönetimi ve raporlama) birbirinden farklıdır ve farklı nedenlerle değişebilirler.SRP Uygulanmış Örnek:// Sorumluluk 1: Kullanıcı Veri Yönetimi
class UserRepository {
    private Database db;
    public User findUser(int userId) { /* ... / return db.queryUser(userId); }
    public void saveUser(User user) { / ... */ db.save(user); }
}// Sorumluluk 2: Kullanıcı Raporlama
class UserReporter {
    public String generateHtmlReport(User user) {
        // Sadece rapor formatlama ile ilgilenir
        String report = "...";
        // ... formatlama ...
        return report;
    }
    // Belki başka formatlar için metotlar: generatePdfReport(User user)...
}// Kullanım (Koordinasyon başka bir yerde yapılır)
public class UserManagementService {
    private UserRepository repository;
    private UserReporter reporter;
    // ... DI ile inject edilir ...
public String getUserReportAsHtml(int userId) {
    User user = repository.findUser(userId);
    if (user != null) {
        return reporter.generateHtmlReport(user);
    }
    return null; // Veya hata yönetimi
}



    Enter fullscreen mode
    


    Exit fullscreen mode
    




}Bu ayrımda, UserRepository sadece veri erişimiyle, UserReporter ise sadece raporlamayla ilgilenir. Her birinin değişmek için tek bir nedeni vardır.SRP'nin Hedefleri:Yüksek Bağlılık (High Cohesion): Sınıfların tek bir amaca odaklanmasını sağlamak.Düşük Bağımlılık (Low Coupling - Dolaylı Etki): Bir sorumluluktaki değişikliklerin, ilgisiz sorumlulukları barındıran diğer sınıfları etkileme riskini azaltmak.Anlaşılabilirlik: Tek bir iş yapan sınıfları anlamak daha kolaydır.Test Edilebilirlik: Tek bir sorumluluğu olan sınıfları izole edip test etmek daha basittir.Yeniden Kullanılabilirlik: Odaklanmış sınıfların başka bağlamlarda yeniden kullanılma olasılığı daha yüksektir.SRP, sistemin mikro düzeydeki yapı taşlarının (sınıflar, modüller) nasıl tasarlanması gerektiğine odaklanır ve her birimin tek bir göreve sahip olmasını hedefler.Bölüm 3: SoC vs SRP - Temel FarklılıklarSoC ve SRP'nin tanımlarını ve hedeflerini inceledikten sonra, aralarındaki temel farklılıkları netleştirebiliriz:Kapsam ve Soyutlama Seviyesi:SoC: Daha geniş kapsamlı ve yüksek seviyeli (makro) bir prensiptir. Tüm sistemin veya büyük alt sistemlerin mimari organizasyonuyla ilgilenir. "İlgi alanları" (concerns) genellikle daha geniştir (UI, Logic, Data, Logging vb.).SRP: Daha dar kapsamlı ve düşük seviyeli (mikro) bir prensiptir. Tek tek sınıfların veya modüllerin iç tasarımıyla ilgilenir. "Sorumluluk" genellikle daha spesifik bir görevi ifade eder.Odak Noktası:SoC: Sistemin farklı bölümleri arasındaki ayrışmaya odaklanır. Katmanların veya modüllerin sınırlarını ve aralarındaki etkileşimleri tanımlar. Temel hedefi, farklı ilgi alanlarının birbirine karışmasını önlemektir.SRP: Tek bir sınıfın veya modülün içsel tutarlılığına ve odaklanmasına odaklanır. Bir birimin birden fazla, ilgisiz görevi üstlenmesini engellemeyi hedefler. Temel hedefi, bir birimin değişmek için tek bir nedeni olmasını sağlamaktır.Uygulama Alanı:SoC: Genellikle mimari desenler (Katmanlı Mimari, Mikroservisler), AOP gibi tekniklerle uygulanır.SRP: Genellikle sınıf tasarımı, refaktöriyon (örneğin, bir sınıfı birden fazla sınıfa bölme) ve iyi nesne yönelimli pratiklerle uygulanır.Hedeflenen Problem:SoC: Farklı teknik veya işlevsel alanların birbirine bağımlı hale gelerek sistemin genelinde katılık ve karmaşıklık yaratması problemini çözer.SRP: Bir sınıfın çok fazla iş yaparak düşük bağlılığa (low cohesion) sahip olması ve farklı nedenlerle sürekli değişmek zorunda kalması problemini çözer.İlişki:SoC, SRP'yi İçerebilir/Teşvik Eder: İyi bir SoC uygulaması (örneğin, katmanlara ayırma), her katmanın kendi sorumluluğuna odaklanmasını sağlar. Bu katmanlar içindeki sınıfların da SRP'ye uygun olarak tasarlanması genellikle doğal bir sonuçtur veya hedeflenir. Örneğin, Veri Erişim Katmanı (SoC) içindeki her Repository sınıfının sadece belirli bir varlığın veri erişimiyle ilgilenmesi (SRP) beklenir.SRP, SoC'yi Garanti Etmez: Bir sistemdeki tüm sınıflar SRP'ye mükemmel bir şekilde uyuyor olabilir, ancak sistemin genel mimarisi (SoC) hala kötü olabilir. Örneğin, tüm sınıflar tek sorumluluğa sahip olsa bile, veri erişim mantığı sunum katmanındaki sınıfların içine dağılmış olabilir. Bu durumda SRP uygulanmış ama SoC ihlal edilmiş olur.Özetle, SoC sistemi büyük parçalara ayırırken, SRP bu parçaların içindeki daha küçük yapı taşlarının nasıl olması gerektiğiyle ilgilenir. SoC ormanı düzenlerken, SRP ağaçların sağlıklı büyümesini sağlar.Bölüm 4: Birbirlerini Nasıl Tamamlarlar? Sinerjik İlişkiSoC ve SRP, farklı seviyelerde çalışsalar da, birbirlerini mükemmel bir şekilde tamamlarlar ve birlikte uygulandıklarında en iyi sonuçları verirler.SoC Zemin Hazırlar: SoC, sistemi mantıksal bölümlere ayırarak daha yönetilebilir bir yapı oluşturur. Bu yapı, SRP'nin uygulanması için uygun bir zemin hazırlar. Örneğin, İş Mantığı Katmanı tanımlandığında, bu katman içindeki sınıfların sadece iş kurallarıyla ilgilenmesi gerektiği (ve örneğin UI veya veri erişimiyle ilgilenmemesi gerektiği) daha belirgin hale gelir.SRP Detayları İyileştirir: SoC ile ayrılan her bölümün (katman veya modül) içindeki sınıflar SRP'ye göre tasarlandığında, bu bölümlerin kendi iç kalitesi artar. Yüksek bağlılığa sahip, odaklanmış sınıflar, ilgili oldukları SoC bölümünün sorumluluğunu daha etkin bir şekilde yerine getirir.Tutarlılık Sağlarlar: Hem makro (SoC) hem de mikro (SRP) düzeyde sorumlulukların net bir şekilde ayrılması, sistem genelinde tutarlı ve öngörülebilir bir tasarım oluşturur.Bakım ve Değişikliği Kolaylaştırırlar: SoC, değişikliğin hangi bölümde yapılacağını belirlemeye yardımcı olurken, SRP bu bölüm içindeki hangi spesifik sınıfın değiştirilmesi gerektiğini netleştirir. Bu, değişikliklerin etki alanını daraltır ve süreci hızlandırır.Örnek Senaryo:Bir e-ticaret uygulamasını düşünelim:SoC Uygulaması: Sistemi Katmanlı Mimari ile ayırırız:Presentation Layer (Web Controller'ları, API Endpoint'leri)Business Logic Layer (Servisler, Domain Nesneleri -örn: ProductService, OrderService)Data Access Layer (Repository'ler - örn: ProductRepository, OrderRepository)SRP Uygulaması (BLL içinde):OrderService: Sadece sipariş oluşturma, güncelleme, iptal etme gibi sipariş iş akışı sorumluluğuna sahiptir.InventoryService: Sadece ürün stoklarını kontrol etme ve güncelleme sorumluluğuna sahiptir.NotificationService: Sadece kullanıcıya bildirim (e-posta, SMS) gönderme sorumluluğuna sahiptir.OrderService, bir sipariş oluşturulduğunda hem InventoryService'i (stok düşmek için) hem de NotificationService'i (e-posta göndermek için) çağırır, ancak bu servislerin nasıl çalıştığıyla ilgilenmez. Her servis kendi tek sorumluluğuna odaklanır.SRP Uygulaması (DAL içinde):ProductRepository: Sadece Product varlığıyla ilgili veritabanı işlemlerinden (CRUD) sorumludur.OrderRepository: Sadece Order varlığıyla ilgili veritabanı işlemlerinden sorumludur.Bu yapıda, hem sistem genelinde ilgi alanları ayrılmıştır (SoC) hem de her katman içindeki sınıflar tek bir göreve odaklanmıştır (SRP). Bu, son derece modüler, test edilebilir ve bakımı kolay bir tasarım sağlar.Bölüm 5: Yaygın Yanlış Anlaşılmalar ve TuzaklarSoC ve SRP arasındaki ilişki bazen yanlış anlaşılabilir veya uygulamada hatalara yol açabilir:SRP'yi SoC ile Karıştırmak: En yaygın hatadır. Bir sınıfın sadece tek bir teknik katmana (örneğin, sadece veri erişimi yapması) ait olmasının SRP'ye uyduğu düşünülür. Ancak o sınıf hala birden fazla farklı veri varlığıyla ilgileniyorsa (hem ürün hem sipariş gibi), SRP'yi ihlal ediyor olabilir. SRP, "değişim nedeni" ekseninde düşünülmelidir.SoC'yi İhmal Edip Sadece SRP'ye Odaklanmak: Tüm sınıflar tek bir sorumluluğa sahip olsa bile, bu sınıflar yanlış katmanlara veya modüllere dağılmışsa, sistemin genel yapısı hala karmaşık ve bakımı zor olabilir (SoC ihlali).Aşırı Granüler SRP (Atomik Sınıflar): SRP'yi aşırıya kaçırıp her küçük işlev parçacığı için ayrı bir sınıf oluşturmak. Bu, çok fazla sayıda küçük sınıfa ve aralarındaki karmaşık etkileşimlere yol açarak sistemi anlamayı zorlaştırabilir (KISS ihlali). Doğru sorumluluk seviyesini bulmak önemlidir."Sorumluluk" Tanımının Belirsizliği: Hem SoC'deki "ilgi alanı" hem de SRP'deki "sorumluluk" veya "değişim nedeni" tanımları bazen subjektif olabilir ve bağlama göre değişebilir. Takım içinde ortak bir anlayış geliştirmek ve kararları gerekçelendirmek önemlidir.Bölüm 6: Pratik Uygulama ve DeğerlendirmeSoC ve SRP'yi projelerinizde etkili bir şekilde uygulamak için:Tasarım Aşamasında Düşünün: Daha kod yazmaya başlamadan önce, sistemin ana ilgi alanlarını (SoC) ve temel sınıfların potansiyel sorumluluklarını (SRP) düşünün. Mimariyi ve temel sınıf yapılarını buna göre planlayın.Refaktöriyon Fırsatlarını Kollayın: Kod yazarken veya kod incelemesi yaparken SoC ve SRP ihlallerini (kod kokularını) arayın. Bir sınıfın çok fazla iş yaptığını veya farklı katmanlara ait kodların karıştığını fark ettiğinizde refaktör edin."Değişim Nedenini" Sorun (SRP için): Bir sınıfa yeni bir işlevsellik eklerken veya mevcut birini değiştirirken kendinize sorun: "Bu değişiklik, bu sınıfın temel sorumluluğuyla mı ilgili, yoksa farklı bir değişim nedenini mi temsil ediyor?" Farklı bir nedense, bu işlevselliği ayrı bir sınıfa taşımayı düşünün.Katman Sınırlarına Dikkat Edin (SoC için): Farklı katmanlar arasındaki bağımlılıkların yönünü (genellikle üstten alta) ve iletişim mekanizmalarını (arayüzler, DTO'lar) net bir şekilde tanımlayın ve bu sınırlara uyun. Alt katmanların üst katmanları bilmemesini sağlayın.Takım Standardı Oluşturun: SoC ve SRP'nin projenizdeki anlamı ve uygulama şekli konusunda takım içinde ortak bir anlayış ve standartlar oluşturun. Kod incelemelerinde bu standartları referans alın.Sonuç: Modüler Tasarımın İki BoyutuSorumlulukların Ayrılması (SoC) ve Tek Sorumluluk Prensibi (SRP), yazılım tasarımında modülerliği, esnekliği ve sürdürülebilirliği artırmayı hedefleyen, birbiriyle derinden ilişkili ancak farklı odak noktalarına sahip iki temel ilkedir.SoC, gemiyi farklı bölmelere ayırır (makro düzey): Sistemi genel ilgi alanlarına (UI, Mantık, Veri vb.) göre organize eder, büyük ölçekli yapıyı ve katmanlar/modüller arası ilişkileri yönetir.SRP, her bölmedeki ekipmanın tek bir iş yapmasını sağlar (mikro düzey): Her sınıfın veya modülün tek bir göreve odaklanmasını, yüksek içsel bağlılığa sahip olmasını ve değişmek için tek bir nedeni olmasını hedefler.SoC olmadan SRP, iyi organize olmamış bir sistemde tek iş yapan ama dağınık duran sınıflara yol açabilir. SRP olmadan SoC ise, genel yapısı iyi olsa da içindeki katmanların veya modüllerin karmaşık ve bakımı zor sınıflarla dolu olmasına neden olabilir.En etkili ve sürdürülebilir yazılımlar, genellikle bu iki prensibi birlikte ve uyum içinde uygulayanlardır. SoC ile kurulan sağlam mimari temel üzerinde, SRP ile tasarlanmış temiz, odaklanmış ve test edilebilir sınıflar inşa etmek, hem geliştirme sürecini iyileştirir hem de ortaya çıkan ürünün kalitesini artırır. Bu iki prensibi anlamak ve aralarındaki ilişkiyi kavramak, her yazılım geliştiricisinin ve mimarının sahip olması gereken temel bir yetkinliktir ve daha iyi yazılımlar yaratma yolculuğunda bize rehberlik eder.Abdulkadir Güngör - Kişisel WebSite
Abdulkadir Güngör - Kişisel WebSite
Abdulkadir Güngör - Özgeçmiş
Github
Linkedin