M

MLOG

ಕನ್ನಡ

ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಡಿಸೈನ್ ಪ್ಯಾಟರ್ನ್‌ಗಳನ್ನು ಬಳಸಿ ದೃಢವಾದ, ಸ್ಕೇಲೆಬಲ್ ಮತ್ತು ನಿರ್ವಹಿಸಬಲ್ಲ ಕೋಡ್ ರಚಿಸಿ. ಜಾಗತಿಕ ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ ಒಂದು ಪ್ರಾಯೋಗಿಕ ಮಾರ್ಗದರ್ಶಿ.

ಸಾಫ್ಟ್‌ವೇರ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ ಪರಿಣತಿ: ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಡಿಸೈನ್ ಪ್ಯಾಟರ್ನ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಒಂದು ಪ್ರಾಯೋಗಿಕ ಮಾರ್ಗದರ್ಶಿ

ಸಾಫ್ಟ್‌ವೇರ್ ಅಭಿವೃದ್ಧಿ ಜಗತ್ತಿನಲ್ಲಿ, ಸಂಕೀರ್ಣತೆಯೇ ಅಂತಿಮ ಎದುರಾಳಿ. ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಬೆಳೆದಂತೆ, ಹೊಸ ಫೀಚರ್‌ಗಳನ್ನು ಸೇರಿಸುವುದು ಒಂದು ಜಟಿಲವಾದ ದಾರಿಯಲ್ಲಿ ಸಾಗಿದಂತೆ ಭಾಸವಾಗಬಹುದು, ಅಲ್ಲಿ ಒಂದು ತಪ್ಪು ತಿರುವು ಬಗ್‌ಗಳ ಮತ್ತು ತಾಂತ್ರಿಕ ಸಾಲದ ಸರಣಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಅನುಭವಿ ಆರ್ಕಿಟೆಕ್ಟ್‌ಗಳು ಮತ್ತು ಇಂಜಿನಿಯರ್‌ಗಳು ಕೇವಲ ಶಕ್ತಿಶಾಲಿಯಾದ, ಆದರೆ ಹೊಂದಿಕೊಳ್ಳುವ, ಸ್ಕೇಲೆಬಲ್ ಮತ್ತು ನಿರ್ವಹಿಸಲು ಸುಲಭವಾದ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸುತ್ತಾರೆ? ಉತ್ತರವು ಸಾಮಾನ್ಯವಾಗಿ ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಡಿಸೈನ್ ಪ್ಯಾಟರ್ನ್‌ಗಳ ಆಳವಾದ ತಿಳುವಳಿಕೆಯಲ್ಲಿದೆ.

ಡಿಸೈನ್ ಪ್ಯಾಟರ್ನ್‌ಗಳು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಕಾಪಿ ಮತ್ತು ಪೇಸ್ಟ್ ಮಾಡಬಹುದಾದ ಸಿದ್ಧ ಕೋಡ್ ಅಲ್ಲ. ಬದಲಾಗಿ, ಅವುಗಳನ್ನು ಉನ್ನತ ಮಟ್ಟದ ನೀಲನಕ್ಷೆಗಳೆಂದು ಯೋಚಿಸಿ—ನಿರ್ದಿಷ್ಟ ಸಾಫ್ಟ್‌ವೇರ್ ವಿನ್ಯಾಸ ಸಂದರ್ಭದಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಸಂಭವಿಸುವ ಸಮಸ್ಯೆಗಳಿಗೆ ಸಾಬೀತಾಗಿರುವ, ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಪರಿಹಾರಗಳು. ಇದೇ ರೀತಿಯ ಸವಾಲುಗಳನ್ನು ಎದುರಿಸಿದ ಅಸಂಖ್ಯಾತ ಡೆವಲಪರ್‌ಗಳ ಸಂಗ್ರಹಿತ ಜ್ಞಾನವನ್ನು ಅವು ಪ್ರತಿನಿಧಿಸುತ್ತವೆ. 1994 ರಲ್ಲಿ ಎರಿಕ್ ಗಾಮಾ, ರಿಚರ್ಡ್ ಹೆಲ್ಮ್, ರಾಲ್ಫ್ ಜಾನ್ಸನ್ ಮತ್ತು ಜಾನ್ ವ್ಲಿಸ್ಸೈಡ್ಸ್ (ಪ್ರಸಿದ್ಧವಾಗಿ "ಗ್ಯಾಂಗ್ ಆಫ್ ಫೋರ್" ಅಥವಾ GoF ಎಂದು ಕರೆಯಲ್ಪಡುವವರು) ಬರೆದ "Design Patterns: Elements of Reusable Object-Oriented Software" ಎಂಬ ಪ್ರಸಿದ್ಧ ಪುಸ್ತಕದಿಂದ ಮೊದಲು ಜನಪ್ರಿಯಗೊಳಿಸಲ್ಪಟ್ಟ ಈ ಪ್ಯಾಟರ್ನ್‌ಗಳು, ಸೊಗಸಾದ ಸಾಫ್ಟ್‌ವೇರ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ರಚಿಸಲು ಒಂದು ಶಬ್ದಕೋಶ ಮತ್ತು ಒಂದು ವ್ಯೂಹಾತ್ಮಕ ಸಾಧನಗಳಾಗಿವೆ.

ಈ ಮಾರ್ಗದರ್ಶಿ ಅಮೂರ್ತ ಸಿದ್ಧಾಂತವನ್ನು ಮೀರಿ ಈ ಅಗತ್ಯ ಪ್ಯಾಟರ್ನ್‌ಗಳ ಪ್ರಾಯೋಗಿಕ ಅನುಷ್ಠಾನದೊಳಗೆ ಧುಮುಕುತ್ತದೆ. ಅವು ಯಾವುವು, ಆಧುನಿಕ ಅಭಿವೃದ್ಧಿ ತಂಡಗಳಿಗೆ (ವಿಶೇಷವಾಗಿ ಜಾಗತಿಕ ತಂಡಗಳಿಗೆ) ಏಕೆ ನಿರ್ಣಾಯಕವಾಗಿವೆ, ಮತ್ತು ಸ್ಪಷ್ಟ, ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆಗಳೊಂದಿಗೆ ಅವುಗಳನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸುವುದು ಎಂಬುದನ್ನು ನಾವು ಅನ್ವೇಷಿಸುತ್ತೇವೆ.

