Laravel ਐਪਲੀਕੇਸ਼ਨਾਂ ਬਣਾ ਰਹੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਆਪਣੇ ਕੰਟਰੋਲਰਾਂ ਦੇ ਅੰਦਰ new ਕੀਵਰਡ ਨੂੰ ਛੱਡਣ ਅਤੇ Factory Method ਪੈਟਰਨ ਵੱਲ ਜਾਣ ਦੀ ਸਲਾਹ ਦਿੱਤੀ ਜਾ ਰਹੀ ਹੈ। ਆਬਜੈਕਟ ਕ੍ਰਿਏਸ਼ਨ (object creation) ਨੂੰ ਸਮਰਪਿਤ ਫੈਕਟਰੀਆਂ (factories) ਵਿੱਚ ਲੈ ਕੇ ਜਾਣ ਨਾਲ, ਕੋਡ ਨੂੰ ਵਧਾਉਣਾ, ਟੈਸਟ ਕਰਨਾ ਅਤੇ ਬਰਕਰਾਰ ਰੱਖਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ—ਇਹ ਉਹ ਫਾਇਦੇ ਹਨ ਜੋ ਉਦੋਂ ਮਹੱਤਵਪੂਰਨ ਹੋ ਜਾਂਦੇ ਹਨ ਜਦੋਂ ਪ੍ਰੋਜੈਕਟ ਕੁਝ ਐਂਡਪੁਆਇੰਟਾਂ ਤੋਂ ਅੱਗੇ ਵਧਦੇ ਹਨ।

new ਕੀਵਰਡ ਇੱਕ ਲੁਕੀ ਹੋਈ ਦੇਣਦਾਰੀ (liability) ਕਿਉਂ ਹੈ

ਜਦੋਂ ਇੱਕ ਕੰਟਰੋਲਰ ਵਿੱਚ ਅਜਿਹੀ ਲਾਈਨ ਹੁੰਦੀ ਹੈ ਜਿਵੇਂ ਕਿ 

$processor = new StripePaymentProcessor($config);

ਤਾਂ ਕੰਟਰੋਲਰ ਹੁਣ StripePaymentProcessor ਕਲਾਸ ਨਾਲ ਬਹੁਤ ਗੂੜ੍ਹਾ ਜੁੜ (tightly coupled) ਜਾਂਦਾ ਹੈ। ਹਰ ਉਹ ਜਗ੍ਹਾ ਜਿੱਥੇ ਪੇਮੈਂਟ ਪ੍ਰੋਸੈਸਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਉਹ ਉਸੇ ਲਾਈਨ ਨੂੰ ਦੁਹਰਾਉਂਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਕੰਸਟ੍ਰਕਸ਼ਨ ਲੌਜਿਕ (construction logic) ਪੂਰੇ ਕੋਡਬੇਸ ਵਿੱਚ ਖਿੰਡ ਜਾਂਦਾ ਹੈ। ਜੇਕਰ ਬਾਅਦ ਵਿੱਚ ਪ੍ਰੋਸੈਸਰ ਨੂੰ ਲੌਗਰ (logger), ਕੈਸ਼ ਮੈਨੇਜਰ (cache manager), ਜਾਂ ਕਿਸੇ ਵੱਖਰੇ ਕੌਂਫਿਗਰੇਸ਼ਨ ਫਾਰਮੈਟ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਜਗ੍ਹਾ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਪਵੇਗਾ। ਨਤੀਜੇ ਵਜੋਂ ਅਜਿਹਾ ਨਾਜ਼ੁਕ ਕੋਡ ਬਣਦਾ ਹੈ ਜੋ ਬਦਲਾਅ ਦਾ ਵਿਰੋਧ ਕਰਦਾ ਹੈ ਅਤੇ ਯੂਨਿਟ ਟੈਸਟਾਂ (unit tests) ਵਿੱਚ ਮੌਕ (mock) ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।

Factory Method ਪੈਟਰਨ ਦੀ ਭੂਮਿਕਾ

