SOLID İlkesi Havuz Kalıbı İle Laravel

Question

SOLID İlkesini korurken Denetleyici Deposu ile Denetleyici kullanımı hakkında bir kafa karışıklığım var. Ben Özlü

1. Ticari Teklif
2. Özel Teklif

Ve gelecekte alıntılarla yeni tip yüksek şans iki tür var düşünün. Her Teklifin farklı alanları vardır, iş mantığı vardır, ancak birçok ortak işlevi paylaşırlar. Bu yüzden bir QuotationInterface

Tırnak Inteface Interface

class CommercialQuotation implements QuotationInterface 
{ 
    public function(array $data) 
    { 
     // save commercial quotation 
    } 
} 

class PrivateQuotation implements QuotationInterface 
{ 
    public function(array $data) 
    { 
    // save Private quotation 
    } 
} 

Tırnak Deposu uygulamak

interface QuotationInterface 
{ 
    public function save(array $data); 

} 

Tırnak sınıfı yarattı

class QuotationRepository 
{ 
    public function save(array $data, QuotationInterface $quotation) 
    { 
     $quotation->save($data); 
    } 
} 

QotationController İşte benim QuotationController içinde

public function store(Resource $resource) 
{ 

    $inputs = $resource->all(); 

    /** 
    * Clearly here Open/Close Principle is broken 
    */ 

    if ($inputs['type'] == 'private'){ 
     $quotation = new PrivateQuotation;; 
    } 
    else if($inputs['type'] == 'commercial'){ 
     $quotation = new CommercialQuotation; 
    } 

    $this->repo->save($inputs, $quotation); 
} 

, açıkça

tırnak her türü için Kontrolör oluşturma iyi bir fikir mi .. Aç/Kapat İlke ihlal ( olabilir 10+ bir gün, kim bilir?) OCP ihlalinden kaçınmak için tasarımım yanlış mı? Herhangi bir öneri, tasarım değişikliği ipuçları, kaynak açıktır.

NOT: Teklifim Denetçisi, yalnızca kaydetme dışında birçok başka işleve sahip olacaktır.

Answer 1

sana bir ile, sizin $quotation nesneleri Örneğin

oluşturmak için alıntılar için tek bir denetleyici kullanmak ve bir Fabrika tasarım deseni kullanmak önermek Bu gibi basit fabrika: Eğer kontrolörleri yöntemleri fabrikayı kullanabilirsiniz

//FACTORY CLASS 
abstract class QuotationFactory 
{ 
    /** return QuotationInterface */ 
    public static function createQuotation($type) 
    { 
     switch($type) 
     { 
      CASE "private": 
       return new PrivateQuotation(); 
      break; 

      CASE "commercial": 
       return new CommercialQuotation(); 
      break;  
     } 
    } 
} 

:

//YOUR CONTROLLER'S METHOD 
public function store(Resource $resource) 
{ 
    $inputs = $resource->all(); 

    //delegate objects creation to factory class 
    $quotation = QuotationFactory::createQuotation($inputs['type']); 

    $this->repo->save($inputs, $quotation); 
} 

Bu şekilde, kontrol cihazlarınızdaki açık/kapalı ilkeyi ihlal etmeyeceksiniz, çünkü siz teklifler ekledikçe, yalnızca fabrika yöntemini değiştirmeniz gerekir (anahtar ifadesine durumlar ekleyerek) ve bir QuotationFactory nesnesi gereken her yerde.

Bu aynı zamanda kodunuzu tutacak KURU ve KATI sen/else ifadeleri sizin kontrolörün yöntemlerinde Nesnelerinizi oluşturmak için eğer bir karşı nesnelerin yaratılış sorumluluk temsilci olarak tekrarlamak zorunda değilsiniz çünkü özel fabrika sınıfı

Aşağıdaki yorumlarda doğru bir şekilde işaret edildiği gibi, Basit fabrika, denetleyicilerinizdeki Açık/Kapalı İlkesinden kaçınmanıza yardımcı olacak, ancak daha genel bir bakış açısından, Basit Fabrikanın kendisinden gelen bir eşya olacaktır. bir anahtar durumu kullandığı için OCP'yi doğal olarak ihlal ediyor.

Neyse, uygulamanızın görebildiğim kadarıyla, basit fabrika, iyi bir çözüm olabilir çünkü öncelikli konu, değişken bir yerden birçok yerde örnek oluşturmaktır. Böylelikle, Basit fabrikayı kullanarak, nesneleri fabrikaya oluşturma ve kontrol cihazlarınızda ihtiyaç duyduğunuz örnekleri alma işlemlerini 'gizleyebilirsiniz'. Bu nedenle, OCP'yi yalnızca anahtarın içinde bulunan fabrikanın içinde ihlal ediyorsunuz, ancak bunun açık bir satışa kapalı olabileceğini düşünüyorum. Bu,

Answer 2

Bunun çoğunlukla uygulamanızın kapsamına bağlı olduğunu düşünüyorum. PHP dünyasında bu günlerde insanlar/else ifadeleriyle çok öfkelendiler :). Ancak, bu sizin uygulamanız için çalışıyor ve sizin bağlamınızın kapsamı içinde makul görünüyorsa, bence bu iyi.

İşletmeler değişiyor ve İş değişiklikleri planlamak her zaman kolay değil. Bu değişiklikleri yalnızca ortaya çıktıklarında daha kolay hale getirmeye çalışabilirsiniz.

Bu söyleniyor ki, dersler ucuz ve bu noktada (ve gelecekte) ayrı sınıflara sahip olmanın çok makul olduğunu düşünüyorum. Her bir teklif türü için gereklilikler genişlediyse, iyi bir temelde olacaksınız ve şu ana kadar, kodunuzun anlaşılması zor olacağına dair soyutlama yaptığınızı düşünmüyorum.ileride gösterdiğin yol gidiyoruz