ಜಾಗತಿಕ ಅಭಿವೃದ್ಧಿ ಸಂದರ್ಭದಲ್ಲಿ ಡಿಸೈನ್ ಪ್ಯಾಟರ್ನ್‌ಗಳು ಏಕೆ ಮುಖ್ಯವಾಗಿವೆ

ಇಂದಿನ ಅಂತರ್ಸಂಪರ್ಕಿತ ಜಗತ್ತಿನಲ್ಲಿ, ಅಭಿವೃದ್ಧಿ ತಂಡಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಖಂಡಗಳು, ಸಂಸ್ಕೃತಿಗಳು ಮತ್ತು ಸಮಯ ವಲಯಗಳಲ್ಲಿ ಹರಡಿಕೊಂಡಿವೆ. ಈ ಪರಿಸರದಲ್ಲಿ, ಸ್ಪಷ್ಟ ಸಂವಹನವು ಅತಿಮುಖ್ಯವಾಗಿದೆ. ಇಲ್ಲಿಯೇ ಡಿಸೈನ್ ಪ್ಯಾಟರ್ನ್‌ಗಳು ನಿಜವಾಗಿಯೂ ಹೊಳೆಯುತ್ತವೆ, ಸಾಫ್ಟ್‌ವೇರ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಾಗಿ ಸಾರ್ವತ್ರಿಕ ಭಾಷೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.

ಮೂರು ಆಧಾರಸ್ತಂಭಗಳು: ಡಿಸೈನ್ ಪ್ಯಾಟರ್ನ್‌ಗಳ ವರ್ಗೀಕರಣ

ಗ್ಯಾಂಗ್ ಆಫ್ ಫೋರ್ ತಮ್ಮ 23 ಪ್ಯಾಟರ್ನ್‌ಗಳನ್ನು ಅವುಗಳ ಉದ್ದೇಶದ ಆಧಾರದ ಮೇಲೆ ಮೂರು ಮೂಲಭೂತ ಗುಂಪುಗಳಾಗಿ ವರ್ಗೀಕರಿಸಿದ್ದಾರೆ. ಈ ವರ್ಗಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ನಿರ್ದಿಷ್ಟ ಸಮಸ್ಯೆಗೆ ಯಾವ ಪ್ಯಾಟರ್ನ್ ಬಳಸಬೇಕೆಂದು ಗುರುತಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

  1. ಕ್ರಿಯೇಷನಲ್ ಪ್ಯಾಟರ್ನ್‌ಗಳು: ಈ ಪ್ಯಾಟರ್ನ್‌ಗಳು ವಿವಿಧ ಆಬ್ಜೆಕ್ಟ್ ರಚನಾ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ, ಇದು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕೋಡ್‌ನ ಹೊಂದಿಕೊಳ್ಳುವಿಕೆ ಮತ್ತು ಮರುಬಳಕೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ. ಅವು ಆಬ್ಜೆಕ್ಟ್ ರಚನೆಯ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಭಾಯಿಸುತ್ತವೆ, ಆಬ್ಜೆಕ್ಟ್ ರಚನೆಯ "ಹೇಗೆ" ಎಂಬುದನ್ನು ಅಮೂರ್ತಗೊಳಿಸುತ್ತವೆ.
  2. ಸ್ಟ್ರಕ್ಚರಲ್ ಪ್ಯಾಟರ್ನ್‌ಗಳು: ಈ ಪ್ಯಾಟರ್ನ್‌ಗಳು ಈ ರಚನೆಗಳನ್ನು ಹೊಂದಿಕೊಳ್ಳುವ ಮತ್ತು ದಕ್ಷವಾಗಿರಿಸಿಕೊಂಡು ದೊಡ್ಡ ರಚನೆಗಳಾಗಿ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಮತ್ತು ಕ್ಲಾಸ್‌ಗಳನ್ನು ಹೇಗೆ ಜೋಡಿಸುವುದು ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತವೆ. ಅವು ಕ್ಲಾಸ್ ಮತ್ತು ಆಬ್ಜೆಕ್ಟ್ ಸಂಯೋಜನೆಯ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತವೆ.
  3. ಬಿಹೇವಿಯರಲ್ ಪ್ಯಾಟರ್ನ್‌ಗಳು: ಈ ಪ್ಯಾಟರ್ನ್‌ಗಳು ಅಲ್ಗಾರಿದಮ್‌ಗಳು ಮತ್ತು ಆಬ್ಜೆಕ್ಟ್‌ಗಳ ನಡುವಿನ ಜವಾಬ್ದಾರಿಗಳ ಹಂಚಿಕೆಗೆ ಸಂಬಂಧಿಸಿವೆ. ಅವು ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತವೆ ಮತ್ತು ಜವಾಬ್ದಾರಿಯನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತವೆ.

ಪ್ರತಿ ವರ್ಗದಿಂದ ಕೆಲವು ಅತ್ಯಂತ ಅಗತ್ಯವಾದ ಪ್ಯಾಟರ್ನ್‌ಗಳ ಪ್ರಾಯೋಗಿಕ ಅನುಷ್ಠಾನಗಳೊಳಗೆ ಧುಮುಕೋಣ.

ಆಳವಾದ ನೋಟ: ಕ್ರಿಯೇಷನಲ್ ಪ್ಯಾಟರ್ನ್‌ಗಳ ಅನುಷ್ಠಾನ