Factory Method ਪੈਟਰਨ ਸਿੱਧੀ ਇੰਸਟੈਂਸ਼ੀਏਸ਼ਨ (instantiation) ਦੀ ਜਗ੍ਹਾ ਇੱਕ ਅਜਿਹਾ ਮੈਥਡ ਲਿਆਉਂਦਾ ਹੈ ਜੋ ਦਿੱਤੇ ਗਏ ਇੰਟਰਫੇਸ (interface) ਦਾ ਇੱਕ ਇੰਸਟੈਂਸ ਰਿਟਰਨ ਕਰਦਾ ਹੈ। ਕੰਟਰੋਲਰ ਇੰਟਰਫੇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਇੱਕ ਫੈਕਟਰੀ ਕਲਾਸ ਜਾਣਦੀ ਹੈ ਕਿ ਕਿਹੜੀ ਕੰਕਰੀਟ ਕਲਾਸ (concrete class) ਬਣਾਉਣੀ ਹੈ ਅਤੇ ਉਸਦੀਆਂ ਡਿਪੈਂਡੈਂਸੀਆਂ (dependencies) ਨੂੰ ਕਿਵੇਂ ਜੋੜਨਾ ਹੈ। ਸਾਰੀ ਕ੍ਰਿਏਸ਼ਨ ਲੌਜਿਕ ਇੱਕ ਹੀ ਜਗ੍ਹਾ 'ਤੇ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਨਵੀਂ ਡਿਪੈਂਡੈਂਸੀ ਜੋੜਨਾ ਜਾਂ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਬਦਲਣਾ ਸਿਰਫ਼ ਫੈਕਟਰੀ ਨੂੰ ਹੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ।

ਮੁੱਖ ਫਾਇਦੇ

  • ਲੂਜ਼ ਕਪਲਿੰਗ (Loose coupling) – ਕੰਟਰੋਲਰ ਐਬਸਟਰੈਕਸ਼ਨ (abstractions) ਦੇ ਅਧਾਰ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹਨ, ਨਾ ਕਿ ਕੰਕਰੀਟ ਕਲਾਸਾਂ 'ਤੇ।
  • ਕੇਂਦਰੀਕ੍ਰਿਤ ਕੰਸਟ੍ਰਕਸ਼ਨ (Centralized construction) – ਬਿਲਡ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਬਦਲਣ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਫਾਈਲ ਨੂੰ ਐਡਿਟ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
  • ਟੈਸਟੇਬਿਲਟੀ (Testability) – ਫੈਕਟਰੀਆਂ ਨੂੰ ਸਟੱਬ (stub) ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਮੌਕਸ (mocks) ਨਾਲ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਕੰਟਰੋਲਰ ਦੇ ਅਲੱਗ-ਅਲੱਗ ਟੈਸਟ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ।
  • ਓਪਨ/ਕਲੋਜ਼ਡ ਪ੍ਰਿੰਸੀਪਲ (Open/Closed Principle) – ਮੌਜੂਦਾ ਕੰਟਰੋਲਰ ਕੋਡ ਨੂੰ ਛੇੜੇ ਬਿਨਾਂ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ (ਜਿਵੇਂ ਕਿ ਨਵਾਂ ਪੇਮੈਂਟ ਗੇਟਵੇ) ਜੋੜੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ।

ਇੱਕ ਕੌਫੀ-ਸ਼ਾਪ ਦੀ ਉਦਾਹਰਣ

