ਸਿੰਗਲ ਜ਼ਿੰਮੇਵਾਰੀ ਸਿਧਾਂਤ। ਇੰਨਾ ਸਧਾਰਨ ਨਹੀਂ ਜਿੰਨਾ ਇਹ ਲੱਗਦਾ ਹੈ

ਸਿੰਗਲ ਜਿੰਮੇਵਾਰੀ ਸਿਧਾਂਤ, ਜਿਸਨੂੰ ਸਿੰਗਲ ਜਿੰਮੇਵਾਰੀ ਦਾ ਸਿਧਾਂਤ ਵੀ ਕਿਹਾ ਜਾਂਦਾ ਹੈ,
ਇਕਸਾਰ ਪਰਿਵਰਤਨਸ਼ੀਲਤਾ ਦਾ ਸਿਧਾਂਤ - ਸਮਝਣ ਲਈ ਇੱਕ ਬਹੁਤ ਹੀ ਤਿਲਕਣ ਵਾਲਾ ਮੁੰਡਾ ਅਤੇ ਇੱਕ ਪ੍ਰੋਗਰਾਮਰ ਇੰਟਰਵਿਊ ਵਿੱਚ ਅਜਿਹਾ ਘਬਰਾਹਟ ਵਾਲਾ ਸਵਾਲ।

ਇਸ ਸਿਧਾਂਤ ਨਾਲ ਮੇਰੀ ਪਹਿਲੀ ਗੰਭੀਰ ਜਾਣ-ਪਛਾਣ ਮੇਰੇ ਪਹਿਲੇ ਸਾਲ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਹੋਈ, ਜਦੋਂ ਜਵਾਨ ਅਤੇ ਹਰੇ ਬੱਚਿਆਂ ਨੂੰ ਲਾਰਵੇ ਤੋਂ ਅਸਲ ਵਿਦਿਆਰਥੀ ਬਣਾਉਣ ਲਈ ਜੰਗਲ ਵਿੱਚ ਲਿਜਾਇਆ ਗਿਆ।

ਜੰਗਲ ਵਿੱਚ, ਸਾਨੂੰ 8-9 ਵਿਅਕਤੀਆਂ ਦੇ ਸਮੂਹਾਂ ਵਿੱਚ ਵੰਡਿਆ ਗਿਆ ਸੀ ਅਤੇ ਇੱਕ ਮੁਕਾਬਲਾ ਸੀ - ਕਿਹੜਾ ਸਮੂਹ ਵੋਡਕਾ ਦੀ ਇੱਕ ਬੋਤਲ ਸਭ ਤੋਂ ਤੇਜ਼ ਪੀਵੇਗਾ, ਬਸ਼ਰਤੇ ਕਿ ਸਮੂਹ ਵਿੱਚੋਂ ਪਹਿਲਾ ਵਿਅਕਤੀ ਇੱਕ ਗਲਾਸ ਵਿੱਚ ਵੋਡਕਾ ਪਾਵੇ, ਦੂਜਾ ਇਸਨੂੰ ਪੀਵੇ, ਅਤੇ ਤੀਜੇ ਕੋਲ ਸਨੈਕ ਹੈ। ਯੂਨਿਟ ਜਿਸ ਨੇ ਆਪਣਾ ਕੰਮ ਪੂਰਾ ਕਰ ਲਿਆ ਹੈ, ਉਹ ਸਮੂਹ ਦੀ ਕਤਾਰ ਦੇ ਅੰਤ ਤੱਕ ਚਲੀ ਜਾਂਦੀ ਹੈ।

ਕੇਸ ਜਿੱਥੇ ਕਤਾਰ ਦਾ ਆਕਾਰ ਤਿੰਨ ਦਾ ਗੁਣਜ ਸੀ, ਐਸਆਰਪੀ ਦਾ ਇੱਕ ਵਧੀਆ ਲਾਗੂਕਰਨ ਸੀ।

ਪਰਿਭਾਸ਼ਾ 1. ਸਿੰਗਲ ਜ਼ਿੰਮੇਵਾਰੀ।

ਸਿੰਗਲ ਜ਼ਿੰਮੇਵਾਰੀ ਸਿਧਾਂਤ (SRP) ਦੀ ਅਧਿਕਾਰਤ ਪਰਿਭਾਸ਼ਾ ਦੱਸਦੀ ਹੈ ਕਿ ਹਰੇਕ ਇਕਾਈ ਦੀ ਆਪਣੀ ਜ਼ਿੰਮੇਵਾਰੀ ਅਤੇ ਹੋਂਦ ਦਾ ਕਾਰਨ ਹੈ, ਅਤੇ ਇਸਦੀ ਸਿਰਫ ਇੱਕ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ।

