Laravel ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಿರುವ ಡೆವಲಪರ್‌ಗಳು ತಮ್ಮ ಕಂಟ್ರೋಲರ್‌ಗಳಲ್ಲಿ new ಕೀವರ್ಡ್ ಅನ್ನು ಬಿಟ್ಟುಕೊಟ್ಟು, Factory Method ಪ್ಯಾಟರ್ನ್ ಅನ್ನು ಬಳಸಲು ಸೂಚಿಸಲಾಗುತ್ತಿದೆ. ಆಬ್ಜೆಕ್ಟ್ ಕ್ರಿಯೇಷನ್ ಅನ್ನು ಪ್ರತ್ಯೇಕ ಫ್ಯಾಕ್ಟರಿಗಳಿಗೆ ವರ್ಗಾಯಿಸುವ ಮೂಲಕ, ಕೋಡ್ ಅನ್ನು ವಿಸ್ತರಿಸುವುದು, ಪರೀಕ್ಷಿಸುವುದು ಮತ್ತು ನಿರ್ವಹಿಸುವುದು ಸುಲಭವಾಗುತ್ತದೆ—ಯೋಜನೆಗಳು ಕೆಲವು ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಮೀರಿದಂತೆ ಬೆಳೆದಂತೆ ಈ ಪ್ರಯೋಜನಗಳು ಬಹಳ ಮುಖ್ಯವಾಗುತ್ತವೆ.

new ಕೀವರ್ಡ್ ಏಕೆ ಒಂದು ಗುಪ್ತ ಹೊರೆ (liability)?

ಒಂದು ಕಂಟ್ರೋಲರ್‌ನಲ್ಲಿ ಈ ಕೆಳಗಿನಂತಹ ಸಾಲು ಇದ್ದಾಗ:

$processor = new StripePaymentProcessor($config);

ಆ ಕಂಟ್ರೋಲರ್ ಈಗ StripePaymentProcessor ಕ್ಲಾಸ್‌ಗೆ ಬಿಗಿಯಾಗಿ ಬೆಸೆದಿದೆ (tightly coupled). ಪೇಮೆಂಟ್ ಪ್ರೊಸೆಸರ್ ಅಗತ್ಯವಿರುವ ಪ್ರತಿಯೊಂದು ಸ್ಥಳದಲ್ಲಿ ಆ ಸಾಲನ್ನು ಪುನರಾವರ್ತಿಸಲಾಗುತ್ತದೆ, ಇದರಿಂದ ನಿರ್ಮಾಣ ತರ್ಕವು (construction logic) ಇಡೀ ಕೋಡ್‌ಬೇಸ್‌ನಲ್ಲಿ ಹರಡುತ್ತದೆ. ನಂತರ ಪ್ರೊಸೆಸರ್‌ಗೆ ಲಾಗಿಂಗ್ (logger), ಕ್ಯಾಶ್ ಮ್ಯಾನೇಜರ್ ಅಥವಾ ವಿಭಿನ್ನ ಕಾನ್ಫಿಗರೇಶನ್ ಫಾರ್ಮ್ಯಾಟ್ ಅಗತ್ಯವಿದ್ದರೆ, ಆ ಎಲ್ಲಾ ಸ್ಥಳಗಳನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ ಕೋಡ್ ದುರ್ಬಲವಾಗುತ್ತದೆ, ಬದಲಾವಣೆಗಳಿಗೆ ಒಗ್ಗುವುದಿಲ್ಲ ಮತ್ತು ಯೂನಿಟ್ ಟೆಸ್ಟ್‌ಗಳಲ್ಲಿ ಮಾಕ್ (mock) ಮಾಡುವುದು ಕಷ್ಟವಾಗುತ್ತದೆ.

Factory Method ಪ್ಯಾಟರ್ನ್‌ನ ಪ್ರವೇಶ