ਇੱਕ ਬੈਰਿਸਟਾ (barista) ਦੀ ਕਲਪਨਾ ਕਰੋ ਜਿਸ ਨੂੰ ਹਰ ਆਰਡਰ ਲਈ if-else ਸਟੇਟਮੈਂਟਾਂ ਦੀ ਇੱਕ ਲੰਬੀ ਲੜੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਬੀਨਜ਼ ਪੀਸਣੇ, ਦੁੱਧ ਗਰਮ ਕਰਨਾ ਅਤੇ ਪਾਣੀ ਪਾਉਣਾ ਪੈਂਦਾ ਹੈ। ਜੇਕਰ ਲੈਟੇ (latte) ਦੀ ਰੈਸਿਪੀ ਬਦਲਦੀ ਹੈ, ਤਾਂ ਹਰ ਬੈਰਿਸਟਾ ਨੂੰ ਸਟੈਪਸ ਦੁਬਾਰਾ ਸਿੱਖਣੇ ਪੈਣਗੇ। ਇੱਕ ਕੌਫੀ ਮਸ਼ੀਨ ਜੋ ਆਰਡਰ ਦੀ ਕਿਸਮ ਪ੍ਰਾਪਤ ਕਰਦੀ ਹੈ ਅਤੇ ਤਿਆਰੀ ਨੂੰ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਸੰਭਾਲਦੀ ਹੈ, ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਦੀ ਹੈ: ਬੈਰਿਸਟਾ ਸਿਰਫ਼ ਮਸ਼ੀਨ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਮਸ਼ੀਨ ਸਾਰੇ ਸਟੈਪਸ ਨੂੰ ਆਪਣੇ ਅੰਦਰ ਸਮੇਟ ਲੈਂਦੀ ਹੈ। ਹੁਣ ਰੈਸਿਪੀ ਨੂੰ ਅਪਡੇਟ ਕਰਨ ਦਾ ਮਤਲਬ ਮਸ਼ੀਨ ਨੂੰ ਐਡਜਸਟ ਕਰਨਾ ਹੈ, ਨਾ ਕਿ ਹਰ ਬੈਰਿਸਟਾ ਨੂੰ।

Laravel ਪਹਿਲਾਂ ਹੀ ਫੈਕਟਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ

Laravel ਦੇ ਆਪਣੇ ਕੋਰ ਕੰਪੋਨੈਂਟਸ ਇਸ ਪੈਟਰਨ ਨੂੰ ਅਮਲੀ ਰੂਪ ਵਿੱਚ ਦਰਸਾਉਂਦੇ ਹਨ:

  • Database – ConnectionFactory ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ MySQL ਜਾਂ PostgreSQL ਕਨੈਕਸ਼ਨ ਬਣਾਉਣਾ ਹੈ।
  • Queues – QueueManager Redis, SQS, ਜਾਂ ਹੋਰ ਬੈਕ-ਐਂਡਾਂ ਲਈ ਡਰਾਈਵਰ ਬਣਾਉਂਦਾ ਹੈ।
  • Filesystem – FilesystemManager ਲੋਕਲ ਜਾਂ S3 ਡਿਸਕ ਇੰਸਟੈਂਸ ਪੈਦਾ ਕਰਦਾ ਹੈ।
  • Mail – MailManager SMTP, Mailgun, ਜਾਂ ਹੋਰ ਮੇਲ ਡਰਾਈਵਰਾਂ ਨੂੰ ਰੈਜ਼ੋਲਵ ਕਰਦਾ ਹੈ।

ਜੇਕਰ ਫਰੇਮਵਰਕ ਇਹਨਾਂ ਮਹੱਤਵਪੂਰਨ ਸੇਵਾਵਾਂ ਲਈ ਫੈਕਟਰੀਆਂ 'ਤੇ ਭਰੋਸਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਕਸਟਮ ਕੋਡ ਨੂੰ ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਫੈਕਟਰੀ ਕਦੋਂ ਲਾਗੂ ਕਰਨੀ ਹੈ

ਫੈਕਟਰੀ ਦੀ ਵਰਤੋਂ ਉਦੋਂ ਕਰੋ ਜਦੋਂ:

  • ਆਬਜੈਕਟ ਕ੍ਰਿਏਸ਼ਨ ਵਿੱਚ ਕਈ ਕੌਂਫਿਗਰੇਸ਼ਨ ਸਟੈਪਸ ਜਾਂ ਬਾਹਰੀ ਸੇਵਾਵਾਂ ਸ਼ਾਮਲ ਹੋਣ।
  • ਕਈ ਇੰਟਰਚੇਂਜੇਬਲ (interchangeable) ਇੰਪਲੀਮੈਂਟੇਸ਼ਨਾਂ ਮੌਜੂਦ ਹੋਣ (ਵੱਖ-ਵੱਖ ਪੇਮੈਂਟ ਗੇਟਵੇ, ਸਟੋਰੇਜ ਪ੍ਰੋਵਾਈਡਰ, ਆਦਿ)।
  • ਸੰਭਵ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨਾਂ ਦੀ ਸੂਚੀ ਵਧਣ ਦੀ ਉਮੀਦ ਹੋਵੇ।