ಕ್ರಿಯೇಷನಲ್ ಪ್ಯಾಟರ್ನ್‌ಗಳು ಆಬ್ಜೆಕ್ಟ್ ರಚನೆಯ ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತವೆ, ಈ ಮೂಲಭೂತ ಕಾರ್ಯಾಚರಣೆಯ ಮೇಲೆ ನಿಮಗೆ ಹೆಚ್ಚಿನ ನಿಯಂತ್ರಣವನ್ನು ನೀಡುತ್ತವೆ.

1. ಸಿಂಗಲ್‌ಟನ್ ಪ್ಯಾಟರ್ನ್: ಒಂದೇ, ಮತ್ತು ಕೇವಲ ಒಂದೇ ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸುವುದು

ಸಮಸ್ಯೆ: ಒಂದು ಕ್ಲಾಸ್ ಒಂದೇ ಒಂದು ಇನ್‌ಸ್ಟೆನ್ಸ್ ಅನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಅದಕ್ಕೆ ಜಾಗತಿಕ ಪ್ರವೇಶ ಬಿಂದುವನ್ನು ಒದಗಿಸಬೇಕು ಎಂಬುದನ್ನು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. ಡೇಟಾಬೇಸ್ ಕನೆಕ್ಷನ್ ಪೂಲ್, ಲಾಗರ್, ಅಥವಾ ಕಾನ್ಫಿಗರೇಶನ್ ಮ್ಯಾನೇಜರ್‌ನಂತಹ ಹಂಚಿಕೆಯ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಆಬ್ಜೆಕ್ಟ್‌ಗಳಿಗೆ ಇದು ಸಾಮಾನ್ಯವಾಗಿದೆ.

ಪರಿಹಾರ: ಸಿಂಗಲ್‌ಟನ್ ಪ್ಯಾಟರ್ನ್ ತನ್ನದೇ ಆದ ಇನ್‌ಸ್ಟೆನ್ಶಿಯೇಷನ್‌ಗೆ ಕ್ಲಾಸ್ ಅನ್ನು ಜವಾಬ್ದಾರರನ್ನಾಗಿ ಮಾಡುವ ಮೂಲಕ ಇದನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಇದು ಸಾಮಾನ್ಯವಾಗಿ ನೇರ ರಚನೆಯನ್ನು ತಡೆಯಲು ಪ್ರೈವೇಟ್ ಕನ್ಸ್ಟ್ರಕ್ಟರ್ ಮತ್ತು ಏಕೈಕ ಇನ್‌ಸ್ಟೆನ್ಸ್ ಅನ್ನು ಹಿಂದಿರುಗಿಸುವ ಸ್ಟ್ಯಾಟಿಕ್ ಮೆಥಡ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.

ಪ್ರಾಯೋಗಿಕ ಅನುಷ್ಠಾನ (ಪೈಥಾನ್ ಉದಾಹರಣೆ):

ಒಂದು ಅಪ್ಲಿಕೇಶನ್‌ಗಾಗಿ ಕಾನ್ಫಿಗರೇಶನ್ ಮ್ಯಾನೇಜರ್ ಅನ್ನು ರೂಪಿಸೋಣ. ನಾವು ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಒಂದೇ ಒಂದು ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಮಾತ್ರ ಬಯಸುತ್ತೇವೆ.


class ConfigurationManager:
    _instance = None

    # The __new__ method is called before __init__ when creating an object.
    # We override it to control the creation process.
    def __new__(cls):
        if cls._instance is None:
            print('Creating the one and only instance...')
            cls._instance = super(ConfigurationManager, cls).__new__(cls)
            # Initialize settings here, e.g., load from a file
            cls._instance.settings = {"api_key": "ABC12345", "timeout": 30}
        return cls._instance

    def get_setting(self, key):
        return self.settings.get(key)

# --- Client Code ---
manager1 = ConfigurationManager()
print(f"Manager 1 API Key: {manager1.get_setting('api_key')}")

manager2 = ConfigurationManager()
print(f"Manager 2 API Key: {manager2.get_setting('api_key')}")

# Verify that both variables point to the same object
print(f"Are manager1 and manager2 the same instance? {manager1 is manager2}")

# ಔಟ್‌ಪುಟ್:
# Creating the one and only instance...
# Manager 1 API Key: ABC12345
# Manager 2 API Key: ABC12345
# Are manager1 and manager2 the same instance? True

ಜಾಗತಿಕ ಪರಿಗಣನೆಗಳು: ಮಲ್ಟಿ-ಥ್ರೆಡೆಡ್ ಪರಿಸರದಲ್ಲಿ, ಮೇಲಿನ ಸರಳ ಅನುಷ್ಠಾನವು ವಿಫಲವಾಗಬಹುದು. ಎರಡು ಥ್ರೆಡ್‌ಗಳು ಒಂದೇ ಸಮಯದಲ್ಲಿ `_instance` `None` ಆಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಬಹುದು, ಎರಡೂ ಅದನ್ನು ಸತ್ಯವೆಂದು ಕಂಡುಕೊಳ್ಳಬಹುದು ಮತ್ತು ಎರಡೂ ಒಂದು ಇನ್‌ಸ್ಟೆನ್ಸ್ ಅನ್ನು ರಚಿಸಬಹುದು. ಇದನ್ನು ಥ್ರೆಡ್-ಸುರಕ್ಷಿತವಾಗಿಸಲು, ನೀವು ಲಾಕಿಂಗ್ ಮೆಕ್ಯಾನಿಸಂ ಅನ್ನು ಬಳಸಬೇಕು. ಜಾಗತಿಕವಾಗಿ ನಿಯೋಜಿಸಲಾದ उच्च-ಕಾರ್ಯಕ್ಷಮತೆಯ, ಸಮಕಾಲೀನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಇದು ಒಂದು ನಿರ್ಣಾಯಕ ಪರಿಗಣನೆಯಾಗಿದೆ.

