ಏಕ ಜವಾಬ್ದಾರಿ ತತ್ವ. ತೋರುವಷ್ಟು ಸರಳವಲ್ಲ

ಏಕ ಜವಾಬ್ದಾರಿ ತತ್ವ, ಏಕ ಜವಾಬ್ದಾರಿಯ ತತ್ವ ಎಂದೂ ಕರೆಯುತ್ತಾರೆ,
ಏಕರೂಪದ ವ್ಯತ್ಯಾಸದ ತತ್ವ - ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಅತ್ಯಂತ ಜಾರು ವ್ಯಕ್ತಿ ಮತ್ತು ಪ್ರೋಗ್ರಾಮರ್ ಸಂದರ್ಶನದಲ್ಲಿ ಅಂತಹ ನರಗಳ ಪ್ರಶ್ನೆ.

ಈ ತತ್ವದೊಂದಿಗೆ ನನ್ನ ಮೊದಲ ಗಂಭೀರ ಪರಿಚಯವು ಮೊದಲ ವರ್ಷದ ಆರಂಭದಲ್ಲಿ ನಡೆಯಿತು, ಯುವ ಮತ್ತು ಹಸಿರು ಜನರನ್ನು ಲಾರ್ವಾಗಳಿಂದ ವಿದ್ಯಾರ್ಥಿಗಳನ್ನು ಮಾಡಲು ಕಾಡಿಗೆ ಕರೆದೊಯ್ಯಲಾಯಿತು - ನಿಜವಾದ ವಿದ್ಯಾರ್ಥಿಗಳು.

ಕಾಡಿನಲ್ಲಿ, ನಮ್ಮನ್ನು ತಲಾ 8-9 ಜನರ ಗುಂಪುಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ ಮತ್ತು ಸ್ಪರ್ಧೆಯನ್ನು ನಡೆಸಲಾಯಿತು - ಯಾವ ಗುಂಪು ವೋಡ್ಕಾ ಬಾಟಲಿಯನ್ನು ವೇಗವಾಗಿ ಕುಡಿಯುತ್ತದೆ, ಗುಂಪಿನಿಂದ ಮೊದಲ ವ್ಯಕ್ತಿ ವೋಡ್ಕಾವನ್ನು ಗಾಜಿನೊಳಗೆ ಸುರಿಯುತ್ತಾರೆ, ಎರಡನೆಯವರು ಅದನ್ನು ಕುಡಿಯುತ್ತಾರೆ, ಮತ್ತು ಮೂರನೇ ಒಂದು ಲಘು ಹೊಂದಿದೆ. ಅದರ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಿದ ಘಟಕವು ಗುಂಪಿನ ಸರದಿಯ ಅಂತ್ಯಕ್ಕೆ ಚಲಿಸುತ್ತದೆ.

ಸರದಿಯ ಗಾತ್ರವು ಮೂರರಲ್ಲಿ ಬಹುಸಂಖ್ಯೆಯಿರುವ ಸಂದರ್ಭವು SRP ಯ ಉತ್ತಮ ಅನುಷ್ಠಾನವಾಗಿದೆ.

ವ್ಯಾಖ್ಯಾನ 1. ಏಕ ಜವಾಬ್ದಾರಿ.

ಏಕ ಜವಾಬ್ದಾರಿ ತತ್ವದ (SRP) ಅಧಿಕೃತ ವ್ಯಾಖ್ಯಾನವು ಪ್ರತಿ ಘಟಕವು ತನ್ನದೇ ಆದ ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಅಸ್ತಿತ್ವಕ್ಕೆ ಕಾರಣವನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಅದು ಕೇವಲ ಒಂದು ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ.

"ಕುಡಿಯುವ" ವಸ್ತುವನ್ನು ಪರಿಗಣಿಸಿ (ಟಿಪ್ಲರ್).
SRP ತತ್ವವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು, ನಾವು ಜವಾಬ್ದಾರಿಗಳನ್ನು ಮೂರು ಭಾಗಗಳಾಗಿ ವಿಂಗಡಿಸುತ್ತೇವೆ:

• ಒಬ್ಬರು ಸುರಿಯುತ್ತಾರೆ (ಪೋರ್ ಆಪರೇಷನ್)
• ಒಂದು ಪಾನೀಯ (ಡ್ರಿಂಕ್ಅಪ್ ಆಪರೇಷನ್)
• ಒಬ್ಬನಿಗೆ ತಿಂಡಿ ಇದೆ (ಟೇಕ್‌ಬೈಟ್ ಆಪರೇಷನ್)

ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಭಾಗವಹಿಸುವ ಪ್ರತಿಯೊಬ್ಬರೂ ಪ್ರಕ್ರಿಯೆಯ ಒಂದು ಅಂಶಕ್ಕೆ ಜವಾಬ್ದಾರರಾಗಿರುತ್ತಾರೆ, ಅಂದರೆ, ಒಂದು ಪರಮಾಣು ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿದೆ - ಕುಡಿಯಲು, ಸುರಿಯಲು ಅಥವಾ ಲಘುವಾಗಿ.

ಕುಡಿಯುವ ರಂಧ್ರವು ಈ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಒಂದು ಮುಂಭಾಗವಾಗಿದೆ:

сlass Tippler {
    //...
    void Act(){
        _pourOperation.Do() // налить
        _drinkUpOperation.Do() // выпить
        _takeBiteOperation.Do() // закусить
    }
}

ಯಾಕೆ?

