10 ਆਬਜੈਕਟ ਓਰੀਐਂਟਡ ਪ੍ਰੋਗਰਾਮਿੰਗ ਸਿਧਾਂਤ ਹਰ ਡਿਵੈਲਪਰ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ

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

ਅਸੀਂ ਯਾਦ ਦਿਵਾਉਂਦੇ ਹਾਂ: ਹਾਬਰ ਦੇ ਸਾਰੇ ਪਾਠਕਾਂ ਲਈ - Habr ਪ੍ਰਚਾਰ ਕੋਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕਿਸੇ ਵੀ ਸਕਿੱਲਬਾਕਸ ਕੋਰਸ ਵਿੱਚ ਦਾਖਲਾ ਲੈਣ 'ਤੇ 10 ਰੂਬਲ ਦੀ ਛੋਟ।

ਸਕਿੱਲਬਾਕਸ ਸਿਫ਼ਾਰਿਸ਼ ਕਰਦਾ ਹੈ: ਵਿਦਿਅਕ ਔਨਲਾਈਨ ਕੋਰਸ "ਜਾਵਾ ਡਿਵੈਲਪਰ".

ਸੁੱਕਾ (ਆਪਣੇ ਆਪ ਨੂੰ ਨਾ ਦੁਹਰਾਓ)

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

ਜੇਕਰ ਕੋਡ ਵਿੱਚ ਦੋ ਦੁਹਰਾਉਣ ਵਾਲੇ ਭਾਗ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਵਿਧੀ ਵਿੱਚ ਜੋੜਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਇੱਕ ਹਾਰਡਕੋਡਡ ਮੁੱਲ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਇਸਨੂੰ ਇੱਕ ਜਨਤਕ ਸਥਿਰਾਂਕ ਵਿੱਚ ਬਦਲਣ ਦੇ ਯੋਗ ਹੈ।

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

ਐਨਕੈਪਸੂਲੇਟਿੰਗ ਤਬਦੀਲੀਆਂ

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

ਜੇ ਤੁਸੀਂ Java ਵਿੱਚ ਲਿਖਦੇ ਹੋ, ਤਾਂ ਮੂਲ ਰੂਪ ਵਿੱਚ ਨਿੱਜੀ ਢੰਗ ਅਤੇ ਵੇਰੀਏਬਲ ਨਿਰਧਾਰਤ ਕਰੋ.

ਖੁੱਲ੍ਹਾ/ਬੰਦ ਸਿਧਾਂਤ

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

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

ਇੱਥੇ ਕੋਡ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਜੋ ਇਸ ਸਿਧਾਂਤ ਦੀ ਉਲੰਘਣਾ ਕਰਦੀ ਹੈ।

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

ਤਰੀਕੇ ਨਾਲ, ਖੁੱਲੇਪਨ-ਬੰਦ ਹੋਣਾ SOLID ਦੇ ਸਿਧਾਂਤਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ।

ਸਿੰਗਲ ਜ਼ਿੰਮੇਵਾਰੀ ਸਿਧਾਂਤ (SRP)

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

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

ਨਿਰਭਰਤਾ ਉਲਟ ਸਿਧਾਂਤ (DIP)

ਉੱਪਰ ਇੱਕ ਕੋਡ ਉਦਾਹਰਨ ਹੈ ਜਿੱਥੇ ਐਪਮੈਨੇਜਰ ਇਵੈਂਟਲੌਗ ਰਾਈਟਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਜੋ ਬਦਲੇ ਵਿੱਚ ਐਪਮੈਨੇਜਰ ਨਾਲ ਮਿਲ ਕੇ ਹੈ। ਜੇਕਰ ਤੁਹਾਨੂੰ ਕੋਈ ਸੂਚਨਾ ਦਿਖਾਉਣ ਲਈ ਕਿਸੇ ਵੱਖਰੇ ਤਰੀਕੇ ਦੀ ਲੋੜ ਹੈ, ਭਾਵੇਂ ਇਹ ਪੁਸ਼, SMS ਜਾਂ ਈਮੇਲ ਹੋਵੇ, ਤੁਹਾਨੂੰ ਐਪਮੈਨੇਜਰ ਕਲਾਸ ਨੂੰ ਬਦਲਣ ਦੀ ਲੋੜ ਹੈ।