2. ಫ್ಯಾಕ್ಟರಿ ಮೆಥಡ್ ಪ್ಯಾಟರ್ನ್: ಇನ್‌ಸ್ಟೆನ್ಶಿಯೇಷನ್ ಅನ್ನು ನಿಯೋಜಿಸುವುದು

ಸಮಸ್ಯೆ: ನಿಮ್ಮ ಬಳಿ ಒಂದು ಕ್ಲಾಸ್ ಇದೆ, ಅದು ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ, ಆದರೆ ಯಾವ ನಿಖರವಾದ ಕ್ಲಾಸ್‌ನ ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ ಎಂಬುದನ್ನು ಅದು ನಿರೀಕ್ಷಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ನೀವು ಈ ಜವಾಬ್ದಾರಿಯನ್ನು ಅದರ ಸಬ್‌ಕ್ಲಾಸ್‌ಗಳಿಗೆ ನಿಯೋಜಿಸಲು ಬಯಸುತ್ತೀರಿ.

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

ಪ್ರಾಯೋಗಿಕ ಅನುಷ್ಠಾನ (ಪೈಥಾನ್ ಉದಾಹರಣೆ):

ಒಂದು ಲಾಜಿಸ್ಟಿಕ್ಸ್ ಕಂಪನಿಯು ವಿವಿಧ ರೀತಿಯ ಸಾರಿಗೆ ವಾಹನಗಳನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ಕೋರ್ ಲಾಜಿಸ್ಟಿಕ್ಸ್ ಅಪ್ಲಿಕೇಶನ್ ನೇರವಾಗಿ `Truck` ಅಥವಾ `Ship` ಕ್ಲಾಸ್‌ಗಳಿಗೆ ಬದ್ಧವಾಗಿರಬಾರದು.


from abc import ABC, abstractmethod

# The Product Interface
class Transport(ABC):
    @abstractmethod
    def deliver(self, destination):
        pass

# Concrete Products
class Truck(Transport):
    def deliver(self, destination):
        return f"Delivering by land in a truck to {destination}."

class Ship(Transport):
    def deliver(self, destination):
        return f"Delivering by sea in a container ship to {destination}."

# The Creator (Abstract Class)
class Logistics(ABC):
    @abstractmethod
    def create_transport(self) -> Transport:
        pass

    def plan_delivery(self, destination):
        transport = self.create_transport()
        result = transport.deliver(destination)
        print(result)

# Concrete Creators
class RoadLogistics(Logistics):
    def create_transport(self) -> Transport:
        return Truck()

class SeaLogistics(Logistics):
    def create_transport(self) -> Transport:
        return Ship()

# --- Client Code ---
def client_code(logistics_provider: Logistics, destination: str):
    logistics_provider.plan_delivery(destination)

print("App: Launched with Road Logistics.")
client_code(RoadLogistics(), "City Center")

print("\nApp: Launched with Sea Logistics.")
client_code(SeaLogistics(), "International Port")

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

ಆಳವಾದ ನೋಟ: ಸ್ಟ್ರಕ್ಚರಲ್ ಪ್ಯಾಟರ್ನ್‌ಗಳ ಅನುಷ್ಠಾನ

ಸ್ಟ್ರಕ್ಚರಲ್ ಪ್ಯಾಟರ್ನ್‌ಗಳು ದೊಡ್ಡ, ಹೆಚ್ಚು ಹೊಂದಿಕೊಳ್ಳುವ ರಚನೆಗಳನ್ನು ರೂಪಿಸಲು ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಮತ್ತು ಕ್ಲಾಸ್‌ಗಳು ಹೇಗೆ ಸಂಯೋಜಿಸಲ್ಪಡುತ್ತವೆ ಎಂಬುದರ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತವೆ.

1. ಅಡಾಪ್ಟರ್ ಪ್ಯಾಟರ್ನ್: ಹೊಂದಾಣಿಕೆಯಾಗದ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು ಒಟ್ಟಿಗೆ ಕೆಲಸ ಮಾಡುವಂತೆ ಮಾಡುವುದು

ಸಮಸ್ಯೆ: ನೀವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕ್ಲಾಸ್ (`Adaptee`) ಅನ್ನು ಬಳಸಲು ಬಯಸುತ್ತೀರಿ, ಆದರೆ ಅದರ ಇಂಟರ್ಫೇಸ್ ನಿಮ್ಮ ಸಿಸ್ಟಮ್‌ನ ಉಳಿದ ಕೋಡ್‌ನೊಂದಿಗೆ (`Target` ಇಂಟರ್ಫೇಸ್) ಹೊಂದಾಣಿಕೆಯಾಗುವುದಿಲ್ಲ. ಅಡಾಪ್ಟರ್ ಪ್ಯಾಟರ್ನ್ ಒಂದು ಸೇತುವೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಪರಿಹಾರ: ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಕೋಡ್ ನಿರೀಕ್ಷಿಸುವ `Target` ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಒಂದು ವ್ರ್ಯಾಪರ್ ಕ್ಲಾಸ್ (`Adapter`) ಅನ್ನು ರಚಿಸಿ. ಆಂತರಿಕವಾಗಿ, ಅಡಾಪ್ಟರ್ ಟಾರ್ಗೆಟ್ ಇಂಟರ್ಫೇಸ್‌ನಿಂದ ಬರುವ ಕರೆಗಳನ್ನು ಅಡಾಪ್ಟಿಯ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿನ ಕರೆಗಳಾಗಿ ಭಾಷಾಂತರಿಸುತ್ತದೆ. ಇದು ಅಂತರರಾಷ್ಟ್ರೀಯ ಪ್ರಯಾಣಕ್ಕಾಗಿ ಸಾರ್ವತ್ರಿಕ ಪವರ್ ಅಡಾಪ್ಟರ್‌ಗೆ ಸಾಫ್ಟ್‌ವೇರ್ ಸಮಾನವಾಗಿದೆ.

ಪ್ರಾಯೋಗಿಕ ಅನುಷ್ಠಾನ (ಪೈಥಾನ್ ಉದಾಹರಣೆ):

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