ಮಾನವ ಪ್ರೋಗ್ರಾಮರ್ ಕೋತಿ-ಮನುಷ್ಯನಿಗೆ ಕೋಡ್ ಅನ್ನು ಬರೆಯುತ್ತಾನೆ, ಮತ್ತು ಕೋತಿ-ಮನುಷ್ಯನು ಗಮನಹರಿಸುವುದಿಲ್ಲ, ಮೂರ್ಖನಾಗಿರುತ್ತಾನೆ ಮತ್ತು ಯಾವಾಗಲೂ ಅವಸರದಲ್ಲಿರುತ್ತಾನೆ. ಅವರು ಒಂದೇ ಸಮಯದಲ್ಲಿ 3 - 7 ಪದಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಬಹುದು ಮತ್ತು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬಹುದು.
ಕುಡುಕನ ವಿಷಯದಲ್ಲಿ, ಈ ಮೂರು ಪದಗಳಿವೆ. ಹೇಗಾದರೂ, ನಾವು ಕೋಡ್ ಅನ್ನು ಒಂದು ಹಾಳೆಯಲ್ಲಿ ಬರೆದರೆ, ಅದು ಕೈಗಳು, ಕನ್ನಡಕಗಳು, ಜಗಳಗಳು ಮತ್ತು ರಾಜಕೀಯದ ಬಗ್ಗೆ ಅಂತ್ಯವಿಲ್ಲದ ವಾದಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಮತ್ತು ಇದೆಲ್ಲವೂ ಒಂದು ವಿಧಾನದ ದೇಹದಲ್ಲಿ ಇರುತ್ತದೆ. ನಿಮ್ಮ ಅಭ್ಯಾಸದಲ್ಲಿ ನೀವು ಅಂತಹ ಕೋಡ್ ಅನ್ನು ನೋಡಿದ್ದೀರಿ ಎಂದು ನನಗೆ ಖಾತ್ರಿಯಿದೆ. ಮನಸ್ಸಿಗೆ ಅತ್ಯಂತ ಮಾನವೀಯ ಪರೀಕ್ಷೆಯಲ್ಲ.

ಮತ್ತೊಂದೆಡೆ, ಕೋತಿ ಮನುಷ್ಯನನ್ನು ತನ್ನ ತಲೆಯಲ್ಲಿ ನೈಜ ಪ್ರಪಂಚದ ವಸ್ತುಗಳನ್ನು ಅನುಕರಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಅವನ ಕಲ್ಪನೆಯಲ್ಲಿ, ಅವನು ಅವುಗಳನ್ನು ಒಟ್ಟಿಗೆ ತಳ್ಳಬಹುದು, ಅವುಗಳಿಂದ ಹೊಸ ವಸ್ತುಗಳನ್ನು ಜೋಡಿಸಬಹುದು ಮತ್ತು ಅದೇ ರೀತಿಯಲ್ಲಿ ಅವುಗಳನ್ನು ಡಿಸ್ಅಸೆಂಬಲ್ ಮಾಡಬಹುದು. ಹಳೆಯ ಮಾದರಿಯ ಕಾರನ್ನು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ನಿಮ್ಮ ಕಲ್ಪನೆಯಲ್ಲಿ, ನೀವು ಬಾಗಿಲು ತೆರೆಯಬಹುದು, ಬಾಗಿಲಿನ ಟ್ರಿಮ್ ಅನ್ನು ತಿರುಗಿಸಿ ಮತ್ತು ಅಲ್ಲಿ ವಿಂಡೋ ಲಿಫ್ಟ್ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ನೋಡಬಹುದು, ಅದರೊಳಗೆ ಗೇರ್ಗಳು ಇರುತ್ತವೆ. ಆದರೆ ನೀವು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಯಂತ್ರದ ಎಲ್ಲಾ ಘಟಕಗಳನ್ನು ಒಂದೇ "ಪಟ್ಟಿಯಲ್ಲಿ" ನೋಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಕನಿಷ್ಠ "ಮಂಕಿ ಮ್ಯಾನ್" ಸಾಧ್ಯವಿಲ್ಲ.

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

ಈಗ, SRP ಎನ್ನುವುದು ಒಂದು ತತ್ವವಾಗಿದ್ದು ಅದು ಹೇಗೆ ಕೊಳೆಯುವುದು, ಅಂದರೆ ವಿಭಜಿಸುವ ರೇಖೆಯನ್ನು ಎಲ್ಲಿ ಸೆಳೆಯಬೇಕು ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.

"ಜವಾಬ್ದಾರಿ" ಯ ವಿಭಜನೆಯ ತತ್ವದ ಪ್ರಕಾರ, ಅಂದರೆ, ಕೆಲವು ವಸ್ತುಗಳ ಕಾರ್ಯಗಳ ಪ್ರಕಾರ ಕೊಳೆಯುವುದು ಅವಶ್ಯಕ ಎಂದು ಅವರು ಹೇಳುತ್ತಾರೆ.

ಕುಡಿತಕ್ಕೆ ಹಿಂತಿರುಗೋಣ ಮತ್ತು ಕೊಳೆಯುವ ಸಮಯದಲ್ಲಿ ಕೋತಿ ಮನುಷ್ಯನು ಪಡೆಯುವ ಅನುಕೂಲಗಳು:

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

(ಓಹ್, ಇದು ಈಗಾಗಲೇ OCP ತತ್ವವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ, ಮತ್ತು ನಾನು ಈ ಪೋಸ್ಟ್‌ನ ಜವಾಬ್ದಾರಿಯನ್ನು ಉಲ್ಲಂಘಿಸಿದ್ದೇನೆ)

ಮತ್ತು, ಸಹಜವಾಗಿ, ಅನಾನುಕೂಲಗಳು:

• ನಾವು ಇನ್ನಷ್ಟು ಪ್ರಕಾರಗಳನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ.
• ಕುಡುಕನು ಮೊದಲ ಬಾರಿಗೆ ಅವನು ಕುಡಿಯುವುದಕ್ಕಿಂತ ಒಂದೆರಡು ಗಂಟೆಗಳ ನಂತರ ಕುಡಿಯುತ್ತಾನೆ.

ವ್ಯಾಖ್ಯಾನ 2. ಏಕೀಕೃತ ವ್ಯತ್ಯಾಸ.

