Açısal ve SOLID ilkeleri

SOLID, geliştiricilerin daha iyi yazılım uygulamaları tasarlamasına yardımcı olan bir dizi ilkenin kısaltmasıdır. Bu ilkeler şunlardır:

1. Tek Sorumluluk İlkesi (SRP)
   '' Bir sınıfın veya modülün değişmek için tek bir nedeni olmalıdır.''
   Bu, bir sınıfın yalnızca bir şeyden sorumlu olması ve birden fazla sorumluluğu olmaması gerektiği anlamına gelir.
2. Açık/Kapalı Prensibi (OCP)
   '' Bir sınıf genişlemeye açık, değişikliğe kapalı olmalıdır.''
   Bu, mevcut kodunu değiştirmeden bir sınıfa yeni işlevler ekleyebilmeniz gerektiği anlamına gelir.
3. Liskov İkame İlkesi (LSP)
   '' Alt tipler, temel tiplerinin yerine kullanılabilir olmalıdır.''
   Bu, eğer bir sınıf başka bir sınıftan türetilmişse, herhangi bir beklenmedik davranışa neden olmadan üst sınıfın yerini alabilmesi gerektiği anlamına gelir.
4. Arayüz Segregasyon İlkesi (ISP)
   '' Müşteriler, kullanmadıkları arayüzlere bağımlı olmaya zorlanmamalıdır.''
   Bu, bir sınıfın ihtiyaç duymadığı arayüzleri uygulamaya zorlanmaması gerektiği anlamına gelir.
5. Bağımlılık Tersine Çevirme İlkesi (DIP)
   '' Yüksek seviyeli modüller, düşük seviyeli modüllere bağlı olmamalıdır. Her ikisi de soyutlamalara bağlı olmalıdır. ''
   Bu, sınıfların somut uygulamalardan ziyade soyutlamalara bağlı olması gerektiği anlamına gelir.

Angular'da, bir API'den veri almak veya kullanıcı kimlik doğrulamasını yönetmek gibi tek sorumluluğu olan hizmetler oluşturabilirsiniz. Bir API'den veri alan bir hizmet örneğini burada bulabilirsiniz:

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';

@Injectable()
export class DataService {
  constructor(private http: HttpClient) {}

  getData() {
    return this.http.get('https://jhonburbakollam.com/data');
  }
}

Açık/Kapalı Prensibi (OCP)

Angular'da, orijinal kodlarını değiştirmeden genişletilebilen veya değiştirilebilen yeniden kullanılabilir bileşenler oluşturmak için kalıtım ve kompozisyonu kullanabilirsiniz. İşte kompozisyon kullanan bir bileşen örneği:

import { Component } from '@angular/core';

@Component({
  selector: 'app-button',
  template: '<button>Click me!</button>'
})
export class ButtonComponent {}

import { Component } from '@angular/core';
import { ButtonComponent } from './button.component';

@Component({
  selector: 'app-custom-button',
  template: '<button>Custom text</button>'
})
export class CustomButtonComponent extends ButtonComponent {}

Liskov İkame İlkesi (LSP)

Angular'da, sınıfların izlemesi gereken sözleşmeleri tanımlamak için arayüzleri kullanabilirsiniz. İşte bir sözleşmeyi tanımlayan bir arayüz örneği:

export interface DataService {
  getData(): Observable<any>;
}

Bu arabirimi uygulayan bir sınıfınız varsa, herhangi bir beklenmeyen davranışa yol açmadan, bu arabirimi yine arabirimi uygulayan başka bir sınıfla değiştirebilirsiniz.

Arayüz Ayırma İlkesi (ISP)

Angular'da, sınıfların izlemesi gereken sözleşmeleri tanımlamak için arayüzleri kullanabilirsiniz. İşte ISP'yi takip eden bir arayüz örneği:

export interface Logger {
  log(message: string): void;
}

Arabirimleri kullanarak, sınıfların kullanmadıkları arabirimleri uygulamaya zorlanmak yerine yalnızca ihtiyaç duydukları arabirimlere bağlı olmasını sağlayabilirsiniz.

Bağımlılık Tersine Çevirme İlkesi (DIP)

Angular'da, diğer sınıflara sınıf örnekleri sağlamak için bağımlılık enjeksiyonunu kullanabilirsiniz. Bağımlılık eklemeyi kullanan bir hizmet örneği aşağıda verilmiştir:

import { Injectable } from '@angular/core';
import { DataService } from './data.service';

@Injectable()
export class LoggerService {
  constructor(private dataService: DataService) {}

  logData() {
    this.dataService.getData().subscribe((data) => {
      console.log(data);
    });
  }
}

Bağımlılık enjeksiyonunu kullanarak, bağımlı sınıfın kodunu değiştirmeden uygulamaları değiştirmenize izin veren sınıflar arasında gevşek bağlantı elde edebilirsiniz.