Factory Method ಪ್ಯಾಟರ್ನ್ ನೇರ ಇನ್‌ಸ್ಟಾಂಸಿಯೇಷನ್ (direct instantiation) ಬದಲಿಗೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಇಂಟರ್ಫೇಸ್‌ನ ಇನ್‌ಸ್ಟೆನ್ಸ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸುವ ಮೆಥಡ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ಕಂಟ್ರೋಲರ್ ಇಂಟರ್ಫೇಸ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ, ಆದರೆ ಫ್ಯಾಕ್ಟರಿ ಕ್ಲಾಸ್ ಯಾವ ಕಾಂಕ್ರೀಟ್ ಕ್ಲಾಸ್ ಅನ್ನು ನಿರ್ಮಿಸಬೇಕು ಮತ್ತು ಅದರ ಅವಲಂಬನೆಗಳನ್ನು (dependencies) ಹೇಗೆ ಜೋಡಿಸಬೇಕು ಎಂಬುದು ತಿಳಿದಿರುತ್ತದೆ. ಎಲ್ಲಾ ಕ್ರಿಯೇಷನ್ ಲಾಜಿಕ್ ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಇರುವುದರಿಂದ, ಹೊಸ ಅವಲಂಬನೆಯನ್ನು ಸೇರಿಸುವುದು ಅಥವಾ ಇನ್‌ಪ್ಲಿಮೆಂಟೇಶನ್‌ಗಳನ್ನು ಬದಲಾಯಿಸುವುದು ಕೇವಲ ಫ್ಯಾಕ್ಟರಿಯ ಮೇಲೆ ಮಾತ್ರ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ.

ಪ್ರಮುಖ ಪ್ರಯೋಜನಗಳು

  • ಲೂಸ್ ಕಪ್ಲಿಂಗ್ (Loose coupling) – ಕಂಟ್ರೋಲರ್‌ಗಳು ಕಾಂಕ್ರೀಟ್ ಕ್ಲಾಸ್‌ಗಳ ಬದಲಿಗೆ ಅಬ್‌ಸ್ಟ್ರಾಕ್ಷನ್‌ಗಳ (abstractions) ಮೇಲೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ.
  • ಕೇಂದ್ರೀಕೃತ ನಿರ್ಮಾಣ (Centralized construction) – ಬಿಲ್ಡ್ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಬದಲಾಯಿಸಲು ಕೇವಲ ಒಂದು ಫೈಲ್ ಅನ್ನು ಎಡಿಟ್ ಮಾಡಿದರೆ ಸಾಕು.
  • ಪರೀಕ್ಷಿಸುವಿಕೆ (Testability) – ಫ್ಯಾಕ್ಟರಿಗಳನ್ನು ಸ್ಟಬ್ (stub) ಮಾಡಬಹುದು ಅಥವಾ ಮಾಕ್‌ಗಳೊಂದಿಗೆ (mocks) ಬದಲಾಯಿಸಬಹುದು, ಇದು ಪ್ರತ್ಯೇಕ ಕಂಟ್ರೋಲರ್ ಟೆಸ್ಟ್‌ಗಳಿಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
  • ಓಪನ್/ಕ್ಲೋಸ್ಡ್ ಸಿದ್ಧಾಂತ (Open/Closed Principle) – ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕಂಟ್ರೋಲರ್ ಕೋಡ್ ಅನ್ನು ಮುಟ್ಟದೆಯೇ ಹೊಸ ಫೀಚರ್‌ಗಳನ್ನು (ಉದಾಹರಣೆಗೆ, ಹೊಸ ಪೇಮೆಂಟ್ ಗೇಟ್‌ವೇ) ಸೇರಿಸಬಹುದು.

ಕಾಫಿ ಶಾಪ್ ಉದಾಹರಣೆ