# The Target Interface (what our application uses)
class AppLogger:
    def log_message(self, severity, message):
        raise NotImplementedError

# The Adaptee (the third-party library with an incompatible interface)
class ThirdPartyLogger:
    def write_log(self, level, text):
        print(f"ThirdPartyLog [{level.upper()}]: {text}")

# The Adapter
class LoggerAdapter(AppLogger):
    def __init__(self, external_logger: ThirdPartyLogger):
        self._external_logger = external_logger

    def log_message(self, severity, message):
        # Translate the interface
        self._external_logger.write_log(severity, message)

# --- Client Code ---
def run_app_tasks(logger: AppLogger):
    logger.log_message("info", "Application starting up.")
    logger.log_message("error", "Failed to connect to a service.")

# We instantiate the adaptee and wrap it in our adapter
third_party_logger = ThirdPartyLogger()
adapter = LoggerAdapter(third_party_logger)

# Our application can now use the third-party logger via the adapter
run_app_tasks(adapter)

ಜಾಗತಿಕ ಸಂದರ್ಭ: ಈ ಪ್ಯಾಟರ್ನ್ ಜಾಗತೀಕರಣಗೊಂಡ ತಂತ್ರಜ್ಞಾನ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಅನಿವಾರ್ಯವಾಗಿದೆ. ಇದನ್ನು ವಿವಿಧ ಅಂತರರಾಷ್ಟ್ರೀಯ ಪಾವತಿ ಗೇಟ್‌ವೇಗಳು (PayPal, Stripe, Adyen), ಶಿಪ್ಪಿಂಗ್ ಪ್ರೊವೈಡರ್‌ಗಳು, ಅಥವಾ ಪ್ರಾದೇಶಿಕ ಕ್ಲೌಡ್ ಸೇವೆಗಳಂತಹ ಪ್ರತ್ಯೇಕ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ಸಂಯೋಜಿಸಲು ನಿರಂತರವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ, ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಆದ ವಿಶಿಷ್ಟ API ಯನ್ನು ಹೊಂದಿರುತ್ತದೆ.

2. ಡೆಕೋರೇಟರ್ ಪ್ಯಾಟರ್ನ್: ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಜವಾಬ್ದಾರಿಗಳನ್ನು ಸೇರಿಸುವುದು

ಸಮಸ್ಯೆ: ನೀವು ಒಂದು ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ಹೊಸ ಕಾರ್ಯವನ್ನು ಸೇರಿಸಬೇಕಾಗಿದೆ, ಆದರೆ ನೀವು ಇನ್ಹೆರಿಟೆನ್ಸ್ ಬಳಸಲು ಬಯಸುವುದಿಲ್ಲ. ಸಬ್‌ಕ್ಲಾಸಿಂಗ್ ಕಠಿಣವಾಗಿರಬಹುದು ಮತ್ತು ನೀವು ಅನೇಕ ಕಾರ್ಯಗಳನ್ನು ಸಂಯೋಜಿಸಬೇಕಾದರೆ "ಕ್ಲಾಸ್ ಸ್ಫೋಟ"ಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು (ಉದಾ., `CompressedAndEncryptedFileStream` vs. `EncryptedAndCompressedFileStream`).

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

ಪ್ರಾಯೋಗಿಕ ಅನುಷ್ಠಾನ (ಪೈಥಾನ್ ಉದಾಹರಣೆ):

ಒಂದು ಅಧಿಸೂಚನಾ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸೋಣ. ನಾವು ಸರಳ ಅಧಿಸೂಚನೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಿ ನಂತರ ಅದನ್ನು SMS ಮತ್ತು Slack ನಂತಹ ಹೆಚ್ಚುವರಿ ಚಾನಲ್‌ಗಳೊಂದಿಗೆ ಅಲಂಕರಿಸುತ್ತೇವೆ.


# The Component Interface
class Notifier:
    def send(self, message):
        raise NotImplementedError

# The Concrete Component
class EmailNotifier(Notifier):
    def send(self, message):
        print(f"Sending Email: {message}")

# The Base Decorator
class BaseNotifierDecorator(Notifier):
    def __init__(self, wrapped_notifier: Notifier):
        self._wrapped = wrapped_notifier

    def send(self, message):
        self._wrapped.send(message)

# Concrete Decorators
class SMSDecorator(BaseNotifierDecorator):
    def send(self, message):
        super().send(message)
        print(f"Sending SMS: {message}")

class SlackDecorator(BaseNotifierDecorator):
    def send(self, message):
        super().send(message)
        print(f"Sending Slack message: {message}")

# --- Client Code ---
# Start with a basic email notifier
notifier = EmailNotifier()

# Now, let's decorate it to also send an SMS
notifier_with_sms = SMSDecorator(notifier)
print("--- Notifying with Email + SMS ---")
notifier_with_sms.send("System alert: critical failure!")

# Let's add Slack on top of that
full_notifier = SlackDecorator(notifier_with_sms)
print("\n--- Notifying with Email + SMS + Slack ---")
full_notifier.send("System recovered.")

ಕ್ರಿಯಾತ್ಮಕ ಒಳನೋಟ: ಡೆಕೋರೇಟರ್‌ಗಳು ಐಚ್ಛಿಕ ಫೀಚರ್‌ಗಳಿರುವ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಪರಿಪೂರ್ಣವಾಗಿವೆ. ಸ್ಪೆಲ್-ಚೆಕಿಂಗ್, ಸಿಂಟ್ಯಾಕ್ಸ್ ಹೈಲೈಟಿಂಗ್, ಮತ್ತು ಆಟೋ-ಕಂಪ್ಲೀಷನ್‌ನಂತಹ ಫೀಚರ್‌ಗಳನ್ನು ಬಳಕೆದಾರರಿಂದ ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಸೇರಿಸಬಹುದು ಅಥವಾ ತೆಗೆದುಹಾಕಬಹುದಾದ ಟೆಕ್ಸ್ಟ್ ಎಡಿಟರ್ ಬಗ್ಗೆ ಯೋಚಿಸಿ. ಇದು ಹೆಚ್ಚು ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದಾದ ಮತ್ತು ಹೊಂದಿಕೊಳ್ಳುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ರಚಿಸುತ್ತದೆ.