ਫੈਕਟਰੀ ਤੋਂ ਕਦੋਂ ਬਚਣਾ ਹੈ:

  • ਕੰਸਟ੍ਰਕਸ਼ਨ ਇੱਕ ਸਿੰਗਲ, ਅਟੱਲ (immutable) new ਕਾਲ ਹੈ ਜਿਸ ਵਿੱਚ ਕੋਈ ਵਾਧੂ ਸੈੱਟਅੱਪ ਨਹੀਂ ਹੈ।
  • ਸਿਰਫ਼ ਇੱਕ ਹੀ ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਵੇਗੀ, ਜਿਸ ਨਾਲ ਵਾਧੂ ਐਬਸਟਰੈਕਸ਼ਨ ਬੇਲੋੜਾ ਬੋਝ ਬਣ ਜਾਂਦਾ ਹੈ।

ਛੋਟਾ ਜਿਹਾ ਵਾਕ-ਥਰੂ: ਪੇਮੈਂਟ ਕੰਟਰੋਲਰ ਨੂੰ ਰੀਫੈਕਟਰ ਕਰਨਾ

  1. ਇੱਕ ਇੰਟਰਫੇਸ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ – `process(array $

ਫੈਕਟਰੀਆਂ ਦੀ ਮੁੱਖ ਆਲੋਚਨਾ ਵਧਿਆ ਹੋਇਆ ਅਸਿੱਧਾ ਰਸਤਾ (indirection) ਹੈ, ਜੋ ਕਿ ਮਾਮੂਲੀ ਆਬਜੈਕਟਾਂ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੰਬਾ ਮਹਿਸੂਸ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਸਧਾਰਨ ਸਰਵਿਸ ਨੂੰ ਓਵਰ-ਇੰਜੀਨੀਅਰਿੰਗ ਕਰਨਾ ਬਿਨਾਂ ਕਿਸੇ ਅਸਲ ਫਾਇਦੇ ਦੇ ਕੋਡਬੇਸ (codebase) ਨੂੰ ਵਧਾ ਸਕਦਾ ਹੈ। ਮੁੱਖ ਗੱਲ ਉਸਦੇ ਨਿਰਮਾਣ ਦੀ ਗੁੰਝਲਦਾਰਤਾ ਦਾ ਮੁਲਾਂਕਣ ਕਰਨਾ ਹੈ: ਜੇਕਰ ਕੋਈ ਆਬਜੈਕਟ ਬਿਨਾਂ ਕਿਸੇ ਨਿਰਭਰਤਾ (dependencies) ਦੇ ਸਿਰਫ਼ ਇੱਕ ਸਾਧਾਰਨ ਡਾਟਾ ਹੋਲਡਰ ਹੈ, ਤਾਂ ਸਿੱਧਾ new ਵਰਤਣਾ ਸਵੀਕਾਰਯੋਗ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਫੈਕਟਰੀਆਂ ਗੈਰ-ਸੰਬੰਧਿਤ ਲੌਜਿਕ (logic) ਲਈ ਇੱਕ ਡੰਪਿੰਗ ਗਰਾਊਂਡ ਬਣ ਸਕਦੀਆਂ ਹਨ। ਫੈਕਟਰੀਆਂ ਨੂੰ ਸਿਰਫ਼ ਆਬਜੈਕਟ ਬਣਾਉਣ 'ਤੇ ਕੇਂਦਰਿਤ ਰੱਖਣਾ ਅਤੇ ਕੌਂਫਿਗਰੇਸ਼ਨ (configuration) ਨੂੰ ਸਮਰਪਿਤ ਸਰਵਿਸ ਪ੍ਰੋਵਾਈਡਰਾਂ (service providers) ਨੂੰ ਸੌਂਪਣਾ ਸਪਸ਼ਟਤਾ ਬਣਾਈ ਰੱਖਦਾ ਹੈ।

ਅੱਗੇ ਕਿਸ ਚੀਜ਼ ਦਾ ਧਿਆਨ ਰੱਖਣਾ ਹੈ

  • Service container bindings – ਜੇਕਰ ਤੁਸੀਂ ਸਰਵਿਸ ਪ੍ਰੋਵਾਈਡਰ ਵਿੱਚ ਇੰਟਰਫੇਸ (interface) ਨੂੰ ਫੈਕਟਰੀ ਕਲਾਸ ਨਾਲ ਬੰਨ੍ਹਦੇ ਹੋ, ਤਾਂ Laravel ਦਾ ਕੰਟੇਨਰ ਫੈਕਟਰੀਆਂ ਨੂੰ ਆਪਣੇ ਆਪ ਰੈਜ਼ੋਲਵ (resolve) ਕਰ ਸਕਦਾ ਹੈ।
  • Auto-discovery – ਕੁਝ ਪੈਕੇਜ ਆਪਣੀਆਂ ਫੈਕਟਰੀਆਂ ਨੂੰ ਪ੍ਰਗਟ ਕਰਦੇ ਹਨ; ਨਾਮਾਂ ਦੇ ਟਕਰਾਅ (naming collisions) ਤੋਂ ਸੁਚੇਤ ਰਹੋ।
  • Testing strategies – ਕੰਟਰੋਲਰਾਂ ਦੀ ਯੂਨਿਟ ਟੈਸਟਿੰਗ ਕਰਦੇ ਸਮੇਂ, ਫੈਕਟਰੀ ਨੂੰ ਇੱਕ ਮੌਕ (mock) ਨਾਲ ਬਦਲ ਦਿਓ ਜੋ ਇੱਕ ਸਟੱਬਡ ਪ੍ਰੋਸੈਸਰ (stubbed processor) ਵਾਪਸ ਕਰਦਾ ਹੈ, ਤਾਂ ਜੋ ਟੈਸਟ ਤੇਜ਼ ਅਤੇ ਅਲੱਗ-ਥਲੱਗ (isolated) ਰਹਿਣ।

ਨਿਚੋੜ

ਖਿੰਡੀਆਂ ਹੋਈਆਂ new ਕਾਲਾਂ ਨੂੰ ਇੱਕ ਸਹੀ ਜਗ੍ਹਾ 'ਤੇ ਰੱਖੀ ਫੈਕਟਰੀ ਨਾਲ ਬਦਲਣ ਨਾਲ ਨਿਰਮਾਣ ਕੇਂਦਰੀਕ੍ਰਿਤ ਹੋ ਜਾਂਦਾ ਹੈ, ਕਪਲਿੰਗ (coupling) ਘਟਦੀ ਹੈ, ਅਤੇ ਕਸਟਮ ਕੋਡ Laravel ਦੇ ਆਪਣੇ ਡਿਜ਼ਾਈਨ ਫਿਲਾਸਫੀ ਦੇ ਅਨੁਕੂਲ ਹੋ ਜਾਂਦਾ ਹੈ। ਉਹਨਾਂ ਟੀਮਾਂ ਲਈ ਜੋ ਵਿਕਾਸ ਦੀ ਉਮੀਦ ਰੱਖਦੀਆਂ ਹਨ—ਨਵੇਂ ਪੇਮੈਂਟ ਪ੍ਰੋਵਾਈਡਰ, ਸਟੋਰੇਜ ਬੈਕ-ਐਂਡ, ਜਾਂ ਕੋਈ ਵੀ ਪਲੱਗ-ਇਨ-ਸਟਾਈਲ ਕੰਪੋਨੈਂਟ—Factory Method pattern ਇੱਕ ਘੱਟ ਲਾਗਤ ਵਾਲਾ ਨਿਵੇਸ਼ ਹੈ ਜੋ ਲਚਕੀਲੇਪਣ ਅਤੇ ਭਰੋਸੇ ਵਿੱਚ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ। ਤੁਹਾਡਾ ਭਵਿੱਖ ਦਾ ਰੂਪ, ਅਤੇ ਕੋਈ ਵੀ ਜੋ ਇਸ ਕੋਡ ਨੂੰ ਅੱਗੇ ਲਿਜਾਂਦਾ ਹੈ, ਤੁਹਾਡਾ ਧੰਨਵਾਦ ਕਰੇਗਾ।