ಪ್ರತಿ ಆರ್ಡರ್‌ಗೂ ಬೀನ್ಸ್ ಅರೆಯುವುದು, ಹಾಲು ಸ್ಟೀಮ್ ಮಾಡುವುದು ಮತ್ತು ನೀರನ್ನು ಸುರಿಯುವುದು ಮುಂತಾದ ಕೆಲಸಗಳನ್ನು if-else ಸ್ಟೇಟ್‌ಮೆಂಟ್‌ಗಳ ಉದ್ದನೆಯ ಸರಣಿಯನ್ನು ಬಳಸಿ ಮ್ಯಾನುಯಲ್ ಆಗಿ ಮಾಡಬೇಕಾದ ಬ್ಯಾರಿಸ್ಟಾವನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಒಂದು ವೇಳೆ లాಟೆ (latte) ರೆಸಿಪಿ ಬದಲಾದರೆ, ಪ್ರತಿಯೊಬ್ಬ ಬ್ಯಾರಿಸ್ಟಾ ಕೂಡ ಹಂತಗಳನ್ನು ಮರುಕಲಿತೇಬೇಕು. ಆರ್ಡರ್ ಪ್ರಕಾರವನ್ನು ಸ್ವೀಕರಿಸಿ, ತಯಾರಿಕೆಯನ್ನು ಆಂತರಿಕವಾಗಿ ನಿರ್ವಹಿಸುವ ಕಾಫಿ ಯಂತ್ರವು ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ: ಬ್ಯಾರಿಸ್ಟಾ ಕೇವಲ ಯಂತ್ರಕ್ಕೆ ಏನು ಬೇಕು ಎಂದು ತಿಳಿಸಿದರೆ ಸಾಕು, ಯಂತ್ರವು ಎಲ್ಲಾ ಹಂತಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ (encapsulates). ಈಗ ರೆಸಿಪಿಯನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡುವುದು ಎಂದರೆ ಯಂತ್ರವನ್ನು ಸರಿಪಡಿಸುವುದು ಎಂದರ್ಥವೇ ಹೊರತು ಪ್ರತಿಯೊಬ್ಬ ಬ್ಯಾರಿಸ್ಟಾವನ್ನಲ್ಲ.

Laravel ಈಗಾಗಲೇ ಫ್ಯಾಕ್ಟರಿಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ

Laravel ನ ಕೋರ್ ಘಟಕಗಳು ಈ ಪ್ಯಾಟರ್ನ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತವೆ:

  • Database – ConnectionFactory ಎಂಬುದು MySQL ಅಥವಾ PostgreSQL ಕನೆಕ್ಷನ್ ಅನ್ನು ನಿರ್ಮಿಸಬೇಕೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.
  • Queues – QueueManager Redis, SQS ಅಥವಾ ಇತರ ಬ್ಯಾಕ್-ಎಂಡ್‌ಗಳಿಗಾಗಿ ಡ್ರೈವರ್‌ಗಳನ್ನು ರಚಿಸುತ್ತದೆ.
  • Filesystem – FilesystemManager ಲೋಕಲ್ ಅಥವಾ S3 ಡಿಸ್ಕ್ ಇನ್‌ಸ್ಟೆನ್ಸ್‌ಗಳನ್ನು ನೀಡುತ್ತದೆ.
  • Mail – MailManager SMTP, Mailgun ಅಥವಾ ಇತರ ಮೇಲ್ ಡ್ರೈವರ್‌ಗಳನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.

ಈ ನಿರ್ಣಾಯಕ ಸೇವೆಗಳಿಗಾಗಿ ಫ್ರೇಮ್‌ವರ್ಕ್ ಫ್ಯಾಕ್ಟರಿಗಳನ್ನು ನಂಬುತ್ತಿದ್ದರೆ, ನಮ್ಮ ಕಸ್ಟಮ್ ಕೋಡ್ ಕೂಡ ಅದೇ ಹಾದಿಯನ್ನು ಅನುಸರಿಸಬೇಕು.

ಫ್ಯಾಕ್ಟರಿಯನ್ನು ಯಾವಾಗ ಪರಿಚಯಿಸಬೇಕು?

