Facade Pattern
Facade Pattern, karmaşık bir sisteme, kitaplığa, çerçeveye veya sınıf grubuna basit bir arayüz sağlayan yapısal bir tasarım modelidir. Facade Pattern, client codenu birçok farklı nesne ve yöntemle etkileşime girmeye zorlamak yerine, dahili karmaşıklığı gizleyen net bir giriş noktası oluşturur.
Bu model, bir alt sistemin uygulamanın geri kalanına açıklanmaması gereken birçok adıma, birçok bağımlılığa veya birçok teknik ayrıntıya sahip olması durumunda kullanışlıdır. Bir cephe karmaşıklığı tamamen ortadan kaldırmaz ancak onu daha basit bir genel API arkasında düzenler.
Giriş
Bu Design Patterns serisinin önceki makalelerinde Adapter Pattern ve Decorator Pattern gibi yapısal modellerden bahsetmiştik. Adapter uyumsuz arayüzlerin birlikte çalışmasına yardımcı olurken Decorator, arayüzünü değiştirmeden bir nesneye davranış ekler.
Facade Pattern farklı bir sorunu çözüyor. Bir sistem karmaşık olduğunda ve müşteri kodunun onu kullanmak için daha basit bir yola ihtiyacı olduğunda kullanılır.
Gerçek yazılım projelerinde geliştiriciler genellikle ödeme sistemleri, rapor oluşturma modülleri, dosya işleme araçları, e-posta hizmetleri, medya dönüştürücüler, kimlik doğrulama iş akışları, APIs ve çerçeve bileşenleriyle çalışır. Bu sistemler bir işlemi tamamlamak için birkaç adım gerektirebilir. Facade Pattern, bu adımları tek bir basit yöntemin arkasında gruplandırmaya yardımcı olur.
Facade Pattern Nedir?
Facade Pattern, daha büyük ve daha karmaşık bir alt sisteme basitleştirilmiş bir arayüz sağlayan bir tasarım modelidir. Facade sınıfı, birden fazla dahili sınıfı koordine eden ve client code için temiz bir yöntem ortaya çıkaran, öne bakan bir katman görevi görür.
Basit bir ifadeyle cephe bir resepsiyon masası gibidir. Kullanıcı basit bir talepte bulunur ve resepsiyon masası perde arkasında farklı departmanlarla iletişimi yönetir.
Örneğin, bir çevrimiçi sipariş süreci envanter kontrolünü, ödeme işlemini, fatura oluşturmayı, e-posta bildirimini ve nakliye oluşturmayı içerebilir. Bir kontrolörün tüm bu hizmetleri doğrudan çağırmasını sağlamak yerine, OrderFacade, placeOrder gibi bir yöntem sağlayabilir.
Facade Pattern Neden Önemlidir?
Facade Pattern önemlidir çünkü bir alt sistem kullanan kodun karmaşıklığını azaltır. Facade olmadan, müşteri kodunun çok fazla dahili ayrıntıyı bilmesi ve çok fazla sınıfı doğru sırayla çağırması gerekebilir.
Bu sıkı bir bağlantı oluşturur. Eğer iç alt sistem değişirse uygulamanın birçok parçasının da değişmesi gerekebilir.
Facade Pattern ile client code basit bir arayüze bağlıdır. Facade iç koordinasyonu üstlenir. Bu, uygulamanın anlaşılmasını, bakımını ve yeniden düzenlenmesini kolaylaştırır.
Facade Pattern Olmadan Sorun
PDF raporu oluşturan bir uygulama düşünün. İşlem, verilerin yüklenmesini, verilerin biçimlendirilmesini, HTML'nun oluşturulmasını, HTML'nun PDF'ye dönüştürülmesini, dosyayı kaydetmeyi ve bir bildirim göndermeyi gerektirebilir.
Facade olmadan kontrolör şöyle görünebilir:
$data = $reportRepository->getMonthlyData($month);
$formattedData = $reportFormatter->format($data);
$html = $templateRenderer->render('monthly-report', $formattedData);
$pdf = $pdfConverter->convert($html);
$filePath = $fileStorage->save($pdf);
$notificationService->sendReportReady($filePath);Bu kod denetleyiciye birçok dahili adımı gösterir. Rapor oluşturma iş akışı değişirse denetleyicinin de değişmesi gerekir.
Bir cephe bu adımları tek bir yöntemin arkasına gizleyebilir.
PHP'da Temel Facade Pattern Örneği
Aşağıdaki örnekte rapor oluşturmaya yönelik basit bir görünüm gösterilmektedir:
class ReportRepository
{
public function getMonthlyData(string $month): array
{
return ['sales' => 1000, 'expenses' => 500];
}
}
class ReportFormatter
{
public function format(array $data): array
{
return $data;
}
}
class TemplateRenderer
{
public function render(string $template, array $data): string
{
return '<h1>Monthly Report</h1>';
}
}
class PdfConverter
{
public function convert(string $html): string
{
return 'PDF binary content';
}
}
class FileStorage
{
public function save(string $content): string
{
return '/reports/monthly-report.pdf';
}
}Bu sınıflar karmaşık alt sistemi temsil eder. Her sınıfın odaklanmış bir sorumluluğu vardır, ancak bunların tamamını doğrudan müşteri kodundan kullanmak tekrarlayıcı hale gelebilir.
Facade Sınıfının Oluşturulması
Artık rapor oluşturma sürecini koordine eden bir görünüm oluşturabiliriz:
class ReportFacade
{
public function __construct(
private ReportRepository $repository,
private ReportFormatter $formatter,
private TemplateRenderer $renderer,
private PdfConverter $converter,
private FileStorage $storage
) {
}
public function generateMonthlyReport(string $month): string
{
$data = $this->repository->getMonthlyData($month);
$formattedData = $this->formatter->format($data);
$html = $this->renderer->render('monthly-report', $formattedData);
$pdf = $this->converter->convert($html);
return $this->storage->save($pdf);
}
}Facade, dahili iş akışını gizler ve net bir yöntemi ortaya çıkarır: createdMonthlyReport.
Facadeyi Kullanmak
client code çok daha basit hale geliyor:
$filePath = $reportFacade->generateMonthlyReport('2026-06');İstemcinin verilerin nasıl yüklendiğini, biçimlendirildiğini, işlendiğini, dönüştürüldüğünü veya kaydedildiğini bilmesine gerek yoktur. Facade bu adımları dahili olarak gerçekleştirir.
Bu, kodun okunmasını kolaylaştırır ve alt sistem ayrıntılarına bağımlılığı azaltır.
Facade Pattern'nun Ana Parçaları
Facade Pattern genellikle şu ana parçaları içerir:
Facade: Alt sisteme basit bir arayüz sağlayan sınıf.
Alt sistem sınıfları: Gerçek işi gerçekleştiren dahili sınıflar.
client code: Alt sistem sınıflarını doğrudan çağırmak yerine cepheyi kullanan kod.
Facade alt sistemin yerini almaz. Erişimi düzenler ve ortak işlemlerin kullanımını kolaylaştırır.
Gerçek Dünyadan Örnek: Sipariş İşleme Facadesi
Sipariş işleme, Facade Pattern'nun güçlü bir örneğidir. Tek bir sipariş işlemi birden fazla dahili hizmet gerektirebilir.
Örneğin, bir sipariş vermek şunları içerebilir:
Sepet doğrulanıyor.
Ürün stokunun kontrol edilmesi.
Sipariş kaydının oluşturulması.
Ödeme işleniyor.
Envanterin azaltılması.
Fatura oluşturma.
Onay e-postası gönderiliyor.
Bir kontrolörün genellikle tüm bu ayrıntıları doğrudan koordine etmemesi gerekir. OrderFacade, placeOrder gibi daha basit bir yöntem sağlayabilir.
PHP'da Sipariş İşleme Facade Örneği
class OrderFacade
{
public function __construct(
private CartValidator $cartValidator,
private StockService $stockService,
private OrderCreator $orderCreator,
private PaymentService $paymentService,
private InventoryService $inventoryService,
private InvoiceService $invoiceService,
private EmailService $emailService
) {
}
public function placeOrder(User $user, Cart $cart): Order
{
$this->cartValidator->validate($cart);
$this->stockService->checkAvailability($cart);
$order = $this->orderCreator->create($user, $cart);
$this->paymentService->charge($order);
$this->inventoryService->decreaseStock($cart);
$this->invoiceService->generate($order);
$this->emailService->sendOrderConfirmation($user, $order);
return $order;
}
}Denetleyici artık bir yöntemi çağırabilir ve kodunu temiz tutabilir:
$order = $orderFacade->placeOrder($user, $cart);Bunu anlamak, tüm sipariş iş akışı adımlarını denetleyicinin içine yerleştirmekten daha kolaydır.
Facade Pattern ve Kontrolörler
Facade Pattern, denetleyiciler çok büyüdüğünde kullanışlıdır. Web uygulamalarında denetleyiciler genellikle karmaşık iş akışlarını değil, istekleri ve yanıtları ele almalıdır.
Bir denetleyici çok sayıda hizmet çağrısı, koşul ve iş akışı adımı içeriyorsa, bir cephe veya uygulama hizmeti bu karmaşıklığı özel bir sınıfa taşıyabilir.
Bu, denetleyiciyi ince tutar ve iş iş akışının ayrı ayrı test edilmesini kolaylaştırır.
Facade Pattern ve Service Layer
Facade Pattern genellikle hizmet katmanına bağlanır. Bir cephe, birçok alt düzey hizmeti koordine eden üst düzey bir hizmet olarak hareket edebilir.
Örneğin, bir UserRegistrationFacade, kullanıcı oluşturmayı, şifre karma işlemini, e-posta doğrulamayı, karşılama e-postası göndermeyi ve profil başlatmayı koordine edebilir.
Bu, her hizmetin bir cephe olduğu anlamına gelmez. Bir cephe, birden fazla dahili operasyona veya karmaşık bir alt sisteme erişimi kolaylaştırdığında özellikle kullanışlıdır.
Gerçek Dünyadan Örnek: Kullanıcı Kaydı Facadesi
Kullanıcı kaydı, özellikle profesyonel uygulamalarda birkaç adımı içerebilir.
class UserRegistrationFacade
{
public function __construct(
private UserValidator $validator,
private PasswordHasher $passwordHasher,
private UserRepository $users,
private EmailVerificationService $verification,
private WelcomeEmailService $welcomeEmail
) {
}
public function register(array $data): User
{
$this->validator->validate($data);
$user = new User(
name: $data['name'],
email: $data['email'],
password: $this->passwordHasher->hash($data['password'])
);
$this->users->save($user);
$this->verification->send($user);
$this->welcomeEmail->send($user);
return $user;
}
}Facade, dahili süreci gizlerken kullanıcı kaydı için tek bir net işlem sağlar.
Gerçek Dünyadan Örnek: Medya Dönüşüm Facadesi
Medya işleme sistemleri karmaşık olabilir. Bir videoyu dönüştürmek validation, format algılama, sıkıştırma, küçük resim oluşturma, depolama ve meta veri çıkarma işlemlerini gerektirebilir.
Bir MediaFacade, birçok dahili bileşeni koordine ederken, ConvertVideo gibi basit bir yöntemi ortaya çıkarabilir.
class MediaFacade
{
public function __construct(
private FileValidator $validator,
private FormatDetector $detector,
private VideoConverter $converter,
private ThumbnailGenerator $thumbnailGenerator,
private MediaStorage $storage
) {
}
public function convertVideo(string $filePath): string
{
$this->validator->validate($filePath);
$format = $this->detector->detect($filePath);
$convertedFile = $this->converter->convert($filePath, $format);
$this->thumbnailGenerator->generate($convertedFile);
return $this->storage->save($convertedFile);
}
}client codenun pipeline medya işlemenin tamamını anlamasına gerek yoktur. Tek cephe yöntemini kullanır.
Laravel'da Facade Pattern
Laravel, hizmet konteyneri içindeki hizmetlere statik benzeri erişim sağlayan belirli bir çerçeve özelliği için "Facade" kelimesini kullanır. Örnekler arasında Önbellek, Posta, Veritabanı, Yönlendirme ve Repositorylama yer alır.
Laravel Facadeler, karmaşık hizmetlere erişimi basitleştirme genel fikriyle ilgilidir, ancak aynı zamanda çerçeveye özgü bir uygulamadır. Klasik Facade Pattern ile tamamen karıştırılmamalıdırlar.
Kendi Laravel uygulamalarınızda ayrıca ödeme, kayıt, raporlama, içe/dışa aktarma veya bildirim yönetimi gibi karmaşık iş akışlarını basitleştiren cephe tarzı uygulama hizmetleri de oluşturabilirsiniz.
Klasik Facade vs Laravel Facade
Klasik Facade Pattern, karmaşık bir alt sisteme basit bir arayüz sağlayan yapısal bir tasarım modelidir. Genellikle bağımlılıkları alan ve bunları koordine eden normal bir sınıf olarak uygulanır.
Laravel Facadeler, Laravel'nun servis konteynerinde depolanan hizmetlere statik görünümlü bir arayüz sağlar. Perde arkasında Laravel, kapsayıcıdaki gerçek hizmet nesnesini çözer.
Her iki fikir de kullanımı basitleştirir, ancak Laravel Facadeler bir çerçeve özelliğidir, klasik Facade Pattern ise genel bir nesne yönelimli tasarım modelidir.
Symfony'da Facade Pattern
Symfony uygulamaları, karmaşık iş akışlarını basitleştirmek için cephe tarzı hizmetleri kullanabilir. Symfony güçlü bir bağımlılık enjeksiyon konteynerine sahip olduğundan, bir cephe birden fazla hizmet alabilir ve bir veya daha fazla üst düzey yöntemi açığa çıkarabilir.
Örneğin, bir CheckoutFacade validation sepetini, ödemeyi, fatura oluşturmayı ve bildirim göndermeyi koordine edebilir. Kontrolörler CheckoutFacade'e bağlı olabilir ve küçük kalabilir.
Bu yaklaşım, Symfony hizmet mimarisine iyi uyum sağlar ve iş akışlarının test edilmesini kolaylaştırır.
Facade Pattern ve Dependency Injection
Facade Pattern bağımlılık enjeksiyonuyla iyi çalışır. Facade içinde alt sistem nesnelerini manuel olarak oluşturmak yerine, cephe bunları yapıcısı aracılığıyla alabilir.
Bu, cephenin test edilmesini ve yapılandırılmasını kolaylaştırır.
Örneğin, test sırasında, gerçek ödeme ağ geçitlerini, e-posta sistemlerini veya dosya depolama hizmetlerini çağırmadan iş akışını doğrulamak için sahte hizmetler cepheye enjekte edilebilir.
Facade Pattern ve Temiz Mimari
clean architecture'da üst düzey iş akışları genellikle kullanım senaryosu sınıflarına veya uygulama hizmetlerine yerleştirilir. Bu sınıflar cephelere benzer görünebilir çünkü birçok bileşeni basit bir yöntemin arkasında koordine ederler.
Bir cephe, müşteri kodunu alt sistem karmaşıklığından korumaya yardımcı olabilir, ancak geliştiriciler yine de iş kurallarını düzgün bir şekilde organize etmelidir. Facade, sistemdeki her iş kuralını içeren büyük bir sınıf haline gelmemeli, çalışmayı koordine etmelidir.
İyi bir cephe tasarımı, sorumlulukları net tutarken erişimi de kolaylaştırmalıdır.
Facade Pattern vs Adapter Pattern
Facade Pattern ve Adapter Pattern'nun her ikisi de yapısal Design Patternsdir ancak farklı sorunları çözerler.
Adapter Pattern, bir arayüzü istemcinin beklediği başka bir arayüze dönüştürür. Sınıflar veya sistemler uyumsuz olduğunda kullanılır.
Facade Pattern, karmaşık bir alt sisteme basitleştirilmiş bir arayüz sağlar. Alt sistemin doğrudan kullanımının zor olduğu durumlarda kullanılır.
Kısacası Adapter uyumluluğa odaklanırken Facade sadeleştirmeye odaklanır.
Facade Pattern vs Decorator Pattern
Facade Pattern ve Decorator Pattern'nun da farklı amaçları vardır.
Decorator Pattern, aynı arayüzü korurken davranış eklemek için bir nesneyi sarar. Mevcut bir nesnenin etrafına günlük kaydı, önbellekleme, validation veya yetkilendirme eklemek için kullanışlıdır.
Facade Pattern, daha basit bir arayüz sağlamak için bir alt sistemi sarar. Amacı alt sistemin kullanımını kolaylaştırmak olduğu için mutlaka aynı arayüzü tutması gerekmez.
Kısacası Decorator davranış kazandırırken Facade kullanımı kolaylaştırır.
Facade Pattern ve Proxy Deseni Karşılaştırması
Proxy Kalıbı başka bir nesneye erişimi kontrol eder. Tembel yükleme, erişim kontrolü, önbelleğe alma veya uzaktan iletişim ekleyebilir. Genellikle gerçek nesneyle aynı arayüzü temsil eder.
Facade Pattern, birden fazla sınıfa veya karmaşık bir alt sisteme basitleştirilmiş bir arayüz sağlar. Erişimin kontrol edilmesinden ziyade client codenun karmaşıklığının azaltılmasıyla ilgilidir.
Her iki model de ayrıntıları gizleyebilir ancak amaçları farklıdır.
Facade Pattern vs Hizmet Sınıfı
Bir hizmet sınıfı belirli bir işlemi veya iş sorumluluğunu gerçekleştirir. Facade, karmaşık bir alt sisteme veya iş akışına erişimi kolaylaştıran, hizmet benzeri bir sınıf türüdür.
Her hizmet bir cephe değildir. Örneğin, TaxCalculator hizmeti basitçe vergiyi hesaplayabilir. Bu mutlaka bir cephe değildir. Ancak validation sepetini, ödemeyi, envanteri, faturayı ve e-posta hizmetlerini koordine eden bir CheckoutFacade, Facade Pattern'ya daha yakındır.
Temel fark, bir cephenin genellikle birden fazla dahili bileşeni daha basit bir arayüzün arkasına saklamasıdır.
Facade Pattern'nun Faydaları
Facade Pattern, nesne yönelimli yazılım tasarımında birçok fayda sağlar.
Ana faydalar şunları içerir:
Karmaşık alt sistemlere erişimi kolaylaştırır.
client code ile dahili sınıflar arasındaki bağlantıyı azaltır.
Denetleyicileri ve istemci sınıflarını daha temiz tutar.
İş akışı koordinasyonunu merkezileştirir.
Karmaşık işlemlerin kullanımını kolaylaştırır.
Okunabilirliği ve sürdürülebilirliği artırır.
Alt sistem dahili bileşenlerinin client code üzerinde daha az etki yaratacak şekilde değişmesine olanak tanır.
Bu avantajlar, Facade Pattern'yu karmaşık iş akışlarına veya birden fazla etkileşimli hizmete sahip uygulamalarda kullanışlı hale getirir.
Facade Pattern'nun dezavantajları
Facade Pattern'nun dezavantajları da olabilir. Bir cephe çok büyürse çok bilen, çok yapan bir Tanrı sınıfına dönüşebilir.
Diğer bir dezavantaj ise çok fazla basitleştirmenin önemli davranışları gizleyebilmesidir. Geliştiriciler, gerektiğinde cephenin dahili olarak ne yaptığını hâlâ anlayabilmelidir.
Facade ayrıca ekstra bir soyutlama katmanı da oluşturabilir. Alt sistem zaten basitse cephe eklemek gereksiz olabilir.
Facade Pattern Ne Zaman Kullanılır?
client codenun karmaşık bir alt sistem veya iş akışıyla etkileşim kurmak için daha basit bir yola ihtiyacı olduğunda Facade Pattern'yu kullanın.
Facade Pattern şu durumlarda faydalıdır:
Bir süreç birçok dahili adım gerektirir.
client code çok fazla alt sistem sınıfına bağlı.
Denetleyiciler veya hizmetler çok karmaşık hale geliyor.
Teknik detayları basit bir yöntemin arkasına gizlemek istiyorsunuz.
Ortak bir iş akışını merkezileştirmeniz gerekiyor.
Alt sistem gelecekte dahili olarak değişebilir.
Okunabilirliği artırmak ve kopyaları azaltmak istiyorsunuz.
Bu koşullar mevcutsa Facade Pattern sistemin kullanımını ve bakımını kolaylaştırabilir.
Facade Pattern Ne Zaman Kullanılmamalı?
Alt sistem zaten basit olduğunda veya cephenin netlik kazandırmadan yalnızca bir yöntem çağrısını ileteceği durumlarda Facade Pattern'yu kullanmayın.
Aşağıdaki durumlarda Facade Pattern'dan kaçının:
Operasyon basit ve doğrudandır.
Facade gereksiz soyutlama yaratıyor.
Facade büyük bir Tanrı sınıfına dönüşür.
Facade çok fazla önemli iş kuralını gizliyor.
client codenun alt sisteme yönelik temiz bir arayüzü zaten var.
Design Patterns karmaşıklığı azaltmalı, fayda sağlamadan başka bir katman eklememelidir.
Facade Pattern ile Yapılan Yaygın Hatalar
Yaygın bir hata, çok sayıda ilgisiz işlemi tek bir cepheye yerleştirmektir. Örneğin kullanıcıları, siparişleri, ödemeleri, raporları, e-postaları ve dosyaları yöneten bir ApplicationFacade çok büyük hale gelecektir.
Bir diğer hata ise tüm business logicnı dış cepheye koymaktır. Bir cephenin alt sistem sınıflarını koordine etmesi gerekir ancak odaklanmış iş kuralları yine de etki alanı sınıflarına, hizmetlere veya kullanım senaryolarına ait olabilir.
Üçüncü bir hata ise kötü tasarımı gizlemek için cephe kullanmaktır. Alt sistemin kendisi dağınıksa, bir cephe kullanımı kolaylaştırabilir ancak iç yapıyı otomatik olarak düzeltmez.
Dördüncü hata, basit bir servis yönteminin yeterli olacağı bir görünüm yaratmaktır.
Facade Pattern için En İyi Uygulamalar
Facade Pattern'yu etkili bir şekilde kullanmak için geliştiricilerin cepheyi odaklanmış ve anlamlı tutması gerekir.
Yararlı en iyi uygulamalar şunları içerir:
Gerçek karmaşıklığı basitleştirmek için cepheleri kullanın.
Her cephenin tek bir alt sisteme veya iş akışına odaklanmasını sağlayın.
Alt sistem sınıfları için bağımlılık eklemeyi kullanın.
Facadeyi Tanrı sınıfına dönüştürmekten kaçının.
İş kurallarını uygun sınıflarda organize edin.
Üst düzey işlemleri açıklayan anlaşılır yöntem adları kullanın.
Gereksiz dahili alt sistem ayrıntılarını açığa çıkarmayın.
Önemli operasyonları koordine ederken cephe iş akışları için testler yazın.
Bu uygulamalar cepheye dayalı tasarımın temiz ve sürdürülebilir kalmasına yardımcı olur.
Facade Pattern Kullanmadan Önce Pratik Kontrol Listesi
Facade Pattern'yu kullanmadan önce geliştiriciler şu soruları sorabilir:
Alt sistem basitleştirmeyi gerektirecek kadar karmaşık mı?
client code şu anda birçok dahili sınıfı çağırıyor mu?
Bir cephe kopyaları azaltacak mı?
Bir cephe kontrolörleri veya hizmetleri daha temiz hale getirecek mi?
Facade net bir üst düzey operasyonu ortaya çıkarabilir mi?
Facade odaklanmış kalacak mı?
Bu basit bir hizmet sınıfı kullanmaktan daha mı iyi?
Bu soruların birçoğunun cevabı evet ise Facade Pattern iyi bir tasarım tercihi olabilir.
Sonuç
Facade Pattern, karmaşık bir alt sisteme basit bir arayüz sağlayan yapısal bir tasarım modelidir. Dahili karmaşıklığın gizlenmesine, bağlantının azaltılmasına ve client codenun okunmasının ve bakımının kolaylaştırılmasına yardımcı olur.
Facade Pattern, sipariş işleme, rapor oluşturma, kullanıcı kaydı, medya dönüştürme, ödeme işleme ve karmaşık entegrasyonlar gibi iş akışları için kullanışlıdır. Bağımlılık eklemeyle iyi çalışır ve denetleyicilerin ve uygulama hizmetlerinin temiz tutulmasına yardımcı olabilir.
Ancak Facade dikkatli kullanılmalıdır. Bir cephe gerçek karmaşıklığı basitleştirmeli, her türlü sorumluluğu içinde barındıran büyük bir sınıfa dönüşmemelidir. Doğru uygulandığında Facade Pattern temiz, düzenli ve bakımı kolay nesne yönelimli yazılım oluşturmaya yönelik pratik bir araçtır.
