Sınıflar neden tek sorumluluk ilkesine uymalıdır?

Kural
Sınıflar şöyle olmalıdır tek sorumluluğu olmalıdır.
Sınıflar birden fazla birden fazla konuları ihlal
şunu Tek Tek ilkesini ihlal eder.

Desteklenen diller: JS, TS, PY, JAVA, C/C++,
C#, Swift/Objective C, Ruby. PHP, Kotlin, 
Scala, Rust, Haskell, Groovy, Dart. Julia,
Elixit, Klojure, OCaml, Delphi

Giriş

Fazla iş yapan sınıflar darboğazlara dönüşür. Kimlik doğrulama, e-postalar ve geçerlilik denetimini yürüten bir sınıf, herhangi bir konu değiştiğinde değişiklik gerektirir ve bu da alakasız işlevlerde arızalara yol açma riskini doğurur. Test sırasında, tek bir yönü test ediliyor olsa bile sınıfın tamamının simülasyonu gerekir. Tek Sorumluluk İlkesi, bir sınıfın değişmesi için yalnızca tek bir neden olması gerektiğini belirtir.

Neden önemli?

Kodun bakım kolaylığı: Birden fazla sorumluluğa sahip sınıflar daha sık değişir; çünkü herhangi bir sorumluluğun gelişimi sınıfın tamamını etkiler.

Test karmaşıklığı: Birden fazla sorumluluğa sahip sınıfları test etmek, tek bir özelliği test etmek için bile olsa tüm bağımlılıkların simüle edilmesini gerektirir.

Yeniden Kullanılabilirlik: Tüm bağımlılıkları da beraberinde getirmeden tek bir sorumluluğu ayıramazsınız. Geliştiriciler, birden fazla sorumluluğa sahip sınıfları birbirinden ayırmak yerine kodu tekrarlamayı tercih ederler.

Ekip koordinasyonu: Aynı sınıf üzerinde farklı özellikler için çalışan birden fazla geliştirici, sık sık birleştirme çakışmalarına yol açar. Tek sorumluluklu sınıflar, çakışma olmadan paralel geliştirmeye olanak tanır.

Kod örnekleri

❌ Uygun değil:

class UserManager {
    async createUser(userData) {
        const user = await db.users.insert(userData);
        await this.sendWelcomeEmail(user.email);
        await this.logEvent('user_created', user.id);
        await cache.set(`user:${user.id}`, user);
        return user;
    }

    async sendWelcomeEmail(email) {
        const template = this.loadEmailTemplate('welcome');
        await emailService.send(email, template);
    }

    async logEvent(event, userId) {
        await analytics.track(event, { userId, timestamp: Date.now() });
    }
}

Neden yanlış: Bu sınıf, veritabanı işlemlerini, e-posta gönderimini, günlük kaydı ve önbelleklemeyi yönetir. E-posta şablonlarında, günlük kayıt biçimlerinde veya önbellek stratejisinde yapılacak her türlü değişiklik, bu sınıfın değiştirilmesini gerektirir. Kullanıcı oluşturma işlemini test etmek, e-posta hizmetlerini, analiz sistemlerini ve önbelleği simüle etmek anlamına gelir; bu da testlerin yavaşlamasına ve kırılgan hale gelmesine neden olur.

✅ Uygunluk:

class UserRepository {
    async create(userData) {
        return await db.users.insert(userData);
    }
}

class EmailNotificationService {
    async sendWelcomeEmail(email) {
        const template = await this.templateLoader.load('welcome');
        return await this.emailSender.send(email, template);
    }
}

class UserEventLogger {
    async logCreation(userId) {
        return await this.analytics.track('user_created', {
            userId,
            timestamp: Date.now()
        });
    }
}

class UserService {
    constructor(repository, emailService, eventLogger, cache) {
        this.repository = repository;
        this.emailService = emailService;
        this.eventLogger = eventLogger;
        this.cache = cache;
    }

    async createUser(userData) {
        const user = await this.repository.create(userData);
        await Promise.all([
            this.emailService.sendWelcomeEmail(user.email),
            this.eventLogger.logCreation(user.id),
            this.cache.set(`user:${user.id}`, user)
        ]);
        return user;
    }
}

Bunun önemi: Her sınıfın tek bir net sorumluluğu vardır: veri kalıcılığı, e-posta gönderimi, olay günlüğü kaydı veya koordinasyon. E-posta şablonlarında yapılan değişiklikler yalnızca E-posta Bildirim Hizmeti. Kullanıcı oluşturma işlevinin test edilmesinde, bağımlılıklar için basit yedek kodlar kullanılabilir. Sınıflar, farklı özellikler arasında bağımsız olarak yeniden kullanılabilir.

Sonuç

Tek Sorumluluk İlkesi, sınıfları olabildiğince küçük hale getirmekle ilgili değildir; her sınıfın değişmesi için tek ve net bir neden olmasını sağlamaktır. Bir sınıf birden fazla konuyu ele almaya başladığında, her bir sorumluluğu odaklanmış bir arayüze sahip kendi sınıfına ayırarak yeniden yapılandırın. Bu, alakasız işlevler arasında zincirleme değişikliklere yol açmadan kodun test edilmesini, bakımının yapılmasını ve geliştirilmesini kolaylaştırır.