ಈ ಸಂದರ್ಭಗಳಲ್ಲಿ ಫ್ಯಾಕ್ಟರಿಯನ್ನು ಬಳಸಿ:

  • ಆಬ್ಜೆಕ್ಟ್ ಕ್ರಿಯೇಷನ್‌ನಲ್ಲಿ ಹಲವಾರು ಕಾನ್ಫಿಗರೇಶನ್ ಹಂತಗಳು ಅಥವಾ ಬಾಹ್ಯ ಸೇವೆಗಳು ಒಳಗೊಂಡಿದ್ದಾಗ.
  • ಹಲವಾರು ಬದಲಾಯಿಸಬಹುದಾದ ಇನ್‌ಪ್ಲಿಮೆಂಟೇಶನ್‌ಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದಾಗ (ವಿಭಿನ್ನ ಪೇಮೆಂಟ್ ಗೇಟ್‌ವೇಗಳು, ಸ್ಟೋರೇಜ್ ಪ್ರೊವೈಡರ್‌ಗಳು ಇತ್ಯಾದಿ).
  • ಸಾಧ್ಯವಿರುವ ಇನ್‌ಪ್ಲಿಮೆಂಟೇಶನ್‌ಗಳ ಪಟ್ಟಿ ಬೆಳೆಯುವ ನಿರೀಕ್ಷೆಯಿದ್ದಾಗ.

ಈ ಸಂದರ್ಭಗಳಲ್ಲಿ ಫ್ಯಾಕ್ಟರಿಯನ್ನು ತಪ್ಪಿಸಿ:

  • ನಿರ್ಮಾಣವು ಯಾವುದೇ ಹೆಚ್ಚುವರಿ ಸೆಟಪ್ ಇಲ್ಲದ, ಬದಲಾಯಿಸಲಾಗದ ಏಕೈಕ new ಕರೆಯಾಗಿದ್ದಾಗ.
  • ಕೇವಲ ಒಂದು ಇನ್‌ಪ್ಲಿಮೆಂಟೇಶನ್ ಮಾತ್ರ ಬಳಕೆಯಾಗುವ ಸಾಧ್ಯತೆ ಇದ್ದರೆ, ಅಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಅಬ್‌ಸ್ಟ್ರಾಕ್ಷನ್ ಅನಗತ್ಯ ಹೊರೆಯಾಗುತ್ತದೆ.

ಸಂಕ್ಷಿಪ್ತ ವಿವರಣೆ: ಪೇಮೆಂಟ್ ಕಂಟ್ರೋಲರ್ ಅನ್ನು ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡುವುದು

  1. ಒಂದು ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ – process(array $data) ಮೆಥಡ್ ಹೊಂದಿರುವ PaymentProcessorInterface.
  2. ಕಾಂಕ್ರೀಟ್ ಕ್ಲಾಸ್‌ಗಳನ್ನು ಇನ್‌ಪ್ಲಿಮೆಂಟ್ ಮಾಡಿ – ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಪೂರೈಸುವ StripePaymentProcessor, PayPalPaymentProcessor ಇತ್ಯಾದಿ.
  3. ಒಂದು ಫ್ಯಾಕ್ಟರಿಯನ್ನು ರಚಿಸಿ – make(string $driver): PaymentProcessorInterface ಮೆಥಡ್ ಹೊಂದಿರುವ PaymentProcessorFactory. ಇದರ ಒಳಗಡೆ, ಸೂಕ್ತವಾದ ಕ್ಲಾಸ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸಲು switch ಅಥವಾ ಮ್ಯಾಪ್ ಬಳಸಿ, Laravel ನ ಸರ್ವಿಸ್ ಕಂಟೈನರ್‌ನಿಂದ ಅಗತ್ಯವಿರುವ ಸೇವೆಗಳನ್ನು ಇಂಜೆಕ್ಟ್ ಮಾಡಿ.
  4. ಫ್ಯಾಕ್ಟರಿಯನ್ನು ಇಂಜೆಕ್ಟ್ ಮಾಡಿ – ಕಂಟ್ರೋಲರ್‌ನ ಕನ್ಸ್ಟ್ರಕ್ಟರ್‌ನಲ್ಲಿ, PaymentProcessorFactory ಅನ್ನು ಟೈಪ್-ಹಿಂಟ್ ಮಾಡಿ. Laravel ಇದನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ resolve ಮಾಡುತ್ತದೆ.
  5. ಫ್ಯಾಕ್ಟರಿಯನ್ನು ಬಳಸಿ – $processor = $this->processorFactory->make('stripe'); $processor->process($request->all());