ನನಗೆ ಅನುಮತಿಸಿ, ಮಹನೀಯರೇ! ಕುಡಿಯುವ ವರ್ಗವು ಒಂದೇ ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿದೆ - ಅದು ಕುಡಿಯುತ್ತದೆ! ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ, "ಜವಾಬ್ದಾರಿ" ಎಂಬ ಪದವು ಅತ್ಯಂತ ಅಸ್ಪಷ್ಟ ಪರಿಕಲ್ಪನೆಯಾಗಿದೆ. ಮಾನವೀಯತೆಯ ಭವಿಷ್ಯಕ್ಕೆ ಯಾರೋ ಜವಾಬ್ದಾರರು, ಮತ್ತು ಧ್ರುವದಲ್ಲಿ ಉರುಳಿಸಿದ ಪೆಂಗ್ವಿನ್‌ಗಳನ್ನು ಬೆಳೆಸುವ ಜವಾಬ್ದಾರಿ ಯಾರೋ.

ಕುಡಿಯುವವರ ಎರಡು ಅನುಷ್ಠಾನಗಳನ್ನು ಪರಿಗಣಿಸೋಣ. ಮೇಲೆ ತಿಳಿಸಿದ ಮೊದಲನೆಯದು ಮೂರು ವರ್ಗಗಳನ್ನು ಒಳಗೊಂಡಿದೆ - ಸುರಿಯುವುದು, ಕುಡಿಯುವುದು ಮತ್ತು ಲಘು.

ಎರಡನೆಯದನ್ನು "ಫಾರ್ವರ್ಡ್ ಮತ್ತು ಓನ್ಲಿ ಫಾರ್ವರ್ಡ್" ವಿಧಾನದ ಮೂಲಕ ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ವಿಧಾನದಲ್ಲಿನ ಎಲ್ಲಾ ತರ್ಕಗಳನ್ನು ಒಳಗೊಂಡಿದೆ ಆಕ್ಟ್:

//Не тратьте время  на изучение этого класса. Лучше съешьте печеньку
сlass BrutTippler {
   //...
   void Act(){
        // наливаем
    if(!_hand.TryDischarge(from:_bottle, to:_glass, size:_glass.Capacity))
        throw new OverdrunkException();

    // выпиваем
    if(!_hand.TryDrink(from: _glass,  size: _glass.Capacity))
        throw new OverdrunkException();

    //Закусываем
    for(int i = 0; i< 3; i++){
        var food = _foodStore.TakeOrDefault();
        if(food==null)
            throw new FoodIsOverException();

        _hand.TryEat(food);
    }
   }
}

ಈ ಎರಡೂ ವರ್ಗಗಳು, ಹೊರಗಿನ ವೀಕ್ಷಕನ ದೃಷ್ಟಿಕೋನದಿಂದ, ನಿಖರವಾಗಿ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ ಮತ್ತು "ಕುಡಿಯುವ" ಅದೇ ಜವಾಬ್ದಾರಿಯನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ.

ಗೊಂದಲ!

ನಂತರ ನಾವು ಆನ್‌ಲೈನ್‌ಗೆ ಹೋಗಿ SRP ಯ ಮತ್ತೊಂದು ವ್ಯಾಖ್ಯಾನವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತೇವೆ - ಏಕ ಬದಲಾವಣೆಯ ತತ್ವ.

SCP ಹೇಳುತ್ತದೆ "ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಬದಲಾಯಿಸಲು ಒಂದೇ ಒಂದು ಕಾರಣವಿದೆ". ಅಂದರೆ, "ಜವಾಬ್ದಾರಿಯು ಬದಲಾವಣೆಗೆ ಕಾರಣವಾಗಿದೆ."

(ಮೂಲ ವ್ಯಾಖ್ಯಾನದೊಂದಿಗೆ ಬಂದ ವ್ಯಕ್ತಿಗಳು ವಾನರ ಮನುಷ್ಯನ ಟೆಲಿಪಥಿಕ್ ಸಾಮರ್ಥ್ಯಗಳಲ್ಲಿ ವಿಶ್ವಾಸ ಹೊಂದಿದ್ದರು ಎಂದು ತೋರುತ್ತದೆ)

ಈಗ ಎಲ್ಲವೂ ಸ್ಥಳದಲ್ಲಿ ಬೀಳುತ್ತದೆ. ಪ್ರತ್ಯೇಕವಾಗಿ, ನಾವು ಸುರಿಯುವ, ಕುಡಿಯುವ ಮತ್ತು ತಿಂಡಿ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಬದಲಾಯಿಸಬಹುದು, ಆದರೆ ಕುಡಿಯುವವರಲ್ಲಿಯೇ ನಾವು ಕಾರ್ಯಾಚರಣೆಗಳ ಅನುಕ್ರಮ ಮತ್ತು ಸಂಯೋಜನೆಯನ್ನು ಮಾತ್ರ ಬದಲಾಯಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ಕುಡಿಯುವ ಮೊದಲು ಲಘುವನ್ನು ಚಲಿಸುವ ಮೂಲಕ ಅಥವಾ ಟೋಸ್ಟ್ನ ಓದುವಿಕೆಯನ್ನು ಸೇರಿಸುವ ಮೂಲಕ.

"ಫಾರ್ವರ್ಡ್ ಮತ್ತು ಓನ್ಲಿ ಫಾರ್ವರ್ಡ್" ವಿಧಾನದಲ್ಲಿ, ಬದಲಾಯಿಸಬಹುದಾದ ಎಲ್ಲವನ್ನೂ ವಿಧಾನದಲ್ಲಿ ಮಾತ್ರ ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ ಆಕ್ಟ್. ಕಡಿಮೆ ತರ್ಕವಿದ್ದಾಗ ಇದು ಓದಬಲ್ಲ ಮತ್ತು ಪರಿಣಾಮಕಾರಿಯಾಗಿರುತ್ತದೆ ಮತ್ತು ಇದು ಅಪರೂಪವಾಗಿ ಬದಲಾಗಬಹುದು, ಆದರೆ ಆಗಾಗ್ಗೆ ಇದು ಪ್ರತಿಯೊಂದೂ 500 ಸಾಲುಗಳ ಭಯಾನಕ ವಿಧಾನಗಳಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ರಷ್ಯಾ NATO ಗೆ ಸೇರಲು ಅಗತ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ವೇಳೆ-ಹೇಳಿಕೆಗಳೊಂದಿಗೆ.

