👨🏼‍🚀 🤮 👸🏽 पुस्तक "ऑब्जेक्ट ओरिएंटेड दृष्टिकोण। 5 वीं इंट। ईडी। " 🎛️ 🚾 👦🏾

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग (OOP) C ++, Java, C #, विजुअल बेसिक .NET, रूबी, ऑब्जेक्टिव-सी और यहां तक कि स्विफ्ट भाषाओं के केंद्र में है। वे वेब प्रौद्योगिकी वस्तुओं के बिना नहीं कर सकते, क्योंकि वे जावास्क्रिप्ट, पायथन और पीएचपी का उपयोग करते हैं।

यही कारण है कि मैट वीसफेल्ड एक वस्तु-उन्मुख तरीके से सोच विकसित करने की सलाह देता है और केवल एक विशिष्ट प्रोग्रामिंग भाषा में ऑब्जेक्ट-ओरिएंटेड विकास के साथ आगे बढ़ता है।

यह पुस्तक डेवलपर्स के लिए डेवलपर द्वारा लिखी गई है और आपको विशिष्ट समस्याओं को हल करने के लिए सर्वोत्तम दृष्टिकोण चुनने की अनुमति देती है। आप सीखेंगे कि विरासत और संरचना को ठीक से कैसे लागू किया जाए, एकत्रीकरण और संघ के बीच अंतर को समझें, और इंटरफ़ेस और कार्यान्वयन को भ्रमित करना बंद करें।

प्रोग्रामिंग प्रौद्योगिकियां लगातार बदल रही हैं और विकसित हो रही हैं, लेकिन ऑब्जेक्ट-ओरिएंटेड अवधारणाएं स्वतंत्र हैं और लगातार प्रभावी बनी हुई हैं। यह प्रकाशन OOP की मूल नींव पर केंद्रित है: डिजाइन पैटर्न, निर्भरता और ठोस सिद्धांत जो आपके कोड को समझने योग्य, लचीला और अच्छी तरह से बनाए रखेंगे।

ठोस वस्तु उन्मुख डिजाइन सिद्धांत

1. एसआरपी: एकमात्र जिम्मेदारी सिद्धांत

एकमात्र जिम्मेदारी का सिद्धांत बताता है कि एक वर्ग में परिवर्तन करने के लिए केवल एक कारण की आवश्यकता होती है। प्रत्येक कक्षा और कार्यक्रम मॉड्यूल को प्राथमिकता में एक कार्य होना चाहिए। इसलिए, आपको उन तरीकों को पेश नहीं करना चाहिए जो एक से अधिक कारणों से वर्ग में परिवर्तन का कारण बन सकते हैं। यदि वर्ग विवरण में शब्द "और" है, तो SRP सिद्धांत का उल्लंघन हो सकता है। दूसरे शब्दों में, प्रत्येक मॉड्यूल या वर्ग को सॉफ़्टवेयर कार्यक्षमता के एक भाग के लिए ज़िम्मेदार होना चाहिए, और इस तरह की ज़िम्मेदारी पूरी तरह से कक्षा में होनी चाहिए।

आंकड़ों का पदानुक्रम बनाना क्लासिक उदाहरणों में से एक है जो वंशानुक्रम को दर्शाता है। यह उदाहरण अक्सर शिक्षण में पाया जाता है, और मैं इसे इस अध्याय (और साथ ही पूरे पुस्तक में) का उपयोग करता हूं। इस उदाहरण में, सर्किल वर्ग को आकृति वर्ग से विशेषताएँ प्राप्त होती हैं। आकार वर्ग एक उपवर्ग के लिए अनुबंध के रूप में अमूर्त कैल्केरिया () विधि प्रदान करता है। प्रत्येक वर्ग जिसे आकार से विरासत में मिला है, उसके पास कैल्क्रिया () पद्धति का अपना कार्यान्वयन होना चाहिए:

abstract class Shape{
     protected String name;
     protected double area;
     public abstract double calcArea();
}