ਆਬਜੈਕਟ "ਡਰਿੰਕਰ" ਤੇ ਵਿਚਾਰ ਕਰੋ (ਟਿੱਪਲਰ).
SRP ਸਿਧਾਂਤ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ, ਅਸੀਂ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਤਿੰਨ ਵਿੱਚ ਵੰਡਾਂਗੇ:

• ਇੱਕ ਡੋਲ੍ਹਦਾ ਹੈ (ਪੋਰ ਓਪਰੇਸ਼ਨ)
• ਇੱਕ ਪੀਣ (ਡਰਿੰਕਅੱਪ ਓਪਰੇਸ਼ਨ)
• ਇੱਕ ਕੋਲ ਸਨੈਕ ਹੈ (ਟੇਕਬਾਈਟ ਓਪਰੇਸ਼ਨ)

ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਹਰੇਕ ਭਾਗੀਦਾਰ ਪ੍ਰਕਿਰਿਆ ਦੇ ਇੱਕ ਹਿੱਸੇ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ, ਅਰਥਾਤ, ਇੱਕ ਪਰਮਾਣੂ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ - ਪੀਣ, ਡੋਲ੍ਹਣਾ ਜਾਂ ਸਨੈਕ ਕਰਨਾ।

ਪੀਣ ਵਾਲੇ ਮੋਰੀ, ਬਦਲੇ ਵਿੱਚ, ਇਹਨਾਂ ਓਪਰੇਸ਼ਨਾਂ ਲਈ ਇੱਕ ਨਕਾਬ ਹੈ:

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

ਕਿਉਂ?

ਮਨੁੱਖੀ ਪ੍ਰੋਗਰਾਮਰ ਬਾਂਦਰ-ਮਨੁੱਖ ਲਈ ਕੋਡ ਲਿਖਦਾ ਹੈ, ਅਤੇ ਬਾਂਦਰ-ਮਨੁੱਖ ਬੇਪਰਵਾਹ, ਮੂਰਖ ਅਤੇ ਹਮੇਸ਼ਾ ਕਾਹਲੀ ਵਿੱਚ ਹੁੰਦਾ ਹੈ। ਉਹ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਲਗਭਗ 3 - 7 ਸ਼ਬਦਾਂ ਨੂੰ ਫੜ ਅਤੇ ਸਮਝ ਸਕਦਾ ਹੈ।
ਇੱਕ ਸ਼ਰਾਬੀ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇਹਨਾਂ ਵਿੱਚੋਂ ਤਿੰਨ ਸ਼ਬਦ ਹਨ. ਹਾਲਾਂਕਿ, ਜੇ ਅਸੀਂ ਇੱਕ ਸ਼ੀਟ ਨਾਲ ਕੋਡ ਲਿਖਦੇ ਹਾਂ, ਤਾਂ ਇਸ ਵਿੱਚ ਹੱਥ, ਐਨਕਾਂ, ਲੜਾਈਆਂ ਅਤੇ ਰਾਜਨੀਤੀ ਬਾਰੇ ਬੇਅੰਤ ਦਲੀਲਾਂ ਸ਼ਾਮਲ ਹੋਣਗੀਆਂ। ਅਤੇ ਇਹ ਸਭ ਇੱਕ ਵਿਧੀ ਦੇ ਸਰੀਰ ਵਿੱਚ ਹੋਵੇਗਾ. ਮੈਨੂੰ ਯਕੀਨ ਹੈ ਕਿ ਤੁਸੀਂ ਆਪਣੇ ਅਭਿਆਸ ਵਿੱਚ ਅਜਿਹਾ ਕੋਡ ਦੇਖਿਆ ਹੋਵੇਗਾ। ਮਾਨਸਿਕਤਾ ਲਈ ਸਭ ਤੋਂ ਮਨੁੱਖੀ ਪ੍ਰੀਖਿਆ ਨਹੀਂ.