ವ್ಯಾಖ್ಯಾನ 3. ಬದಲಾವಣೆಗಳ ಸ್ಥಳೀಕರಣ.

ಬೇರೊಬ್ಬರ ಅಪಾರ್ಟ್ಮೆಂಟ್ನಲ್ಲಿ ಏಕೆ ಎಚ್ಚರವಾಯಿತು ಅಥವಾ ಅವರ ಮೊಬೈಲ್ ಫೋನ್ ಎಲ್ಲಿದೆ ಎಂದು ಕುಡಿಯುವವರಿಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಅರ್ಥವಾಗುವುದಿಲ್ಲ. ವಿವರವಾದ ಲಾಗಿಂಗ್ ಅನ್ನು ಸೇರಿಸುವ ಸಮಯ.

ಸುರಿಯುವ ಪ್ರಕ್ರಿಯೆಯೊಂದಿಗೆ ಲಾಗಿಂಗ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸೋಣ:

class PourOperation: IOperation{
    PourOperation(ILogger log /*....*/){/*...*/}
    //...
    void Do(){
        _log.Log($"Before pour with {_hand} and {_bottle}");
        //Pour business logic ...
        _log.Log($"After pour with {_hand} and {_bottle}");
    }
}

ಅದನ್ನು ಒಳಗೊಳ್ಳುವ ಮೂಲಕ ಪೋರ್ ಆಪರೇಷನ್, ನಾವು ಜವಾಬ್ದಾರಿ ಮತ್ತು ಸುತ್ತುವರಿದ ದೃಷ್ಟಿಕೋನದಿಂದ ಬುದ್ಧಿವಂತಿಕೆಯಿಂದ ವರ್ತಿಸಿದ್ದೇವೆ, ಆದರೆ ಈಗ ನಾವು ವ್ಯತ್ಯಾಸದ ತತ್ವದೊಂದಿಗೆ ಗೊಂದಲಕ್ಕೊಳಗಾಗಿದ್ದೇವೆ. ಕಾರ್ಯಾಚರಣೆಯ ಜೊತೆಗೆ, ಅದು ಬದಲಾಗಬಹುದು, ಲಾಗಿಂಗ್ ಸ್ವತಃ ಬದಲಾಗಬಹುದು. ಸುರಿಯುವ ಕಾರ್ಯಾಚರಣೆಗಾಗಿ ನೀವು ಪ್ರತ್ಯೇಕ ಲಾಗರ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸಬೇಕು ಮತ್ತು ರಚಿಸಬೇಕು:

interface IPourLogger{
    void LogBefore(IHand, IBottle){}
    void LogAfter(IHand, IBottle){}
    void OnError(IHand, IBottle, Exception){}
}