इस उदाहरण में, सर्किल वर्ग, जो कि आकृति वर्ग से विरासत में मिला है, यदि यह है:

class Circle extends Shape{
     private double radius;

     public Circle(double r) {
           radius = r;
     }
     public double calcArea() {
           area = 3.14*(radius*radius) ;
           return (area);
     };
}

तीसरी श्रेणी, CalculateAreas, आकृति सरणी में निहित विभिन्न आकृतियों के क्षेत्र की गणना करता है। आकृति सरणी आकार में असीमित है और इसमें विभिन्न आकृतियाँ, जैसे कि वर्ग और त्रिकोण शामिल हो सकते हैं।

class CalculateAreas {
     Shape[] shapes;
     double sumTotal=0;
     public CalculateAreas(Shape[] sh) {
           this.shapes = sh;
     }
     public double sumAreas() {
           sumTotal=0;
           for (inti=0; i<shapes.length; i++) {
           sumTotal = sumTotal + shapes[i].calcArea() ;
           }
           return sumTotal ;
     }
     public void output() {
           System.out.printIn("Total of all areas = " + sumTotal);
     }
}

ध्यान दें कि CalculateAreas वर्ग एप्लिकेशन आउटपुट को भी संभालता है, जिससे समस्याएं हो सकती हैं। क्षेत्र की गिनती का व्यवहार और आउटपुट व्यवहार संबंधित हैं क्योंकि वे एक ही वर्ग में निहित हैं।

हम उपयुक्त टेस्ट एप्लिकेशन टेस्टस्पे का उपयोग करके इस कोड की कार्यक्षमता को सत्यापित कर सकते हैं:

public class TestShape {
      public static void main(String args[]) {

            System.out.printin("Hello World!");

            Circle circle = new Circle(1);

            Shape[] shapeArray = new Shape[1];
            shapeArray[0] = circle;

            CalculateAreas ca = new CalculateAreas(shapeArray) ;

            ca.sumAreas() ;
            ca.output();
      }
}

अब हमारे पास अपने निपटान में एक परीक्षण आवेदन है, हम एकमात्र जिम्मेदारी के सिद्धांत की समस्या पर ध्यान केंद्रित कर सकते हैं। फिर, यह समस्या कैलकुलेटरीस वर्ग और इस तथ्य के साथ है कि इस वर्ग में विभिन्न आकृतियों के क्षेत्रों को जोड़ने के साथ-साथ डेटा के आउटपुट के लिए व्यवहार शामिल हैं।

मूल प्रश्न (और, वास्तव में, समस्या) यह है कि यदि आपको आउटपुट () विधि की कार्यक्षमता को बदलने की आवश्यकता है, तो आपको गणनाओं के वर्ग में परिवर्तन करने की आवश्यकता होगी, चाहे आकार के क्षेत्र की गणना के लिए विधि बदल जाए। उदाहरण के लिए, यदि हम अचानक HTML कंसोल में डेटा को आउटपुट करना चाहते हैं, और सादे टेक्स्ट को नहीं, तो हमें कोड को फिर से जोड़ना और फिर से एम्बेड करना होगा, जो आंकड़ों के क्षेत्र को जोड़ता है। सभी क्योंकि देयता संबंधित है।

एकमात्र जिम्मेदारी के सिद्धांत के अनुसार, कार्य एक विधि को बदलना है अन्य विधियों को प्रभावित नहीं करता है और फिर से संकलित नहीं करना है। "वर्ग में एक, केवल एक, परिवर्तन का कारण होना चाहिए - एकमात्र जिम्मेदारी जिसे बदलने की आवश्यकता है।"

इस समस्या को हल करने के लिए, आप दो तरीकों को अलग-अलग वर्गों में रख सकते हैं, एक मूल कंसोल आउटपुट के लिए, दूसरा HTML आउटपुट के लिए:

class CaiculateAreas {;
     Shape[] shapes;
     double sumTotal=0;