ಈಗ ಕಂಟ್ರೋಲರ್ ಎಂದಿಗೂ new ಅಥವಾ ಕಾಂಕ್ರೀಟ್ ಪ್ರೊಸೆಸರ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸುವುದಿಲ್ಲ. ಹೊಸ ಗೇಟ್‌ವೇ ಅನ್ನು ಸೇರಿಸುವುದು ಎಂದರೆ ಕೇವಲ ಒಂದು ಕ್ಲಾಸ್ ಅನ್ನು ರಚಿಸುವುದು ಮತ್ತು ಫ್ಯಾಕ್ಟರಿಯ ಮ್ಯಾಪ್ ಅನ್ನು ವಿಸ್ತರಿಸುವುದು—ಕಂಟ್ರೋಲರ್‌ನಲ್ಲಿ ಯಾವುದೇ ಬದಲಾವಣೆ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ.

ಸಂಭಾವ್ಯ ಅನಾನುಕೂಲಗಳು ಮತ್ತು ಅವುಗಳನ್ನು ಹೇಗೆ ನಿವಾರಿಸುವುದು

ಫ್ಯಾಕ್ಟರಿಗಳ ಮೇಲಿನ ಪ್ರಮುಖ ಟೀಕೆಯೆಂದರೆ ಹೆಚ್ಚುವರಿ ಪರೋಕ್ಷತೆ (indirection), ಇದು ಸಾಮಾನ್ಯ ವಸ್ತುಗಳಿಗೆ (trivial objects) ಅನಗತ್ಯವಾಗಿ ವಿಸ್ತಾರವಾಗಿ ಕಾಣಿಸಬಹುದು. ಒಂದು ಸರಳ ಸೇವೆಯನ್ನು (service) ಅತಿಯಾಗಿ ಎಂಜಿನಿಯರಿಂಗ್ ಮಾಡುವುದು ಯಾವುದೇ ನೈಜ ಪ್ರಯೋಜನವಿಲ್ಲದೆ ಕೋಡ್ ಬೇಸ್ ಅನ್ನು (codebase) ಹೆಚ್ಚಿಸಬಹುದು. ನಿರ್ಮಾಣದ ಸಂಕೀರ್ಣತೆಯನ್ನು ಅಳೆಯುವುದು ಇಲ್ಲಿ ಮುಖ್ಯವಾಗಿದೆ: ಒಂದು ವಸ್ತುವು ಯಾವುದೇ ಅವಲಂಬನೆಗಳಿಲ್ಲದ (dependencies) ಕೇವಲ ಡೇಟಾ ಹೋಲ್ಡರ್ ಆಗಿದ್ದರೆ, ನೇರ new ಬಳಕೆಯು ಸ್ವೀಕಾರಾರ್ಹವಾಗಿರಬಹುದು. ಅಲ್ಲದೆ, ಫ್ಯಾಕ್ಟರಿಗಳು ಸಂಬಂಧವಿಲ್ಲದ ತರ್ಕಗಳಿಗಾಗಿ (unrelated logic) ಕಸದ ತೊಟ್ಟಿಯಂತಾಗಬಹುದು. ಫ್ಯಾಕ್ಟರಿಗಳನ್ನು ಕೇವಲ ವಸ್ತುಗಳ ರಚನೆಯ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವುದು ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಮೀಸಲಾದ service providers ಗೆ ವಹಿಸಿಕೊಡುವುದು ಸ್ಪಷ್ಟತೆಯನ್ನು ಕಾಪಾಡುತ್ತದೆ.