class PourOperation: IOperation{
    PourOperation(IPourLogger log /*....*/){/*...*/}
    //...
    void Do(){
        _log.LogBefore(_hand, _bottle);
        try{
             //... business logic
             _log.LogAfter(_hand, _bottle");
        }
        catch(exception e){
            _log.OnError(_hand, _bottle, e)
        }
    }
}

ಸೂಕ್ಷ್ಮ ಓದುಗ ಅದನ್ನು ಗಮನಿಸುತ್ತಾನೆ ಲಾಗ್ಆಫ್ಟರ್, ಮೊದಲು ಲಾಗ್ ಮಾಡಿ и ಒಂದು ದೋಷ ಪ್ರತ್ಯೇಕವಾಗಿ ಬದಲಾಯಿಸಬಹುದು, ಮತ್ತು ಹಿಂದಿನ ಹಂತಗಳೊಂದಿಗೆ ಸಾದೃಶ್ಯದ ಮೂಲಕ, ಮೂರು ವರ್ಗಗಳನ್ನು ರಚಿಸುತ್ತದೆ: PourLoggerBefore, PourLoggerAfter и PourErrorLogger.

ಮತ್ತು ಕುಡಿಯುವವರಿಗೆ ಮೂರು ಕಾರ್ಯಾಚರಣೆಗಳಿವೆ ಎಂದು ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಂಡು, ನಾವು ಒಂಬತ್ತು ಲಾಗಿಂಗ್ ತರಗತಿಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಪರಿಣಾಮವಾಗಿ, ಸಂಪೂರ್ಣ ಕುಡಿಯುವ ವೃತ್ತವು 14 (!!!) ತರಗತಿಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

ಹೈಪರ್ಬೋಲಾ? ಕಷ್ಟದಿಂದ! ಕೊಳೆಯುವ ಗ್ರೆನೇಡ್ ಹೊಂದಿರುವ ಮಂಕಿ ಮ್ಯಾನ್ "ಪೌರರ್" ಅನ್ನು ಡಿಕಾಂಟರ್, ಗ್ಲಾಸ್, ಸುರಿಯುವ ಆಪರೇಟರ್‌ಗಳು, ನೀರು ಸರಬರಾಜು ಸೇವೆ, ಅಣುಗಳ ಘರ್ಷಣೆಯ ಭೌತಿಕ ಮಾದರಿಯಾಗಿ ವಿಭಜಿಸುತ್ತಾನೆ ಮತ್ತು ಮುಂದಿನ ತ್ರೈಮಾಸಿಕದಲ್ಲಿ ಅವನು ಅವಲಂಬನೆಗಳನ್ನು ಬಿಡಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಾನೆ. ಜಾಗತಿಕ ಅಸ್ಥಿರ. ಮತ್ತು ನನ್ನನ್ನು ನಂಬಿರಿ, ಅವನು ನಿಲ್ಲುವುದಿಲ್ಲ.

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

... Srp ನ ಮೂರನೇ ವ್ಯಾಖ್ಯಾನದ ಅಸ್ತಿತ್ವದ ಬಗ್ಗೆ ಎಂದಿಗೂ ಕಲಿಯದೆ:

"ಏಕ ಜವಾಬ್ದಾರಿ ತತ್ವವು ಹೇಳುತ್ತದೆ ಬದಲಾವಣೆಗೆ ಹೋಲುವ ವಸ್ತುಗಳನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಸಂಗ್ರಹಿಸಬೇಕು". ಅಥವಾ "ಯಾವ ಬದಲಾವಣೆಗಳನ್ನು ಒಟ್ಟಿಗೆ ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಇಡಬೇಕು"

ಅಂದರೆ, ನಾವು ಕಾರ್ಯಾಚರಣೆಯ ಲಾಗಿಂಗ್ ಅನ್ನು ಬದಲಾಯಿಸಿದರೆ, ನಾವು ಅದನ್ನು ಒಂದೇ ಸ್ಥಳದಲ್ಲಿ ಬದಲಾಯಿಸಬೇಕು.

ಇದು ಬಹಳ ಮುಖ್ಯವಾದ ಅಂಶವಾಗಿದೆ - ಮೇಲಿನ SRP ಯ ಎಲ್ಲಾ ವಿವರಣೆಗಳು ಪ್ರಕಾರಗಳನ್ನು ಪುಡಿಮಾಡುವಾಗ ಅವುಗಳನ್ನು ಪುಡಿಮಾಡುವುದು ಅಗತ್ಯವೆಂದು ಹೇಳಿರುವುದರಿಂದ, ಅಂದರೆ, ಅವರು ವಸ್ತುವಿನ ಗಾತ್ರದ ಮೇಲೆ "ಮೇಲಿನ ಮಿತಿಯನ್ನು" ವಿಧಿಸಿದ್ದಾರೆ ಮತ್ತು ಈಗ ನಾವು ಈಗಾಗಲೇ "ಕಡಿಮೆ ಮಿತಿ" ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ. ಬೇರೆ ಪದಗಳಲ್ಲಿ, ಎಸ್‌ಆರ್‌ಪಿಗೆ "ಪುಡಿಮಾಡುವಾಗ ಪುಡಿಮಾಡುವುದು" ಮಾತ್ರವಲ್ಲ, ಅದನ್ನು ಅತಿಯಾಗಿ ಮೀರಿಸಬಾರದು - "ಇಂಟರ್‌ಲಾಕ್ ಮಾಡುವ ವಸ್ತುಗಳನ್ನು ಪುಡಿಮಾಡಬೇಡಿ". ಇದು ಓಕಾಮ್‌ನ ರೇಜರ್ ಮತ್ತು ವಾನರ ಮನುಷ್ಯನ ನಡುವಿನ ಮಹಾ ಯುದ್ಧ!

ಈಗ ಕುಡಿಯುವವರು ಉತ್ತಮವಾಗಬೇಕು. IPourLogger ಲಾಗರ್ ಅನ್ನು ಮೂರು ವರ್ಗಗಳಾಗಿ ವಿಭಜಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಎಂಬ ಅಂಶದ ಜೊತೆಗೆ, ನಾವು ಎಲ್ಲಾ ಲಾಗರ್‌ಗಳನ್ನು ಒಂದು ಪ್ರಕಾರವಾಗಿ ಸಂಯೋಜಿಸಬಹುದು:

class OperationLogger{
    public OperationLogger(string operationName){/*..*/}
    public void LogBefore(object[] args){/*...*/}       
    public void LogAfter(object[] args){/*..*/}
    public void LogError(object[] args, exception e){/*..*/}
}

ಮತ್ತು ನಾವು ನಾಲ್ಕನೇ ರೀತಿಯ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಸೇರಿಸಿದರೆ, ಅದರ ಲಾಗಿಂಗ್ ಈಗಾಗಲೇ ಸಿದ್ಧವಾಗಿದೆ. ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಗಳ ಕೋಡ್ ಸ್ವತಃ ಸ್ವಚ್ಛವಾಗಿದೆ ಮತ್ತು ಮೂಲಸೌಕರ್ಯ ಶಬ್ದದಿಂದ ಮುಕ್ತವಾಗಿದೆ.

ಪರಿಣಾಮವಾಗಿ, ಕುಡಿಯುವ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ನಾವು 5 ತರಗತಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ:

• ಸುರಿಯುವ ಕಾರ್ಯಾಚರಣೆ
• ಕುಡಿಯುವ ಕಾರ್ಯಾಚರಣೆ
• ಜ್ಯಾಮಿಂಗ್ ಕಾರ್ಯಾಚರಣೆ
• ಲಾಗರ್
• ಕುಡಿಯುವವರ ಮುಂಭಾಗ

ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಒಂದು ಕಾರ್ಯಚಟುವಟಿಕೆಗೆ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತಾನೆ ಮತ್ತು ಬದಲಾವಣೆಗೆ ಒಂದು ಕಾರಣವನ್ನು ಹೊಂದಿದೆ. ಬದಲಾವಣೆಗೆ ಹೋಲುವ ಎಲ್ಲಾ ನಿಯಮಗಳು ಹತ್ತಿರದಲ್ಲಿವೆ.

ನಿಜ ಜೀವನದ ಉದಾಹರಣೆ

ನಾವು ಒಮ್ಮೆ b2b ಕ್ಲೈಂಟ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನೋಂದಾಯಿಸಲು ಸೇವೆಯನ್ನು ಬರೆದಿದ್ದೇವೆ. ಮತ್ತು ಒಂದೇ ರೀತಿಯ ವಿಷಯದ 200 ಸಾಲುಗಳಿಗಾಗಿ ದೇವರ ವಿಧಾನವು ಕಾಣಿಸಿಕೊಂಡಿದೆ:

• 1C ಗೆ ಹೋಗಿ ಮತ್ತು ಖಾತೆಯನ್ನು ರಚಿಸಿ
• ಈ ಖಾತೆಯೊಂದಿಗೆ, ಪಾವತಿ ಮಾಡ್ಯೂಲ್‌ಗೆ ಹೋಗಿ ಮತ್ತು ಅದನ್ನು ಅಲ್ಲಿ ರಚಿಸಿ
• ಅಂತಹ ಖಾತೆಯನ್ನು ಹೊಂದಿರುವ ಖಾತೆಯನ್ನು ಮುಖ್ಯ ಸರ್ವರ್‌ನಲ್ಲಿ ರಚಿಸಲಾಗಿಲ್ಲ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ
• ಹೊಸ ಖಾತೆಯನ್ನು ತೆರೆ
• ಪಾವತಿ ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿ ನೋಂದಣಿ ಫಲಿತಾಂಶಗಳನ್ನು ಮತ್ತು ನೋಂದಣಿ ಫಲಿತಾಂಶಗಳ ಸೇವೆಗೆ 1c ಸಂಖ್ಯೆಯನ್ನು ಸೇರಿಸಿ
• ಈ ಕೋಷ್ಟಕಕ್ಕೆ ಖಾತೆಯ ಮಾಹಿತಿಯನ್ನು ಸೇರಿಸಿ
• ಪಾಯಿಂಟ್ ಸೇವೆಯಲ್ಲಿ ಈ ಕ್ಲೈಂಟ್‌ಗಾಗಿ ಪಾಯಿಂಟ್ ಸಂಖ್ಯೆಯನ್ನು ರಚಿಸಿ. ಈ ಸೇವೆಗೆ ನಿಮ್ಮ 1c ಖಾತೆ ಸಂಖ್ಯೆಯನ್ನು ರವಾನಿಸಿ.

ಮತ್ತು ಭಯಾನಕ ಸಂಪರ್ಕದೊಂದಿಗೆ ಈ ಪಟ್ಟಿಯಲ್ಲಿ ಸುಮಾರು 10 ವ್ಯಾಪಾರ ಕಾರ್ಯಾಚರಣೆಗಳು ಇದ್ದವು. ಬಹುತೇಕ ಎಲ್ಲರಿಗೂ ಖಾತೆಯ ವಸ್ತುವಿನ ಅಗತ್ಯವಿದೆ. ಅರ್ಧದಷ್ಟು ಕರೆಗಳಲ್ಲಿ ಪಾಯಿಂಟ್ ಐಡಿ ಮತ್ತು ಕ್ಲೈಂಟ್ ಹೆಸರು ಅಗತ್ಯವಿದೆ.

ಒಂದು ಗಂಟೆಯ ಮರುಫಲಕೀಕರಣದ ನಂತರ, ನಾವು ಮೂಲಸೌಕರ್ಯ ಕೋಡ್ ಮತ್ತು ಖಾತೆಯೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಕೆಲವು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಪ್ರತ್ಯೇಕ ವಿಧಾನಗಳು/ವರ್ಗಗಳಾಗಿ ಪ್ರತ್ಯೇಕಿಸಲು ಸಾಧ್ಯವಾಯಿತು. ಗಾಡ್ ವಿಧಾನವು ಅದನ್ನು ಸುಲಭಗೊಳಿಸಿತು, ಆದರೆ 100 ಸಾಲುಗಳ ಕೋಡ್ ಉಳಿದಿದೆ, ಅದು ಬಿಚ್ಚಿಡಲು ಬಯಸುವುದಿಲ್ಲ.

ಕೆಲವೇ ದಿನಗಳ ನಂತರ ಈ "ಹಗುರ" ವಿಧಾನದ ಸಾರವು ವ್ಯಾಪಾರ ಅಲ್ಗಾರಿದಮ್ ಎಂದು ಸ್ಪಷ್ಟವಾಯಿತು. ಮತ್ತು ತಾಂತ್ರಿಕ ವಿಶೇಷಣಗಳ ಮೂಲ ವಿವರಣೆಯು ಸಾಕಷ್ಟು ಸಂಕೀರ್ಣವಾಗಿದೆ. ಮತ್ತು ಈ ವಿಧಾನವನ್ನು ತುಂಡುಗಳಾಗಿ ಒಡೆಯುವ ಪ್ರಯತ್ನವು SRP ಅನ್ನು ಉಲ್ಲಂಘಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಯಾಗಿ ಅಲ್ಲ.

ಔಪಚಾರಿಕತೆ.

ನಮ್ಮ ಕುಡುಕನನ್ನು ಮಾತ್ರ ಬಿಡುವ ಸಮಯ. ನಿಮ್ಮ ಕಣ್ಣೀರನ್ನು ಒಣಗಿಸಿ - ನಾವು ಖಂಡಿತವಾಗಿಯೂ ಒಂದು ದಿನ ಅದಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತೇವೆ. ಈಗ ಈ ಲೇಖನದಿಂದ ಜ್ಞಾನವನ್ನು ಔಪಚಾರಿಕಗೊಳಿಸೋಣ.

ಔಪಚಾರಿಕತೆ 1. SRP ಯ ವ್ಯಾಖ್ಯಾನ

1. ಅಂಶಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ ಇದರಿಂದ ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಒಂದು ವಿಷಯಕ್ಕೆ ಕಾರಣವಾಗಿದೆ.
2. ಜವಾಬ್ದಾರಿ ಎಂದರೆ "ಬದಲಾವಣೆಗೆ ಕಾರಣ". ಅಂದರೆ, ವ್ಯವಹಾರ ತರ್ಕದ ವಿಷಯದಲ್ಲಿ ಪ್ರತಿಯೊಂದು ಅಂಶವು ಬದಲಾವಣೆಗೆ ಒಂದೇ ಒಂದು ಕಾರಣವನ್ನು ಹೊಂದಿದೆ.
3. ವ್ಯಾಪಾರ ತರ್ಕಕ್ಕೆ ಸಂಭಾವ್ಯ ಬದಲಾವಣೆಗಳು. ಸ್ಥಳೀಕರಿಸಬೇಕು. ಸಿಂಕ್ರೊನಸ್ ಆಗಿ ಬದಲಾಗುವ ಅಂಶಗಳು ಹತ್ತಿರದಲ್ಲಿರಬೇಕು.

ಔಪಚಾರಿಕತೆ 2. ಅಗತ್ಯ ಸ್ವಯಂ ಪರೀಕ್ಷೆಯ ಮಾನದಂಡ.

SRP ಅನ್ನು ಪೂರೈಸಲು ನಾನು ಸಾಕಷ್ಟು ಮಾನದಂಡಗಳನ್ನು ನೋಡಿಲ್ಲ. ಆದರೆ ಅಗತ್ಯ ಷರತ್ತುಗಳಿವೆ:

1) ಈ ವರ್ಗ/ವಿಧಾನ/ಮಾಡ್ಯೂಲ್/ಸೇವೆ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವೇ ಕೇಳಿಕೊಳ್ಳಿ. ನೀವು ಸರಳವಾದ ವ್ಯಾಖ್ಯಾನದೊಂದಿಗೆ ಉತ್ತರಿಸಬೇಕು. ( ಧನ್ಯವಾದ ಬ್ರೈಟೋರಿ )