     public CalculateAreas(Shape[] sh) {
           this.shapes = sh;
     }

     public double sumAreas() {
           sumTotal=0;

           for (inti=0; i<shapes.length; i++) {

                sumTotal = sumTotal + shapes[i].calcArea();

           }

                return sumTotal;
           }
}
class OutputAreas {
     double areas=0;
     public OutputAreas (double a) {
           this.areas = a;
     }

           public void console() {
           System.out.printin("Total of all areas = " + areas);
     }
     public void HTML() {
           System.out.printIn("<HTML>") ;
           System.out.printin("Total of all areas = " + areas);
           System.out.printin("</HTML>") ;
     }
}

नीचे की रेखा यह है कि अब आप जरूरत के आधार पर विभिन्न दिशाओं में निष्कर्ष भेज सकते हैं। यदि आप किसी अन्य आउटपुट विधि की संभावना को जोड़ना चाहते हैं, उदाहरण के लिए, JSON, तो आप इसे कैल्कुलरेट क्लास में परिवर्तन करने के लिए बिना OutputAreas वर्ग में जोड़ सकते हैं। नतीजतन, आप किसी भी तरह से अन्य वर्गों को प्रभावित किए बिना कैल्केटेरास वर्ग को पुनर्वितरित कर सकते हैं।

2. OCP: खुला / बंद सिद्धांत

खुलेपन / निकटता के सिद्धांत में कहा गया है कि आप बदलाव किए बिना एक वर्ग के व्यवहार का विस्तार कर सकते हैं।

आइए फिर से आंकड़ों के साथ उदाहरण पर ध्यान दें। नीचे दिए गए कोड में, एक शेप कलक्यूलर वर्ग है जो एक आयत वस्तु लेता है, इस वस्तु के क्षेत्र की गणना करता है, और मान लौटाता है। यह एक सरल अनुप्रयोग है, लेकिन यह केवल आयतों के साथ काम करता है।

class Rectangle{
     protected double length;
     protected double width;

     public Rectangle(double 1, double w) {
           length = 1;
           width = w;
     };
}
class CalculateAreas {
     private double area;

     public double calcArea(Rectangle r) {

           area = r.length * r.width;

           return area;
     }
}
public class OpenClosed {
      public static void main(String args[]) {

            System.out.printin("Hello World");

            Rectangle r = new Rectangle(1,2);

            CalculateAreas ca = new CalculateAreas ();

            System.out.printin("Area = "+ ca.calcArea(r));
      }
}

तथ्य यह है कि यह आवेदन केवल आयतों के मामले में काम करता है, एक सीमा तक ले जाता है जो स्पष्ट रूप से खुलेपन / बंद होने के सिद्धांत को स्पष्ट करता है: यदि हम सर्कल क्लास को कैल्कुलेटआरे क्लास में जोड़ना चाहते हैं (यह क्या करता है), हमें मॉड्यूल में ही बदलाव करने की आवश्यकता है। जाहिर है, यह खुलेपन / निकटता के सिद्धांत के साथ संघर्ष करता है, जो बताता है कि हमें मॉड्यूल में बदलाव नहीं करना चाहिए कि वह क्या करता है।

खुलेपन / निकटता के सिद्धांत का पालन करने के लिए, हम पहले से ही परीक्षण किए गए उदाहरण के आंकड़ों के साथ लौट सकते हैं, जहां एक अमूर्त वर्ग आकृति बनाई जाती है और सीधे आकृति वर्ग से विरासत में प्राप्त आंकड़े होते हैं, जिसमें एक सार विधि getArea () है।

फिलहाल, आप आवश्यकता के अनुसार अलग-अलग वर्ग जोड़ सकते हैं, बिना सीधे आकृति वर्ग में परिवर्तन करने की आवश्यकता के लिए (उदाहरण के लिए, सर्कल वर्ग)। अब हम कह सकते हैं कि शेप क्लास बंद है।