ಮುಂದೆ ಗಮನಿಸಬೇಕಾದ ಅಂಶಗಳು

  • Service container bindings – ನೀವು service provider ನಲ್ಲಿ interface ಅನ್ನು factory class ಗೆ ಬೈಂಡ್ ಮಾಡಿದರೆ, Laravel ನ container ಫ್ಯಾಕ್ಟರಿಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪರಿಹರಿಸಬಹುದು (resolve).
  • Auto-discovery – ಕೆಲವು ಪ್ಯಾಕೇಜ್‌ಗಳು ತಮ್ಮದೇ ಆದ ಫ್ಯಾಕ್ಟರಿಗಳನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತವೆ; ಹೆಸರಿನ ಸಂಘರ್ಷಗಳ (naming collisions) ಬಗ್ಗೆ ಎಚ್ಚರವಿರಲಿ.
  • Testing strategies – ಕಂಟ್ರೋಲರ್‌ಗಳನ್ನು (controllers) ಯೂನಿಟ್ ಟೆಸ್ಟ್ ಮಾಡುವಾಗ, ಫ್ಯಾಕ್ಟರಿಯನ್ನು stubbed processor ಅನ್ನು ಹಿಂತಿರುಗಿಸುವ ಒಂದು mock ಮೂಲಕ ಬದಲಾಯಿಸಿ, ಇದರಿಂದ ಪರೀಕ್ಷೆಗಳು ವೇಗವಾಗಿ ಮತ್ತು ಪ್ರತ್ಯೇಕವಾಗಿ (isolated) ಇರುತ್ತವೆ.

ಸಾರಾಂಶ

ಚದುರಿಹೋಗಿರುವ new ಕರೆಗಳನ್ನು ಸರಿಯಾದ ಸ್ಥಳದಲ್ಲಿರುವ ಫ್ಯಾಕ್ಟರಿಯಿಂದ ಬದಲಾಯಿಸುವುದು ನಿರ್ಮಾಣವನ್ನು ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ, coupling ಅನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ ಕಸ್ಟಮ್ ಕೋಡ್ ಅನ್ನು Laravel ನ ವಿನ್ಯಾಸ ತತ್ವದೊಂದಿಗೆ (design philosophy) ಹೊಂದಿಸುತ್ತದೆ. ಬೆಳವಣಿಗೆಯನ್ನು ನಿರೀಕ್ಷಿಸುವ ತಂಡಗಳಿಗೆ—ಹೊಸ ಪೇಮೆಂಟ್ ಪ್ರೊವೈಡರ್‌ಗಳು, ಸ್ಟೋರೇಜ್ ಬ್ಯಾಕ್-ಎಂಡ್‌ಗಳು ಅಥವಾ ಯಾವುದೇ ಪ್ಲಗ್-ಇನ್ ಶೈಲಿಯ ಘಟಕಗಳು—Factory Method pattern ಎಂಬುದು ಕಡಿಮೆ ವೆಚ್ಚದ ಹೂಡಿಕೆಯಾಗಿದ್ದು, ಇದು ನಮ್ಯತೆ (flexibility) ಮತ್ತು ಆತ್ಮವಿಶ್ವಾಸವನ್ನು ನೀಡುತ್ತದೆ. ನಿಮ್ಮ ಭವಿಷ್ಯದ ನೀವು ಮತ್ತು ಈ ಕೋಡ್ ಅನ್ನು ಬಳಸುವ ಮುಂದಿನವರು ನಿಮಗೆ ಧನ್ಯವಾದ ಅರ್ಪಿಸುತ್ತಾರೆ.