DIP ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ, ਐਪਮੈਨੇਜਰ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਇੱਕ EventLogWriter ਦੀ ਬੇਨਤੀ ਕਰਦੇ ਹਾਂ, ਜੋ ਕਿ ਫਰੇਮਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਦਾਖਲ ਕੀਤਾ ਜਾਵੇਗਾ।

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

ਵਿਰਾਸਤ ਦੀ ਬਜਾਏ ਰਚਨਾ

ਕੋਡ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਨ ਦੇ ਦੋ ਮੁੱਖ ਤਰੀਕੇ ਹਨ: ਵਿਰਾਸਤ ਅਤੇ ਰਚਨਾ, ਦੋਵਾਂ ਦੇ ਆਪਣੇ ਫਾਇਦੇ ਅਤੇ ਨੁਕਸਾਨ ਹਨ। ਆਮ ਤੌਰ 'ਤੇ ਦੂਜੇ ਨੂੰ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਵਧੇਰੇ ਲਚਕਦਾਰ ਹੁੰਦਾ ਹੈ।

ਰਚਨਾ ਤੁਹਾਨੂੰ ਰਨਟਾਈਮ 'ਤੇ ਕਲਾਸ ਦੇ ਵਿਵਹਾਰ ਨੂੰ ਇਸ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸੈਟ ਕਰਕੇ ਬਦਲਣ ਦੀ ਸਮਰੱਥਾ ਦਿੰਦੀ ਹੈ। ਇੰਟਰਫੇਸ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਸਮੇਂ, ਪੋਲੀਮੋਰਫਿਜ਼ਮ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਵਧੇਰੇ ਲਚਕਦਾਰ ਲਾਗੂਕਰਨ ਦਿੰਦੀ ਹੈ।

ਇੱਥੋਂ ਤੱਕ ਕਿ ਜੋਸ਼ੂਆ ਬਲੋਚ ਦੁਆਰਾ ਪ੍ਰਭਾਵੀ ਜਾਵਾ ਵਿਰਾਸਤ ਨਾਲੋਂ ਰਚਨਾ ਦੀ ਚੋਣ ਕਰਨ ਦੀ ਸਲਾਹ ਦਿੰਦਾ ਹੈ।

ਬਾਰਬਰਾ ਲਿਸਕੋਵ ਸਬਸਟੀਟਿਊਸ਼ਨ ਸਿਧਾਂਤ (LSP)

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

LSP ਇਕੋ ਜ਼ਿੰਮੇਵਾਰੀ ਸਿਧਾਂਤ ਅਤੇ ਸਾਂਝੀ ਜ਼ਿੰਮੇਵਾਰੀ ਸਿਧਾਂਤ ਦੋਵਾਂ ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ। ਜੇਕਰ ਇੱਕ ਕਲਾਸ ਇੱਕ ਉਪ-ਕਲਾਸ ਨਾਲੋਂ ਵਧੇਰੇ ਕਾਰਜਸ਼ੀਲਤਾ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ, ਤਾਂ ਬਾਅਦ ਵਾਲੇ ਇਸ ਸਿਧਾਂਤ ਦੀ ਉਲੰਘਣਾ ਕਰਦੇ ਹੋਏ, ਕੁਝ ਕਾਰਜਸ਼ੀਲਤਾ ਦਾ ਸਮਰਥਨ ਨਹੀਂ ਕਰਨਗੇ।