ਦੂਜੇ ਪਾਸੇ, ਬਾਂਦਰ ਆਦਮੀ ਨੂੰ ਉਸਦੇ ਸਿਰ ਵਿੱਚ ਅਸਲ ਸੰਸਾਰ ਦੀਆਂ ਵਸਤੂਆਂ ਦੀ ਨਕਲ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਆਪਣੀ ਕਲਪਨਾ ਵਿੱਚ, ਉਹ ਉਹਨਾਂ ਨੂੰ ਇਕੱਠੇ ਧੱਕ ਸਕਦਾ ਹੈ, ਉਹਨਾਂ ਤੋਂ ਨਵੀਆਂ ਵਸਤੂਆਂ ਨੂੰ ਇਕੱਠਾ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਵੱਖ ਕਰ ਸਕਦਾ ਹੈ। ਇੱਕ ਪੁਰਾਣੇ ਮਾਡਲ ਦੀ ਕਾਰ ਦੀ ਕਲਪਨਾ ਕਰੋ। ਤੁਹਾਡੀ ਕਲਪਨਾ ਵਿੱਚ, ਤੁਸੀਂ ਦਰਵਾਜ਼ਾ ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ, ਦਰਵਾਜ਼ੇ ਦੀ ਟ੍ਰਿਮ ਨੂੰ ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ ਅਤੇ ਉੱਥੇ ਵਿੰਡੋ ਲਿਫਟ ਮਕੈਨਿਜ਼ਮ ਦੇਖ ਸਕਦੇ ਹੋ, ਜਿਸ ਦੇ ਅੰਦਰ ਗੀਅਰ ਹੋਣਗੇ। ਪਰ ਤੁਸੀਂ ਇੱਕ "ਸੂਚੀ" ਵਿੱਚ ਇੱਕੋ ਸਮੇਂ ਮਸ਼ੀਨ ਦੇ ਸਾਰੇ ਹਿੱਸੇ ਨਹੀਂ ਦੇਖ ਸਕਦੇ। ਘੱਟੋ ਘੱਟ "ਬਾਂਦਰ ਆਦਮੀ" ਨਹੀਂ ਕਰ ਸਕਦਾ.

ਇਸ ਲਈ, ਮਨੁੱਖੀ ਪ੍ਰੋਗਰਾਮਰ ਗੁੰਝਲਦਾਰ ਵਿਧੀਆਂ ਨੂੰ ਘੱਟ ਗੁੰਝਲਦਾਰ ਅਤੇ ਕਾਰਜਸ਼ੀਲ ਤੱਤਾਂ ਦੇ ਸਮੂਹ ਵਿੱਚ ਵਿਗਾੜ ਦਿੰਦੇ ਹਨ। ਹਾਲਾਂਕਿ, ਇਸ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਕੰਪੋਜ਼ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: ਬਹੁਤ ਸਾਰੀਆਂ ਪੁਰਾਣੀਆਂ ਕਾਰਾਂ ਵਿੱਚ, ਹਵਾ ਦੀ ਨਲੀ ਦਰਵਾਜ਼ੇ ਵਿੱਚ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਆਧੁਨਿਕ ਕਾਰਾਂ ਵਿੱਚ, ਲਾਕ ਇਲੈਕਟ੍ਰੋਨਿਕਸ ਵਿੱਚ ਅਸਫਲਤਾ ਇੰਜਣ ਨੂੰ ਚਾਲੂ ਹੋਣ ਤੋਂ ਰੋਕਦੀ ਹੈ, ਜੋ ਮੁਰੰਮਤ ਦੌਰਾਨ ਇੱਕ ਸਮੱਸਿਆ ਹੈ.

ਇਸ ਲਈ, SRP ਇੱਕ ਸਿਧਾਂਤ ਹੈ ਜੋ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਵਿਗਾੜਨਾ ਹੈ, ਯਾਨੀ ਕਿ ਵੰਡਣ ਵਾਲੀ ਰੇਖਾ ਕਿੱਥੇ ਖਿੱਚਣੀ ਹੈ.

ਉਹ ਕਹਿੰਦਾ ਹੈ ਕਿ "ਜ਼ਿੰਮੇਵਾਰੀ" ਦੀ ਵੰਡ ਦੇ ਸਿਧਾਂਤ ਅਨੁਸਾਰ ਵਿਘਨ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ, ਯਾਨੀ ਕਿ ਕੁਝ ਵਸਤੂਆਂ ਦੇ ਕੰਮਾਂ ਦੇ ਅਨੁਸਾਰ.

ਆਉ ਪੀਣ ਅਤੇ ਬਾਂਦਰ ਮਨੁੱਖ ਨੂੰ ਸੜਨ ਦੇ ਦੌਰਾਨ ਪ੍ਰਾਪਤ ਹੋਣ ਵਾਲੇ ਫਾਇਦਿਆਂ ਵੱਲ ਵਾਪਸ ਆਉਂਦੇ ਹਾਂ:

