Pembangun yang membina aplikasi Laravel digesa untuk meninggalkan kata kunci new di dalam pengawal (controller) mereka dan beralih kepada corak Factory Method. Dengan memindahkan penciptaan objek ke dalam kilang (factory) khusus, kod menjadi lebih mudah untuk diperluas, diuji, dan diselenggara—manfaat yang penting apabila projek berkembang melampaui beberapa titik hujung (endpoints).

Mengapa kata kunci new adalah liabiliti tersembunyi

Apabila sebuah pengawal mengandungi baris seperti 

$processor = new StripePaymentProcessor($config);

pengawal tersebut kini terikat secara ketat (tightly coupled) dengan kelas StripePaymentProcessor. Setiap tempat yang memerlukan pemproses pembayaran akan mengulangi baris tersebut, menyebabkan logik pembinaan tersebar di seluruh kod sumber. Jika pemproses tersebut kemudiannya memerlukan logger, pengurus cache, atau format konfigurasi yang berbeza, setiap lokasi tersebut mesti dikemas kini. Hasilnya ialah kod yang rapuh, sukar untuk diubah, dan sukar untuk di-mock dalam ujian unit.

Corak Factory Method mengambil alih

Corak Factory Method menggantikan penginstansian secara langsung dengan satu kaedah yang mengembalikan instans bagi sesuatu antara muka (interface) yang diberikan. Pengawal bergantung pada antara muka tersebut, manakala kelas kilang mengetahui kelas konkrit mana yang perlu dibina dan cara untuk menyusun kebergantungannya (dependencies). Semua logik penciptaan berada di satu tempat, jadi penambahan kebergantungan baharu atau penukaran pelaksanaan hanya melibatkan kilang tersebut.

Kelebihan utama

  • Kaitan longgar (Loose coupling) – Pengawal berfungsi berdasarkan abstraksi, bukan kelas konkrit.
  • Pembinaan berpusat – Mengubah proses pembinaan hanya memerlukan pengeditan satu fail sahaja.
  • Kebolehtestan – Kilang boleh dijadikan stub atau digantikan dengan mock, membolehkan ujian pengawal dilakukan secara terasing.
  • Prinsip Terbuka/Tertutup (Open/Closed Principle) – Ciri baharu (contohnya, gerbang pembayaran baharu) boleh ditambah tanpa menyentuh kod pengawal sedia ada.

Analogi kedai kopi

Bayangkan seorang barista yang perlu mengisar biji kopi, mengukus susu, dan menuang air secara manual untuk setiap pesanan, menggunakan siri pernyataan if-else yang panjang. Jika resipi latte berubah, setiap barista perlu mempelajari semula langkah-langkah tersebut. Mesin kopi yang menerima jenis pesanan dan mengendalikan penyediaan secara dalaman menyelesaikan masalah ini: barista hanya perlu memberitahu mesin apa yang diperlukan, dan mesin tersebut merangkumkan (encapsulates) semua langkah tersebut. Mengemas kini resipi kini bermakna hanya perlu melaraskan mesin, bukan setiap barista.

Laravel sudah pun bergantung pada kilang (factories)

Komponen teras Laravel sendiri menggambarkan corak ini dalam tindakan:

  • Database – ConnectionFactory menentukan sama ada untuk membina sambungan MySQL atau PostgreSQL.
  • Queues – QueueManager mencipta pemacu (drivers) untuk Redis, SQS, atau sandaran (back-ends) lain.
  • Filesystem – FilesystemManager menghasilkan instans cakera tempatan atau S3.
  • Mail – MailManager menyelesaikan SMTP, Mailgun, atau pemacu e-mel lain.

Jika rangka kerja (framework) mempercayai kilang untuk perkhidmatan kritikal ini, kod tersuai juga harus mengikut jejak yang sama.

Bila perlu memperkenalkan kilang