ਇੱਥੇ ਕੋਡ ਦਾ ਇੱਕ ਟੁਕੜਾ ਹੈ ਜੋ LSP ਦਾ ਖੰਡਨ ਕਰਦਾ ਹੈ।

ਖੇਤਰ(ਰੈਕਟੈਂਗਲ ਆਰ) ਵਿਧੀ ਇੱਕ ਆਇਤਕਾਰ ਦੇ ਖੇਤਰ ਦੀ ਗਣਨਾ ਕਰਦੀ ਹੈ। ਪ੍ਰੋਗਰਾਮ Square ਨੂੰ ਚਲਾਉਣ ਤੋਂ ਬਾਅਦ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਵੇਗਾ ਕਿਉਂਕਿ Square ਇੱਥੇ ਇੱਕ ਆਇਤਕਾਰ ਨਹੀਂ ਹੈ। LSP ਸਿਧਾਂਤ ਦੇ ਅਨੁਸਾਰ, ਫੰਕਸ਼ਨ ਜੋ ਬੇਸ ਕਲਾਸਾਂ ਦੇ ਸੰਦਰਭਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਵਾਧੂ ਨਿਰਦੇਸ਼ਾਂ ਤੋਂ ਬਿਨਾਂ ਪ੍ਰਾਪਤ ਕੀਤੀਆਂ ਕਲਾਸਾਂ ਦੀਆਂ ਵਸਤੂਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

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

ਇੰਟਰਫੇਸ ਸਪਲਿਟ ਸਿਧਾਂਤ (ISP)

ਇੱਕ ਹੋਰ ਠੋਸ ਸਿਧਾਂਤ। ਇਸਦੇ ਅਨੁਸਾਰ, ਇੱਕ ਇੰਟਰਫੇਸ ਜੋ ਵਰਤਿਆ ਨਹੀਂ ਜਾਂਦਾ ਹੈ, ਨੂੰ ਲਾਗੂ ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ. ਇਸ ਸਿਧਾਂਤ ਦਾ ਪਾਲਣ ਕਰਨਾ ਸਿਸਟਮ ਨੂੰ ਲਚਕਦਾਰ ਅਤੇ ਰੀਫੈਕਟਰਿੰਗ ਲਈ ਢੁਕਵਾਂ ਰਹਿਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦੋਂ ਓਪਰੇਟਿੰਗ ਤਰਕ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

ਅਕਸਰ, ਇਹ ਸਥਿਤੀ ਉਦੋਂ ਵਾਪਰਦੀ ਹੈ ਜਦੋਂ ਇੰਟਰਫੇਸ ਵਿੱਚ ਇੱਕੋ ਸਮੇਂ ਕਈ ਫੰਕਸ਼ਨ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਉਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ ਇੱਕ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ.

ਕਿਉਂਕਿ ਇੱਕ ਇੰਟਰਫੇਸ ਲਿਖਣਾ ਇੱਕ ਮੁਸ਼ਕਲ ਕੰਮ ਹੈ, ਇਸ ਲਈ ਬਿਨਾਂ ਕਿਸੇ ਤੋੜ ਦੇ ਕੰਮ ਪੂਰਾ ਹੋਣ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਬਦਲਣਾ ਇੱਕ ਚੁਣੌਤੀ ਹੋਵੇਗੀ।

ਜਾਵਾ ਵਿੱਚ ISP ਸਿਧਾਂਤ ਦਾ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਸਾਰੀਆਂ ਵਿਧੀਆਂ ਨੂੰ ਪਹਿਲਾਂ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕੇਵਲ ਤਦ ਹੀ ਉਹਨਾਂ ਨੂੰ ਕਲਾਸਾਂ ਦੁਆਰਾ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ, ਸਿਧਾਂਤ ਤਰੀਕਿਆਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਘਟਾਉਣਾ ਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ.

ਇੰਟਰਫੇਸ ਲਈ ਪ੍ਰੋਗਰਾਮਿੰਗ, ਲਾਗੂ ਕਰਨ ਲਈ ਨਹੀਂ