नीचे दिया गया कोड आयतों और हलकों के समाधान का कार्यान्वयन प्रदान करता है और आपको असीमित संख्या में आकृतियाँ बनाने की अनुमति देता है:

abstract class Shape {
      public abstract double getArea() ;
}
class Rectangle extends Shape
{

      protected double length;
      protected double width;

      public Rectangle(double 1, double w) {
            length = 1;
            width = w;
      };
      public double getArea() {
            return length*width;
      }

}
class Circle extends Shape
{
      protected double radius;

      public Circle(double r) {
            radius = r;
      };
      public double getArea() {
            return radius*radius*3.14;
      }
}
class CalculateAreas {
      private double area;

      public double calcArea(Shape s) {
            area = s.getArea();
            return area;
      }
}

public class OpenClosed {
      public static void main(String args[]) {

            System.out.printiIn("Hello World") ;

            CalculateAreas ca = new CalculateAreas() ;

            Rectangle r = new Rectangle(1,2);

            System.out.printIn("Area = " + ca.calcArea(r));

            Circle c = new Circle(3);

            System.out.printIn("Area = " + ca.calcArea(c));
}
}

यह ध्यान देने योग्य है कि इस कार्यान्वयन के साथ, शेप क्लास का एक नया उदाहरण बनाते समय कैलक्लेटअरेस () पद्धति को संशोधित नहीं किया जाना चाहिए।

आप पिछले कोड के अस्तित्व के बारे में चिंता किए बिना कोड को स्केल कर सकते हैं। खुलेपन / निकटता का सिद्धांत यह है कि आपको उपवर्गों का उपयोग करके कोड का विस्तार करना चाहिए ताकि मूल वर्ग को संपादन की आवश्यकता न हो। हालाँकि, "विस्तार" की अवधारणा स्वयं SOLID के सिद्धांतों के बारे में कुछ चर्चाओं में विवादास्पद है। इसे कुंद करने के लिए, यदि हम विरासत के बजाय रचना पसंद करते हैं, तो यह खुलेपन / निकटता के सिद्धांत को कैसे प्रभावित करता है?

एक ठोस सिद्धांतों का अनुपालन करते समय, कोड अन्य SOLID सिद्धांतों के मानदंडों को पूरा कर सकता है। उदाहरण के लिए, खुलेपन / निकटता के सिद्धांत के अनुसार डिजाइन करते समय, कोड एकमात्र जिम्मेदारी के सिद्धांत की आवश्यकताओं के अनुरूप हो सकता है।

3. एलएसपी: लिस्क प्रतिस्थापन सिद्धांत

लिसकोव प्रतिस्थापन सिद्धांत के अनुसार, डिज़ाइन को बच्चे की कक्षाओं में से किसी एक के साथ मूल वर्ग के किसी भी उदाहरण को बदलने की संभावना के लिए प्रदान करना चाहिए। यदि अभिभावक वर्ग कोई कार्य कर सकता है, तो बाल वर्ग को भी सक्षम होना चाहिए।

कुछ कोड पर विचार करें जो पहली नज़र में सही है, लेकिन लिस्क प्रतिस्थापन सिद्धांत का उल्लंघन करता है। नीचे दिए गए कोड में एक सामान्य आकार का सार वर्ग है। आयत वर्ग, बदले में, आकृति वर्ग से विशेषताएँ प्राप्त करता है और इसकी सार कैल्केरिया () विधि को ओवरराइड करता है। स्क्वायर वर्ग, बदले में, आयत से विरासत में मिला है।

abstract class Shape{
      protected double area;

      public abstract double calcArea();
}
class Rectangle extends Shape{
      private double length;
      private double width;

      public Rectangle(double 1, double w) {
            length = 1;
            width = w;
      }
      public double calcArea() {
            area = length*width;
            return (area) ;
      };
}
class Square extends Rectangle{
      public Square(double s) {
            super(s, Ss);
      }
}