ಆಳವಾದ ನೋಟ: ಬಿಹೇವಿಯರಲ್ ಪ್ಯಾಟರ್ನ್‌ಗಳ ಅನುಷ್ಠಾನ

ಬಿಹೇವಿಯರಲ್ ಪ್ಯಾಟರ್ನ್‌ಗಳು ಆಬ್ಜೆಕ್ಟ್‌ಗಳು ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತವೆ ಮತ್ತು ಜವಾಬ್ದಾರಿಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ ಎಂಬುದರ ಬಗ್ಗೆ ಇವೆ, ಅವುಗಳ ಪರಸ್ಪರ ಕ್ರಿಯೆಗಳನ್ನು ಹೆಚ್ಚು ಹೊಂದಿಕೊಳ್ಳುವ ಮತ್ತು ಸಡಿಲವಾಗಿ ಜೋಡಿಸುತ್ತವೆ.

1. ಅಬ್ಸರ್ವರ್ ಪ್ಯಾಟರ್ನ್: ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ತಿಳಿವಳಿಕೆಯಲ್ಲಿ ಇಡುವುದು

ಸಮಸ್ಯೆ: ನಿಮ್ಮ ಬಳಿ ಆಬ್ಜೆಕ್ಟ್‌ಗಳ ನಡುವೆ ಒಂದರಿಂದ-ಅನೇಕಕ್ಕೆ ಸಂಬಂಧವಿದೆ. ಒಂದು ಆಬ್ಜೆಕ್ಟ್ (`Subject`) ತನ್ನ ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸಿದಾಗ, ಅದರ ಎಲ್ಲಾ ಅವಲಂಬಿತರು (`Observers`) ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸೂಚನೆ ಪಡೆಯಬೇಕು ಮತ್ತು ಅಪ್‌ಡೇಟ್ ಆಗಬೇಕು, ಸಬ್ಜೆಕ್ಟ್ ಅಬ್ಸರ್ವರ್‌ಗಳ ಕಾಂಕ್ರೀಟ್ ಕ್ಲಾಸ್‌ಗಳ ಬಗ್ಗೆ ತಿಳಿದುಕೊಳ್ಳುವ ಅಗತ್ಯವಿಲ್ಲದೆ.

ಪರಿಹಾರ: `Subject` ಆಬ್ಜೆಕ್ಟ್ ತನ್ನ `Observer` ಆಬ್ಜೆಕ್ಟ್‌ಗಳ ಪಟ್ಟಿಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ಅಬ್ಸರ್ವರ್‌ಗಳನ್ನು ಲಗತ್ತಿಸಲು ಮತ್ತು ಬೇರ್ಪಡಿಸಲು ಮೆಥಡ್‌ಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಸ್ಥಿತಿ ಬದಲಾವಣೆಯಾದಾಗ, ಸಬ್ಜೆಕ್ಟ್ ತನ್ನ ಅಬ್ಸರ್ವರ್‌ಗಳ ಮೂಲಕ ಪುನರಾವರ್ತಿಸಿ ಪ್ರತಿಯೊಂದರ ಮೇಲೆ `update` ಮೆಥಡ್ ಅನ್ನು ಕರೆಯುತ್ತದೆ.

ಪ್ರಾಯೋಗಿಕ ಅನುಷ್ಠಾನ (ಪೈಥಾನ್ ಉದಾಹರಣೆ):

ಒಂದು ಸುದ್ದಿ ಸಂಸ್ಥೆ (ಸಬ್ಜೆಕ್ಟ್) ವಿವಿಧ ಮಾಧ್ಯಮಗಳಿಗೆ (ಅಬ್ಸರ್ವರ್‌ಗಳು) ಸುದ್ದಿ ಫ್ಲ್ಯಾಶ್‌ಗಳನ್ನು ಕಳುಹಿಸುವುದು ಒಂದು ಶ್ರೇಷ್ಠ ಉದಾಹರಣೆಯಾಗಿದೆ.


# The Subject (or Publisher)
class NewsAgency:
    def __init__(self):
        self._observers = []
        self._latest_news = None

    def attach(self, observer):
        self._observers.append(observer)

    def detach(self, observer):
        self._observers.remove(observer)

    def notify(self):
        for observer in self._observers:
            observer.update(self)

    def add_news(self, news):
        self._latest_news = news
        self.notify()

    def get_news(self):
        return self._latest_news

# The Observer Interface
class Observer(ABC):
    @abstractmethod
    def update(self, subject: NewsAgency):
        pass

# Concrete Observers
class Website(Observer):
    def update(self, subject: NewsAgency):
        news = subject.get_news()
        print(f"Website Display: Breaking News! {news}")

class NewsChannel(Observer):
    def update(self, subject: NewsAgency):
        news = subject.get_news()
        print(f"Live TV Ticker: ++ {news} ++")

# --- Client Code ---
agency = NewsAgency()

website = Website()
agency.attach(website)

news_channel = NewsChannel()
agency.attach(news_channel)

agency.add_news("Global markets surge on new tech announcement.")

agency.detach(website)
print("\n--- Website has unsubscribed ---")
agency.add_news("Local weather update: Heavy rain expected.")