ਸਿਰਲੇਖ ਤੋਂ ਇੱਥੇ ਸਭ ਕੁਝ ਸਪਸ਼ਟ ਹੈ। ਇਸ ਸਿਧਾਂਤ ਨੂੰ ਲਾਗੂ ਕਰਨ ਨਾਲ ਲਚਕਦਾਰ ਕੋਡ ਦੀ ਸਿਰਜਣਾ ਹੁੰਦੀ ਹੈ ਜੋ ਇੰਟਰਫੇਸ ਦੇ ਕਿਸੇ ਵੀ ਨਵੇਂ ਲਾਗੂ ਕਰਨ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ।

ਤੁਹਾਨੂੰ ਵੇਰੀਏਬਲ, ਰਿਟਰਨ ਕਿਸਮਾਂ, ਜਾਂ ਵਿਧੀ ਆਰਗੂਮੈਂਟ ਕਿਸਮ ਲਈ ਇੰਟਰਫੇਸ ਕਿਸਮ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਇੱਕ ਉਦਾਹਰਨ ਸਬਕਲਾਸ ਦੀ ਬਜਾਏ ਸੁਪਰਕਲਾਸ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ।

ਜੋ ਕਿ ਹੈ:

ਸੂਚੀ ਨੰਬਰ = getNumbers();

ਪਰ ਨਾ:

ਐਰੇਲਿਸਟ ਨੰਬਰ = getNumbers();

ਇੱਥੇ ਉੱਪਰ ਦੱਸੀਆਂ ਗਈਆਂ ਗੱਲਾਂ ਦਾ ਵਿਹਾਰਕ ਅਮਲ ਹੈ।

ਵਫ਼ਦ ਦਾ ਸਿਧਾਂਤ

ਇੱਕ ਆਮ ਉਦਾਹਰਨ Java ਵਿੱਚ ਬਰਾਬਰ() ਅਤੇ ਹੈਸ਼ਕੋਡ() ਢੰਗ ਹਨ। ਜਦੋਂ ਦੋ ਵਸਤੂਆਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਇਹ ਕਾਰਵਾਈ ਕਲਾਇੰਟ ਇੱਕ ਦੀ ਬਜਾਏ ਸੰਬੰਧਿਤ ਕਲਾਸ ਨੂੰ ਸੌਂਪੀ ਜਾਂਦੀ ਹੈ।

ਸਿਧਾਂਤ ਦਾ ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਕੋਡ ਦੀ ਕੋਈ ਡੁਪਲੀਕੇਸ਼ਨ ਨਹੀਂ ਹੈ ਅਤੇ ਵਿਵਹਾਰ ਨੂੰ ਬਦਲਣਾ ਮੁਕਾਬਲਤਨ ਸਧਾਰਨ ਹੈ. ਇਹ ਇਵੈਂਟ ਡੈਲੀਗੇਸ਼ਨ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।

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

ਸਕਿੱਲਬਾਕਸ ਸਿਫ਼ਾਰਿਸ਼ ਕਰਦਾ ਹੈ:

• ਪ੍ਰੈਕਟੀਕਲ ਕੋਰਸ "ਮੋਬਾਈਲ ਡਿਵੈਲਪਰ ਪ੍ਰੋ".
• ਆਨਲਾਈਨ ਕੋਰਸ ਅਪਲਾਈ ਕੀਤਾ "ਪਾਈਥਨ ਵਿੱਚ ਡੇਟਾ ਐਨਾਲਿਸਟ".
• ਦੋ ਸਾਲਾ ਪ੍ਰੈਕਟੀਕਲ ਕੋਰਸ "ਮੈਂ ਇੱਕ ਪ੍ਰੋ ਵੈੱਬ ਡਿਵੈਲਪਰ ਹਾਂ".

ਸਰੋਤ: www.habr.com