public class LiskovSubstitution {
      public static void main(String args[]) {

            System.out.printIn("Hello World") ;

            Rectangle r = new Rectangle(1,2);

            System.out.printin("Area = " + r.calcArea());

            Square s = new Square(2) ;

            System.out.printin("Area = " + s.calcArea());
      }
}

अब तक, इतना अच्छा: आयत आकृति का एक उदाहरण है, इसलिए चिंता की कोई बात नहीं है, क्योंकि वर्ग आयत का एक उदाहरण है - और फिर, सब कुछ सही है, है ना?

अब एक दार्शनिक प्रश्न पूछते हैं: क्या एक वर्ग अभी भी एक आयत है? कई पुष्टिमार्ग में जवाब देंगे। यद्यपि यह माना जा सकता है कि एक वर्ग एक आयत का एक विशेष मामला है, इसके गुण भिन्न होंगे। एक आयत एक समांतर चतुर्भुज है (विपरीत पक्ष समान हैं), एक वर्ग की तरह। इसी समय, वर्ग भी एक समभुज है (सभी पक्ष समान हैं), जबकि आयत नहीं है। इसलिए, मतभेद हैं।

जब ऑब्जेक्ट-ओरिएंटेड डिज़ाइन की बात आती है, तो समस्या ज्यामिति नहीं है। समस्या यह है कि हम आयतों और वर्गों को कैसे बनाते हैं। यहाँ आयत वर्ग के लिए निर्माता है:

public Rectangle(double 1, double w) {
      length = 1;
      width = w;
}

जाहिर है, निर्माता को दो मापदंडों की आवश्यकता होती है। हालांकि, वर्ग वर्ग के लिए निर्माणकर्ता को केवल एक की आवश्यकता होती है, भले ही मूल वर्ग, आयत, दो की आवश्यकता हो।

class Square extends Rectangle{
      public Square(double s) {
      super(s, Ss);
}

वास्तव में, इन दो वर्गों में से प्रत्येक के मामले में क्षेत्र की गणना के लिए कार्यात्मक थोड़ा अलग है। यही है, स्क्वायर वर्ग, जैसा कि यह था, एक आयत की नकल करता है, एक ही पैरामीटर को दो बार पास करने वाला है। ऐसा लग सकता है कि इस तरह का वर्कअराउंड काफी उपयुक्त है, लेकिन वास्तव में यह कोड के साथ आने वाले डेवलपर्स को गुमराह कर सकता है, जो भविष्य में होने पर नुकसान के साथ काफी भयावह है। कम से कम यह एक समस्या है और, शायद, एक संदिग्ध डिजाइन निर्णय। जब एक कंस्ट्रक्टर दूसरे को कॉल करता है, तो ब्रेक लेना अच्छा होता है और कंस्ट्रक्शन पर पुनर्विचार करना - शायद चाइल्ड क्लास ठीक से नहीं बना है।

इस स्थिति से बाहर निकलने का रास्ता कैसे खोजा जाए? सीधे शब्दों में कहें, तो आप आयत के लिए वर्गाकार वर्ग का विकल्प नहीं बना सकते। इस प्रकार, स्क्वायर आयत वर्ग का बच्चा नहीं होना चाहिए। उन्हें अलग वर्ग होना चाहिए।

abstract class Shape {
      protected double area;

      public abstract double calcArea();
}

class Rectangle extends Shape {

      private double length;
      private double width;

      public Rectangle(double 1, double w) {
            length = 1;
            width = w;
      }

      public double calcArea() {
            area = length*width;
            return (area);
      };
}

class Square extends Shape {
      private double side;