ಜಾಗತಿಕ ಪ್ರಸ್ತುತತೆ: ಅಬ್ಸರ್ವರ್ ಪ್ಯಾಟರ್ನ್ ಈವೆಂಟ್-ಚಾಲಿತ ಆರ್ಕಿಟೆಕ್ಚರ್‌ಗಳು ಮತ್ತು ರಿಯಾಕ್ಟಿವ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನ ಬೆನ್ನೆಲುಬಾಗಿದೆ. ಇದು ಆಧುನಿಕ ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್‌ಗಳನ್ನು (ಉದಾ., React ಅಥವಾ Angular ನಂತಹ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ), ರಿಯಲ್-ಟೈಮ್ ಡೇಟಾ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು, ಮತ್ತು ಜಾಗತಿಕ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಶಕ್ತಿ ನೀಡುವ ಹಂಚಿಕೆಯ ಈವೆಂಟ್-ಸೋರ್ಸಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಲು ಮೂಲಭೂತವಾಗಿದೆ.

2. ಸ್ಟ್ರಾಟಜಿ ಪ್ಯಾಟರ್ನ್: ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಒಳಸೇರಿಸುವುದು

ಸಮಸ್ಯೆ: ನಿಮ್ಮ ಬಳಿ ಸಂಬಂಧಿತ ಅಲ್ಗಾರಿದಮ್‌ಗಳ ಒಂದು ಕುಟುಂಬವಿದೆ (ಉದಾ., ಡೇಟಾವನ್ನು ವಿಂಗಡಿಸಲು ಅಥವಾ ಮೌಲ್ಯವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ವಿಭಿನ್ನ ವಿಧಾನಗಳು), ಮತ್ತು ನೀವು ಅವುಗಳನ್ನು ಪರಸ್ಪರ ಬದಲಾಯಿಸಲು ಬಯಸುತ್ತೀರಿ. ಈ ಅಲ್ಗಾರಿದಮ್‌ಗಳನ್ನು ಬಳಸುವ ಕ್ಲೈಂಟ್ ಕೋಡ್ ಯಾವುದೇ ನಿರ್ದಿಷ್ಟ ಒಂದಕ್ಕೆ ಬಿಗಿಯಾಗಿ ಜೋಡಿಸಬಾರದು.

ಪರಿಹಾರ: ಎಲ್ಲಾ ಅಲ್ಗಾರಿದಮ್‌ಗಳಿಗಾಗಿ ಒಂದು ಸಾಮಾನ್ಯ ಇಂಟರ್ಫೇಸ್ (`Strategy`) ಅನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ. ಕ್ಲೈಂಟ್ ಕ್ಲಾಸ್ (`Context`) ಸ್ಟ್ರಾಟಜಿ ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ಒಂದು ಉಲ್ಲೇಖವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಕಾಂಟೆಕ್ಸ್ಟ್ ಸ್ವತಃ ನಡವಳಿಕೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಬದಲು ಕೆಲಸವನ್ನು ಸ್ಟ್ರಾಟಜಿ ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ನಿಯೋಜಿಸುತ್ತದೆ. ಇದು ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ರನ್‌ಟೈಮ್‌ನಲ್ಲಿ ಆಯ್ಕೆ ಮಾಡಲು ಮತ್ತು ಬದಲಾಯಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

ಪ್ರಾಯೋಗಿಕ ಅನುಷ್ಠಾನ (ಪೈಥಾನ್ ಉದಾಹರಣೆ):

ವಿವಿಧ ಅಂತರರಾಷ್ಟ್ರೀಯ ಕ್ಯಾರಿಯರ್‌ಗಳ ಆಧಾರದ ಮೇಲೆ ಶಿಪ್ಪಿಂಗ್ ವೆಚ್ಚಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಬೇಕಾದ ಇ-ಕಾಮರ್ಸ್ ಚೆಕ್‌ಔಟ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಪರಿಗಣಿಸಿ.


# The Strategy Interface
class ShippingStrategy(ABC):
    @abstractmethod
    def calculate(self, order_weight_kg):
        pass

# Concrete Strategies
class ExpressShipping(ShippingStrategy):
    def calculate(self, order_weight_kg):
        return order_weight_kg * 5.0 # $5.00 per kg

class StandardShipping(ShippingStrategy):
    def calculate(self, order_weight_kg):
        return order_weight_kg * 2.5 # $2.50 per kg

class InternationalShipping(ShippingStrategy):
    def calculate(self, order_weight_kg):
        return 15.0 + (order_weight_kg * 7.0) # $15.00 base + $7.00 per kg

# The Context
class Order:
    def __init__(self, weight, shipping_strategy: ShippingStrategy):
        self.weight = weight
        self._strategy = shipping_strategy

    def set_strategy(self, shipping_strategy: ShippingStrategy):
        self._strategy = shipping_strategy

    def get_shipping_cost(self):
        cost = self._strategy.calculate(self.weight)
        print(f"Order weight: {self.weight}kg. Strategy: {self._strategy.__class__.__name__}. Cost: ${cost:.2f}")
        return cost

# --- Client Code ---
order = Order(weight=2, shipping_strategy=StandardShipping())
order.get_shipping_cost()

print("\nCustomer wants faster shipping...")
order.set_strategy(ExpressShipping())
order.get_shipping_cost()

print("\nShipping to another country...")
order.set_strategy(InternationalShipping())
order.get_shipping_cost()

ಕ್ರಿಯಾತ್ಮಕ ಒಳನೋಟ: ಈ ಪ್ಯಾಟರ್ನ್ ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ವಿನ್ಯಾಸದ SOLID ತತ್ವಗಳಲ್ಲಿ ಒಂದಾದ ಓಪನ್/ಕ್ಲೋಸ್ಡ್ ಪ್ರಿನ್ಸಿಪಲ್ ಅನ್ನು ಬಲವಾಗಿ ಪ್ರೋತ್ಸಾಹಿಸುತ್ತದೆ. `Order` ಕ್ಲಾಸ್ ವಿಸ್ತರಣೆಗಾಗಿ ತೆರೆದಿದೆ (ನೀವು `DroneDelivery` ನಂತಹ ಹೊಸ ಶಿಪ್ಪಿಂಗ್ ಸ್ಟ್ರಾಟಜಿಗಳನ್ನು ಸೇರಿಸಬಹುದು) ಆದರೆ ಮಾರ್ಪಾಡಿಗಾಗಿ ಮುಚ್ಚಿದೆ (ನೀವು ಎಂದಿಗೂ `Order` ಕ್ಲಾಸ್ ಅನ್ನು ಬದಲಾಯಿಸಬೇಕಾಗಿಲ್ಲ). ಹೊಸ ಲಾಜಿಸ್ಟಿಕ್ಸ್ ಪಾಲುದಾರರು ಮತ್ತು ಪ್ರಾದೇಶಿಕ ಬೆಲೆ ನಿಯಮಗಳಿಗೆ ನಿರಂತರವಾಗಿ ಹೊಂದಿಕೊಳ್ಳಬೇಕಾದ ದೊಡ್ಡ, ವಿಕಸಿಸುತ್ತಿರುವ ಇ-ಕಾಮರ್ಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗಳಿಗೆ ಇದು ಅತ್ಯಗತ್ಯ.