• ਕੋਡ ਹਰ ਪੱਧਰ 'ਤੇ ਬਹੁਤ ਸਪੱਸ਼ਟ ਹੋ ਗਿਆ ਹੈ
• ਕੋਡ ਨੂੰ ਇੱਕ ਵਾਰ ਵਿੱਚ ਕਈ ਪ੍ਰੋਗਰਾਮਰਾਂ ਦੁਆਰਾ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ (ਹਰੇਕ ਇੱਕ ਵੱਖਰਾ ਤੱਤ ਲਿਖਦਾ ਹੈ)
• ਸਵੈਚਲਿਤ ਟੈਸਟਿੰਗ ਨੂੰ ਸਰਲ ਬਣਾਇਆ ਗਿਆ ਹੈ - ਤੱਤ ਜਿੰਨਾ ਸਰਲ ਹੋਵੇਗਾ, ਟੈਸਟ ਕਰਨਾ ਓਨਾ ਹੀ ਆਸਾਨ ਹੋਵੇਗਾ
• ਕੋਡ ਦੀ ਰਚਨਾਤਮਕਤਾ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ - ਤੁਸੀਂ ਬਦਲ ਸਕਦੇ ਹੋ ਡਰਿੰਕਅੱਪ ਓਪਰੇਸ਼ਨ ਇੱਕ ਓਪਰੇਸ਼ਨ ਜਿਸ ਵਿੱਚ ਇੱਕ ਸ਼ਰਾਬੀ ਮੇਜ਼ ਦੇ ਹੇਠਾਂ ਤਰਲ ਪਾਉਂਦਾ ਹੈ। ਜਾਂ ਡੋਲ੍ਹਣ ਦੀ ਕਾਰਵਾਈ ਨੂੰ ਇੱਕ ਓਪਰੇਸ਼ਨ ਨਾਲ ਬਦਲੋ ਜਿਸ ਵਿੱਚ ਤੁਸੀਂ ਵਾਈਨ ਅਤੇ ਪਾਣੀ ਜਾਂ ਵੋਡਕਾ ਅਤੇ ਬੀਅਰ ਨੂੰ ਮਿਲਾਉਂਦੇ ਹੋ। ਕਾਰੋਬਾਰੀ ਲੋੜਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਿਆਂ, ਤੁਸੀਂ ਵਿਧੀ ਕੋਡ ਨੂੰ ਛੂਹਣ ਤੋਂ ਬਿਨਾਂ ਸਭ ਕੁਝ ਕਰ ਸਕਦੇ ਹੋ ਟਿੱਪਲਰ.ਐਕਟ.
• ਇਹਨਾਂ ਓਪਰੇਸ਼ਨਾਂ ਤੋਂ ਤੁਸੀਂ ਗਲੂਟਨ ਨੂੰ ਫੋਲਡ ਕਰ ਸਕਦੇ ਹੋ (ਸਿਰਫ਼ ਵਰਤਦੇ ਹੋਏ TakeBitOperation), ਅਲਕੋਹਲ (ਸਿਰਫ਼ ਵਰਤਣਾ ਡਰਿੰਕਅੱਪ ਓਪਰੇਸ਼ਨ ਸਿੱਧਾ ਬੋਤਲ ਤੋਂ) ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੀਆਂ ਵਪਾਰਕ ਜ਼ਰੂਰਤਾਂ ਨੂੰ ਪੂਰਾ ਕਰੋ।

(ਓਹ, ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਇਹ ਪਹਿਲਾਂ ਹੀ ਇੱਕ 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 ਲਾਈਨਾਂ ਦੇ ਭਿਆਨਕ ਤਰੀਕਿਆਂ ਨਾਲ ਖਤਮ ਹੁੰਦਾ ਹੈ, ਰੂਸ ਲਈ ਨਾਟੋ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਲਈ ਲੋੜ ਤੋਂ ਵੱਧ ਜੇ-ਕਥਨਾਂ ਦੇ ਨਾਲ।

ਪਰਿਭਾਸ਼ਾ 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)
        }
    }
}