ವಿವರಣೆಗಳು

ಆದಾಗ್ಯೂ, ಕೆಲವೊಮ್ಮೆ ಸರಳವಾದ ವ್ಯಾಖ್ಯಾನವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ತುಂಬಾ ಕಷ್ಟ

2) ದೋಷವನ್ನು ಸರಿಪಡಿಸುವುದು ಅಥವಾ ಹೊಸ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಸೇರಿಸುವುದು ಕನಿಷ್ಠ ಸಂಖ್ಯೆಯ ಫೈಲ್‌ಗಳು/ವರ್ಗಗಳ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ. ತಾತ್ತ್ವಿಕವಾಗಿ - ಒಂದು.

ವಿವರಣೆಗಳು

ಜವಾಬ್ದಾರಿ (ವೈಶಿಷ್ಟ್ಯ ಅಥವಾ ದೋಷಕ್ಕಾಗಿ) ಒಂದು ಫೈಲ್/ಕ್ಲಾಸ್‌ನಲ್ಲಿ ಸುತ್ತುವರಿದಿರುವುದರಿಂದ, ಎಲ್ಲಿ ನೋಡಬೇಕು ಮತ್ತು ಏನನ್ನು ಸಂಪಾದಿಸಬೇಕು ಎಂದು ನಿಮಗೆ ನಿಖರವಾಗಿ ತಿಳಿದಿದೆ. ಉದಾಹರಣೆಗೆ: ಲಾಗಿಂಗ್ ಕಾರ್ಯಾಚರಣೆಗಳ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಬದಲಾಯಿಸುವ ವೈಶಿಷ್ಟ್ಯವು ಲಾಗರ್ ಅನ್ನು ಮಾತ್ರ ಬದಲಾಯಿಸುವ ಅಗತ್ಯವಿದೆ. ಉಳಿದ ಕೋಡ್ ಅನ್ನು ಚಲಾಯಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.