ಡಿಸೈನ್ ಪ್ಯಾಟರ್ನ್‌ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು

ಶಕ್ತಿಶಾಲಿಯಾಗಿದ್ದರೂ, ಡಿಸೈನ್ ಪ್ಯಾಟರ್ನ್‌ಗಳು ಸರ್ವರೋಗ ನಿವಾರಕವಲ್ಲ. ಅವುಗಳನ್ನು ದುರುಪಯೋಗಪಡಿಸಿಕೊಳ್ಳುವುದು ಅತಿಯಾಗಿ ಇಂಜಿನಿಯರಿಂಗ್ ಮಾಡಲಾದ ಮತ್ತು ಅನಗತ್ಯವಾಗಿ ಸಂಕೀರ್ಣವಾದ ಕೋಡ್‌ಗೆ ಕಾರಣವಾಗಬಹುದು. ಇಲ್ಲಿ ಕೆಲವು ಮಾರ್ಗದರ್ಶಿ ತತ್ವಗಳಿವೆ:

ತೀರ್ಮಾನ: ನೀಲನಕ್ಷೆಯಿಂದ ಮೇರುಕೃತಿಯವರೆಗೆ

ಆಬ್ಜೆಕ್ಟ್-ಓರಿಯೆಂಟೆಡ್ ಡಿಸೈನ್ ಪ್ಯಾಟರ್ನ್‌ಗಳು ಕೇವಲ ಶೈಕ್ಷಣಿಕ ಪರಿಕಲ್ಪನೆಗಳಿಗಿಂತ ಹೆಚ್ಚಾಗಿವೆ; ಅವು ಕಾಲದ ಪರೀಕ್ಷೆಯನ್ನು ತಡೆದುಕೊಳ್ಳುವ ಸಾಫ್ಟ್‌ವೇರ್ ನಿರ್ಮಿಸಲು ಒಂದು ಪ್ರಾಯೋಗಿಕ ಸಾಧನಗಳಾಗಿವೆ. ಅವು ಜಾಗತಿಕ ತಂಡಗಳಿಗೆ ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸಹಯೋಗಿಸಲು ಅಧಿಕಾರ ನೀಡುವ ಸಾಮಾನ್ಯ ಭಾಷೆಯನ್ನು ಒದಗಿಸುತ್ತವೆ, ಮತ್ತು ಅವು ಸಾಫ್ಟ್‌ವೇರ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಪುನರಾವರ್ತಿತ ಸವಾಲುಗಳಿಗೆ ಸಾಬೀತಾದ ಪರಿಹಾರಗಳನ್ನು ನೀಡುತ್ತವೆ. ಕಾಂಪೊನೆಂಟ್‌ಗಳನ್ನು ಬೇರ್ಪಡಿಸುವ ಮೂಲಕ, ಹೊಂದಿಕೊಳ್ಳುವಿಕೆಯನ್ನು ಉತ್ತೇಜಿಸುವ ಮೂಲಕ, ಮತ್ತು ಸಂಕೀರ್ಣತೆಯನ್ನು ನಿರ್ವಹಿಸುವ ಮೂಲಕ, ಅವು ದೃಢವಾದ, ಸ್ಕೇಲೆಬಲ್, ಮತ್ತು ನಿರ್ವಹಿಸಬಲ್ಲ ಸಿಸ್ಟಮ್‌ಗಳ ರಚನೆಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುತ್ತವೆ.

ಈ ಪ್ಯಾಟರ್ನ್‌ಗಳಲ್ಲಿ ಪರಿಣತಿ ಹೊಂದುವುದು ಒಂದು ಪ್ರಯಾಣ, ಗಮ್ಯವಲ್ಲ. ನೀವು ಪ್ರಸ್ತುತ ಎದುರಿಸುತ್ತಿರುವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಒಂದು ಅಥವಾ ಎರಡು ಪ್ಯಾಟರ್ನ್‌ಗಳನ್ನು ಗುರುತಿಸುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಿ. ಅವುಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ, ಅವುಗಳ ಪ್ರಭಾವವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ, ಮತ್ತು ಕ್ರಮೇಣ ನಿಮ್ಮ ಜ್ಞಾನಭಂಡಾರವನ್ನು ವಿಸ್ತರಿಸಿ. ಆರ್ಕಿಟೆಕ್ಚರಲ್ ಜ್ಞಾನದಲ್ಲಿನ ಈ ಹೂಡಿಕೆಯು ಒಬ್ಬ ಡೆವಲಪರ್ ಮಾಡಬಹುದಾದ ಅತ್ಯಂತ ಮೌಲ್ಯಯುತವಾದ ಹೂಡಿಕೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ, ಇದು ನಮ್ಮ ಸಂಕೀರ್ಣ ಮತ್ತು ಅಂತರ್ಸಂಪರ್ಕಿತ ಡಿಜಿಟಲ್ ಜಗತ್ತಿನಲ್ಲಿ ವೃತ್ತಿಜೀವನದುದ್ದಕ್ಕೂ ಲಾಭಾಂಶವನ್ನು ನೀಡುತ್ತದೆ.