ਸੁਚੇਤ ਪਾਠਕ ਇਸ ਵੱਲ ਧਿਆਨ ਦੇਵੇਗਾ ਲੌਗਆਫਟਰ, LogBefore и OnError ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਵੀ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ, ਪਿਛਲੇ ਪੜਾਵਾਂ ਦੇ ਸਮਾਨਤਾ ਨਾਲ, ਤਿੰਨ ਕਲਾਸਾਂ ਬਣਾਏਗਾ: PourLoggerBefore, PourLoggerAfter и PourErrorLogger.

ਅਤੇ ਯਾਦ ਰੱਖੋ ਕਿ ਇੱਕ ਪੀਣ ਵਾਲੇ ਲਈ ਤਿੰਨ ਓਪਰੇਸ਼ਨ ਹਨ, ਸਾਨੂੰ ਨੌਂ ਲੌਗਿੰਗ ਕਲਾਸਾਂ ਮਿਲਦੀਆਂ ਹਨ. ਨਤੀਜੇ ਵਜੋਂ, ਪੂਰੇ ਪੀਣ ਵਾਲੇ ਸਰਕਲ ਵਿੱਚ 14 (!!!) ਕਲਾਸਾਂ ਸ਼ਾਮਲ ਹਨ.

ਹਾਈਪਰਬੋਲਾ? ਮੁਸ਼ਕਿਲ ਨਾਲ! ਇੱਕ ਸੜਨ ਵਾਲੇ ਗ੍ਰੇਨੇਡ ਵਾਲਾ ਇੱਕ ਬਾਂਦਰ ਆਦਮੀ "ਪੋਅਰਰ" ਨੂੰ ਇੱਕ ਡੀਕੈਨਟਰ, ਇੱਕ ਗਲਾਸ, ਡੋਲ੍ਹਣ ਵਾਲੇ ਆਪਰੇਟਰਾਂ, ਇੱਕ ਪਾਣੀ ਸਪਲਾਈ ਸੇਵਾ, ਅਣੂਆਂ ਦੇ ਟਕਰਾਅ ਦਾ ਇੱਕ ਭੌਤਿਕ ਮਾਡਲ ਵਿੱਚ ਵੰਡ ਦੇਵੇਗਾ, ਅਤੇ ਅਗਲੀ ਤਿਮਾਹੀ ਲਈ ਉਹ ਨਿਰਭਰਤਾ ਨੂੰ ਸੁਲਝਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ. ਗਲੋਬਲ ਵੇਰੀਏਬਲ. ਅਤੇ ਮੇਰੇ ਤੇ ਵਿਸ਼ਵਾਸ ਕਰੋ, ਉਹ ਨਹੀਂ ਰੁਕੇਗਾ.

ਇਹ ਇਸ ਮੌਕੇ 'ਤੇ ਹੈ ਕਿ ਬਹੁਤ ਸਾਰੇ ਇਸ ਸਿੱਟੇ 'ਤੇ ਪਹੁੰਚਦੇ ਹਨ ਕਿ SRP ਗੁਲਾਬੀ ਰਾਜਾਂ ਦੀਆਂ ਪਰੀ ਕਹਾਣੀਆਂ ਹਨ, ਅਤੇ ਨੂਡਲਜ਼ ਖੇਡਣ ਲਈ ਚਲੇ ਜਾਂਦੇ ਹਨ ...

... 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 ਹੋਰ ਕਾਰੋਬਾਰੀ ਸੰਚਾਲਨ ਸਨ। ਲਗਭਗ ਹਰ ਕਿਸੇ ਨੂੰ ਖਾਤਾ ਵਸਤੂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਅੱਧੀਆਂ ਕਾਲਾਂ ਵਿੱਚ ਬਿੰਦੂ ID ਅਤੇ ਕਲਾਇੰਟ ਨਾਮ ਦੀ ਲੋੜ ਸੀ।

ਇੱਕ ਘੰਟੇ ਦੇ ਰੀਫੈਕਟਰਿੰਗ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਕੋਡ ਅਤੇ ਖਾਤੇ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀਆਂ ਕੁਝ ਸੂਖਮਤਾਵਾਂ ਨੂੰ ਵੱਖਰੇ ਢੰਗਾਂ/ਕਲਾਸਾਂ ਵਿੱਚ ਵੱਖ ਕਰਨ ਦੇ ਯੋਗ ਹੋ ਗਏ। ਪ੍ਰਮਾਤਮਾ ਵਿਧੀ ਨੇ ਇਸਨੂੰ ਆਸਾਨ ਬਣਾ ਦਿੱਤਾ, ਪਰ ਕੋਡ ਦੀਆਂ 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