ಇನ್ನೊಂದು ಉದಾಹರಣೆಯೆಂದರೆ ಹಿಂದಿನದನ್ನು ಹೋಲುವ ಹೊಸ UI ನಿಯಂತ್ರಣವನ್ನು ಸೇರಿಸುವುದು. 10 ವಿಭಿನ್ನ ಘಟಕಗಳು ಮತ್ತು 15 ವಿಭಿನ್ನ ಪರಿವರ್ತಕಗಳನ್ನು ಸೇರಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಒತ್ತಾಯಿಸಿದರೆ, ನೀವು ಅದನ್ನು ಅತಿಯಾಗಿ ಮಾಡುತ್ತಿರುವಂತೆ ತೋರುತ್ತಿದೆ.

3) ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್‌ನ ವಿಭಿನ್ನ ವೈಶಿಷ್ಟ್ಯಗಳ ಮೇಲೆ ಹಲವಾರು ಡೆವಲಪರ್‌ಗಳು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ವಿಲೀನ ಸಂಘರ್ಷದ ಸಾಧ್ಯತೆ, ಅಂದರೆ ಒಂದೇ ಫೈಲ್/ಕ್ಲಾಸ್ ಅನ್ನು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಹಲವಾರು ಡೆವಲಪರ್‌ಗಳು ಬದಲಾಯಿಸುವ ಸಾಧ್ಯತೆ ಕಡಿಮೆ.

ವಿವರಣೆಗಳು

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

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

ವಿವರಣೆಗಳು

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

5) ಹೆಸರಿಸುವಿಕೆ ಸ್ಪಷ್ಟವಾಗಿದೆ.

ವಿವರಣೆಗಳು

ನಮ್ಮ ವರ್ಗ ಅಥವಾ ವಿಧಾನವು ಒಂದು ವಿಷಯಕ್ಕೆ ಕಾರಣವಾಗಿದೆ, ಮತ್ತು ಜವಾಬ್ದಾರಿಯು ಅದರ ಹೆಸರಿನಲ್ಲಿ ಪ್ರತಿಫಲಿಸುತ್ತದೆ

AllManagersManagerService - ಹೆಚ್ಚಾಗಿ ದೇವರ ವರ್ಗ
ಸ್ಥಳೀಯ ಪಾವತಿ - ಬಹುಶಃ ಇಲ್ಲ

ಔಪಚಾರಿಕತೆ 3. ಆಕ್ಯಾಮ್-ಮೊದಲ ಅಭಿವೃದ್ಧಿ ವಿಧಾನ.

ವಿನ್ಯಾಸದ ಆರಂಭದಲ್ಲಿ, ಮಂಕಿ ಮ್ಯಾನ್ ತಿಳಿದಿರುವುದಿಲ್ಲ ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುವ ಎಲ್ಲಾ ಸೂಕ್ಷ್ಮತೆಗಳನ್ನು ಅನುಭವಿಸುವುದಿಲ್ಲ ಮತ್ತು ತಪ್ಪು ಮಾಡಬಹುದು. ನೀವು ವಿವಿಧ ರೀತಿಯಲ್ಲಿ ತಪ್ಪುಗಳನ್ನು ಮಾಡಬಹುದು:

• ವಿವಿಧ ಜವಾಬ್ದಾರಿಗಳನ್ನು ವಿಲೀನಗೊಳಿಸುವ ಮೂಲಕ ವಸ್ತುಗಳನ್ನು ತುಂಬಾ ದೊಡ್ಡದಾಗಿಸಿ
• ಒಂದೇ ಜವಾಬ್ದಾರಿಯನ್ನು ವಿವಿಧ ಪ್ರಕಾರಗಳಾಗಿ ವಿಭಜಿಸುವ ಮೂಲಕ ಪುನರ್ನಿರ್ಮಾಣ ಮಾಡುವುದು
• ಜವಾಬ್ದಾರಿಯ ಗಡಿಗಳನ್ನು ತಪ್ಪಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಿ

ನಿಯಮವನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ: "ದೊಡ್ಡ ತಪ್ಪು ಮಾಡುವುದು ಉತ್ತಮ," ಅಥವಾ "ನಿಮಗೆ ಖಚಿತವಿಲ್ಲದಿದ್ದರೆ, ಅದನ್ನು ವಿಭಜಿಸಬೇಡಿ." ಉದಾಹರಣೆಗೆ, ನಿಮ್ಮ ವರ್ಗವು ಎರಡು ಜವಾಬ್ದಾರಿಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದು ಇನ್ನೂ ಅರ್ಥವಾಗುವಂತಹದ್ದಾಗಿದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಕೋಡ್‌ಗೆ ಕನಿಷ್ಠ ಬದಲಾವಣೆಗಳೊಂದಿಗೆ ಎರಡು ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸಬಹುದು. ಹಲವಾರು ಫೈಲ್‌ಗಳಲ್ಲಿ ಹರಡಿರುವ ಸಂದರ್ಭ ಮತ್ತು ಕ್ಲೈಂಟ್ ಕೋಡ್‌ನಲ್ಲಿ ಅಗತ್ಯ ಅವಲಂಬನೆಗಳ ಕೊರತೆಯಿಂದಾಗಿ ಗಾಜಿನ ಚೂರುಗಳಿಂದ ಗಾಜನ್ನು ಜೋಡಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಹೆಚ್ಚು ಕಷ್ಟಕರವಾಗಿರುತ್ತದೆ.

ಇದು ಒಂದು ದಿನ ಎಂದು ಕರೆಯುವ ಸಮಯ

SRP ಯ ವ್ಯಾಪ್ತಿಯು OOP ಮತ್ತು SOLID ಗೆ ಸೀಮಿತವಾಗಿಲ್ಲ. ಇದು ವಿಧಾನಗಳು, ಕಾರ್ಯಗಳು, ತರಗತಿಗಳು, ಮಾಡ್ಯೂಲ್‌ಗಳು, ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳು ಮತ್ತು ಸೇವೆಗಳಿಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಇದು "figax-figax-and-prod" ಮತ್ತು "ರಾಕೆಟ್-ವಿಜ್ಞಾನ" ಅಭಿವೃದ್ಧಿ ಎರಡಕ್ಕೂ ಅನ್ವಯಿಸುತ್ತದೆ, ಇದು ಜಗತ್ತನ್ನು ಎಲ್ಲೆಡೆ ಸ್ವಲ್ಪ ಉತ್ತಮಗೊಳಿಸುತ್ತದೆ. ನೀವು ಅದರ ಬಗ್ಗೆ ಯೋಚಿಸಿದರೆ, ಇದು ಎಲ್ಲಾ ಎಂಜಿನಿಯರಿಂಗ್‌ನ ಮೂಲಭೂತ ತತ್ವವಾಗಿದೆ. ಮೆಕ್ಯಾನಿಕಲ್ ಇಂಜಿನಿಯರಿಂಗ್, ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಗಳು ಮತ್ತು ವಾಸ್ತವವಾಗಿ ಎಲ್ಲಾ ಸಂಕೀರ್ಣ ವ್ಯವಸ್ಥೆಗಳನ್ನು ಘಟಕಗಳಿಂದ ನಿರ್ಮಿಸಲಾಗಿದೆ, ಮತ್ತು "ಅಂಡರ್ಫ್ರಾಗ್ಮೆಂಟೇಶನ್" ವಿನ್ಯಾಸಕಾರರಿಗೆ ನಮ್ಯತೆಯನ್ನು ಕಸಿದುಕೊಳ್ಳುತ್ತದೆ, "ಓವರ್ ಫ್ರಾಗ್ಮೆಂಟೇಶನ್" ವಿನ್ಯಾಸಕಾರರ ದಕ್ಷತೆಯನ್ನು ಕಸಿದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ತಪ್ಪಾದ ಗಡಿಗಳು ಕಾರಣ ಮತ್ತು ಮನಸ್ಸಿನ ಶಾಂತಿಯನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತವೆ.

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

ಮೂಲ: www.habr.com