Gunakan kilang apabila:

  • Penciptaan objek melibatkan pelbagai langkah konfigurasi atau perkhidmatan luaran.
  • Terdapat beberapa pelaksanaan yang boleh ditukar ganti (gerbang pembayaran berbeza, penyedia storan, dll.).
  • Senarai pelaksanaan yang mungkin dijangka akan bertambah.

Elakkan kilang apabila:

  • Pembinaan hanyalah satu panggilan new yang tidak boleh diubah tanpa sebarang tetapan tambahan.
  • Hanya satu pelaksanaan yang akan digunakan, menjadikan abstraksi tambahan sebagai beban (overhead) yang tidak perlu.

Panduan pantas: melakukan refactoring pada pengawal pembayaran

  1. Takrifkan antara muka – PaymentProcessorInterface dengan kaedah process(array $data).
  2. Laksanakan kelas konkrit – StripePaymentProcessor, PayPalPaymentProcessor, masing-masing memenuhi antara muka tersebut.
  3. Cipta kilang – PaymentProcessorFactory dengan kaedah make(string $driver): PaymentProcessorInterface. Di dalamnya, gunakan switch atau pemetaan (map) untuk mengembalikan kelas yang sesuai, dengan menyuntik (injecting) sebarang perkhidmatan yang diperlukan daripada bekas perkhidmatan (service container) Laravel.
  4. Suntik kilang – Dalam pembina (constructor) pengawal, gunakan petunjuk jenis (type-hint) PaymentProcessorFactory. Laravel akan menyelesaikannya secara automatik.
  5. Gunakan kilang – $processor = $this->processorFactory->make('stripe'); $processor->process($request->all());

Kini pengawal tidak lagi menyebut new atau pemproses konkrit. Menambah gerbang baharu bermakna mencipta kelas dan meluaskan pemetaan kilang—tiada perubahan perlu dibuat pada pengawal.

Keburukan yang mungkin berlaku dan cara mengatasinya

Kritikan utama terhadap factory adalah penambahan lapisan tidak langsung (indirection), yang boleh terasa meleret untuk objek yang remeh. Kejuruteraan berlebihan (over-engineering) pada servis yang ringkas boleh mengembangkan kod asas tanpa manfaat sebenar. Kuncinya adalah menilai kerumitan pembinaan: jika sesuatu objek hanyalah pemegang data biasa tanpa sebarang kebergantungan, penggunaan new secara terus mungkin boleh diterima. Selain itu, factory boleh menjadi tempat pembuangan bagi logik yang tidak berkaitan. Mengekalkan fokus factory pada penciptaan objek dan menyerahkan konfigurasi kepada pembekal servis (service provider) yang khusus dapat mengekalkan kejelasan.

Perkara yang perlu diperhatikan seterusnya

  • Ikatan bekas servis (Service container bindings) – Bekas Laravel boleh menyelesaikan factory secara automatik jika anda mengikat antara muka (interface) kepada kelas factory dalam pembekal servis.
  • Penemuan automatik (Auto-discovery) – Sesetengah pakej mendedahkan factory mereka sendiri; berhati-hati dengan pertembungan nama.
  • Strategi pengujian – Semasa melakukan ujian unit pada pengawal (controllers), gantikan factory dengan mock yang mengembalikan pemproses stub, bagi memastikan ujian kekal pantas dan terasing.

Kesimpulan

Menggantikan panggilan new yang berselerak dengan factory yang ditempatkan dengan betul akan memusatkan pembinaan, mengurangkan kaitan (coupling), dan menyelaraskan kod tersuai dengan falsafah reka bentuk Laravel sendiri. Bagi pasukan yang menjangkakan pertumbuhan—pembekal pembayaran baharu, sandaran storan (storage back-ends), atau mana-mana komponen gaya plug-in—corak Factory Method adalah pelaburan kos rendah yang membuahkan hasil dari segi fleksibiliti dan keyakinan. Diri anda di masa hadapan, dan sesiapa sahaja yang mewarisi kod tersebut, akan berterima kasih kepada anda.