      public Square(double s) {
            side = s;
      }
      public double calcArea() {
            area = side*side;
            return (area);
      };
}

public class LiskovSubstitution {
      public static void main(String args[]) {

             System.out.printIn("Hello World") ;

             Rectangle r = new Rectangle(1,2);

             System.out.printIn("Area = " + r.calcArea());

             Square s = new Square(2) ;

             System.out.printIn("Area = " + s.calcArea());
      }
}

4. आईएसपी: इंटरफ़ेस शेयरिंग सिद्धांत

इंटरफेस के पृथक्करण के सिद्धांत में कहा गया है कि कई बड़े लोगों की तुलना में कई छोटे इंटरफेस बनाना बेहतर है।

इस उदाहरण में, हम एक एकल इंटरफ़ेस बनाते हैं जिसमें स्तनपायी वर्ग के लिए कई व्यवहार शामिल हैं, जैसे कि खाने () और मेकओनिज़ ():

interface IMammal {
     public void eat();
     public void makeNoise() ;
}
class Dog implements IMammal {
     public void eat() {
           System.out.printIn("Dog is eating");
     }
     public void makeNoise() {
           System.out.printIn("Dog is making noise");
     }
}
public class MyClass {
      public static void main(String args[]) {

            System.out.printIn("Hello World");

            Dog fido = new Dog();
            fido.eat();
            fido.makeNoise()
      }
}

स्तनपायी वर्ग के लिए एकल इंटरफ़ेस बनाने के बजाय, आपको
सभी व्यवहारों के लिए अलग इंटरफेस बनाने की आवश्यकता है :

interface IEat {
     public void eat();
}
interface IMakeNoise {
     public void makeNoise() ;
}
class Dog implements IEat, IMakeNoise {
     public void eat() {
           System.out.printIn("Dog is eating");
     }
     public void makeNoise() {
           System.out.printIn("Dog is making noise");
     }
}
public class MyClass {
      public static void main(String args[]) {

            System.out.printIn("Hello World") ;

            Dog fido = new Dog();
            fido.eat();
            fido.makeNoise();
      }
}

हम व्यवहार को स्तनपायी वर्ग से अलग करते हैं। यह पता चला है कि वंशानुक्रम (अधिक सटीक, इंटरफेस) के माध्यम से एक एकल स्तनधारी वर्ग बनाने के बजाय, हम पिछले अध्याय में उपयोग की गई रणनीति के समान रचना के आधार पर डिजाइन करने के लिए आगे बढ़ते हैं।

कुछ शब्दों में, इस दृष्टिकोण के साथ, हम एक ही स्तनपायी वर्ग में एम्बेडेड व्यवहार का उपयोग करने के लिए मजबूर होने के बजाय, रचना का उपयोग कर स्तनधारी वर्ग के उदाहरण बना सकते हैं। उदाहरण के लिए, मान लीजिए कि एक स्तनपायी की खोज की गई है जो भोजन नहीं करता है, बल्कि त्वचा के माध्यम से पोषक तत्वों को अवशोषित करता है। यदि हम खाने () व्यवहार वाले स्तनपायी वर्ग से विरासत में लेते हैं, तो यह व्यवहार नए स्तनपायी के लिए बेमानी होगा। इसके अलावा, यदि सभी व्यवहारों को अलग-अलग एकल इंटरफेस में रखा गया है, तो यह प्रत्येक स्तनपायी के वर्ग का निर्माण ठीक उसी तरह होगा जैसा कि इरादा था।

»पुस्तक की अधिक जानकारी प्रकाशक की वेबसाइट पर मिल सकती है
» सामग्री की तालिका
» Habrozhitelami के लिए अंश

कूपन पर 25% छूट -OOP

पुस्तक के पेपर संस्करण के भुगतान पर, एक इलेक्ट्रॉनिक पुस्तक ई-मेल द्वारा भेजी जाती है।

पुस्तक "ऑब्जेक्ट ओरिएंटेड दृष्टिकोण। 5 वीं इंट। ईडी। "

ठोस वस्तु उन्मुख डिजाइन सिद्धांत

1. एसआरपी: एकमात्र जिम्मेदारी सिद्धांत

2. OCP: खुला / बंद सिद्धांत

3. एलएसपी: लिस्क प्रतिस्थापन सिद्धांत

4. आईएसपी: इंटरफ़ेस शेयरिंग सिद्धांत

More articles: