SOLID რა არის ობიექტზე ორიენტირებული პროგრამირების 5 პრინციპი

მყარი მყარი გეომეტრიული ფიგურები
სასწავლო
1

SOLID არის აბრევიატურა, რომელიც გულისხმობს ობიექტზე ორიენტირებული დიზაინის ხუთ პრინციპს (OOD ან OOP). ეს არის სახელმძღვანელო პრინციპები, რომელთა საშუალებითაც დეველოპერებს შეუძლიათ შექმნან პროგრამული უზრუნველყოფა, რომლის მართვა, შენარჩუნება და გაფართოება მარტივია. ამ კონცეფციების გაგება უკეთეს შემქმნელს შეგიქმნით და დაგეხმარებათ პროგრამული უზრუნველყოფის მართვის პრობლემების თავიდან ასაცილებლად. რას ნიშნავს იყო კარგი პროგრამისტი?

ყველას, ვისაც აქვს გარკვეული პროგრამის გამოცდილება, განიხილავს სხვების მიერ დაწერილ პროგრამულ კოდს, მათი კარიერული გზის საფუძველზე, განსჯის პარამეტრების გამოყენებით.

ჩემი პროფესიული კარიერის განმავლობაში, მე ვიცნობდი ბევრ დეველოპერს და ვნახე ათასობით კოდის ხაზი და როდესაც დეველოპერის უნარის შეფასება დამჭირდა, ძირითადად ორ ფაქტორს ვუყურებ:

  • სიმარტივე კოდის წაკითხვისას;
  • რამდენად შესაძლებელია მათი კოდი მუშაობდეს და დროთა განმავლობაში განვითარდეს.

საბედნიეროდ, არსებობს რამდენიმე საფუძველი ან პრინციპი, რაც აადვილებს უკეთ კოდირებას.

აბრევიატურა SOLID ნიშნავს:
S: ერთიანი პასუხისმგებლობის პრინციპი
O: ღია-დახურული პრინციპი
L: ლისკოვის ჩანაცვლების პრინციპი
Iინტერფეისის სეგრეგაციის პრინციპი
D: დამოკიდებულების შებრუნების პრინციპი

დავიწყოთ პირველი SOLID პრინციპის შესწავლით, კერძოდ

ერთი პასუხისმგებლობის პრინციპი

კლასს (ან მოდულს) უნდა ჰქონდეს მხოლოდ ერთი მიზეზი შეცვალოს, განვითარდეს.

თავად კონცეფცია ძალიან მარტივია, მაგრამ ამ სიმარტივის მისაღწევად, განხორციელების გზა შეიძლება ძალიან რთული იყოს. კლასს უნდა ჰქონდეს შეცვლის მხოლოდ ერთი მიზეზი.

Მაგრამ რატომ? 

რატომ არის ძალიან მნიშვნელოვანი შეცვლის მხოლოდ ერთი მიზეზი?

მაგალითად, თუ შეცვლის ორი განსხვავებული მიზეზი არსებობს, საფიქრებელია, რომ ორ სხვადასხვა გუნდს შეეძლო ერთ კოდზე მუშაობა ორი განსხვავებული მიზეზის გამო. თითოეულს მოუწევს საკუთარი გადაწყვეტილების დანერგვა, რაც შედგენილი ენის შემთხვევაში (როგორიცაა C ++, C # ან Java) შეიძლება გამოიწვიოს მოდულები, რომლებიც შეუთავსებელია სხვა გუნდებთან ან პროგრამის სხვა ნაწილებთან.

კიდევ ერთი მაგალითი, თუ თქვენ ინტერპრეტირებულ ენას იყენებთ, შეიძლება სხვადასხვა მიზეზის გამო მოგიწიოთ იმავე კლასის ან მოდულის ხელახლა გამოცდა. ეს ნიშნავს მეტ სამუშაოს, დროსა და ძალისხმევას ხარისხის კონტროლისთვის.

კლასის ან მოდულის ერთადერთი მახასიათებლის იდენტიფიცირება გაცილებით რთულია, ვიდრე ტესტების გასაშვებად მხოლოდ სიაში შესვლა. 

შევეცადოთ ვიფიქროთ ნაკლებად ტექნიკური თვალსაზრისით, ანუ შევეცადოთ გავაანალიზოთ ჩვენი კლასის ან მოდულის მომხმარებელი, ანუ ვინ გამოიყენებს მას. ფუნდამენტური ასპექტი, რომელიც ყოველთვის უნდა გვახსოვდეს, არის ის ფაქტი, რომ ჩვენს მიერ შემუშავებული აპლიკაციის ან სისტემის მომხმარებლები, რომლებსაც ემსახურება კონკრეტული მოდული, იქნება ის, ვინც ითხოვს მასში ცვლილებების შეტანას. მომსახურეები მოითხოვენ კლასის ან მოდულის შეცვლას. 

მოდულების რამდენიმე მაგალითი და მათი გამოყენება:

  • სარემონტო მოდული: მომხმარებელი შედგება მონაცემთა ბაზის ადმინისტრატორებისა და პროგრამული უზრუნველყოფის არქიტექტორებისგან.
  • ანგარიშგების მოდული: მომხმარებელი შედგება ოფისის მუშაკებისგან, ბუღალტრებისგან და პროდუქციისგან.
  • გადახდების გაანგარიშების მოდული სახელფასო მართვის სისტემისთვისმომხმარებლებს შეუძლიათ მოიზიდონ იურისტები, მენეჯერები და ბუღალტრები.
  • ტექსტური ძიების მოდული ბიბლიოთეკის მართვის სისტემისთვის: მომხმარებლებს შეუძლიათ წარმოადგინონ ბიბლიოთეკარი ან თავად ბიბლიოთეკის სტუმრები და მომხმარებლები.

ასე რომ, თუ პირველი ნაბიჯი არის მსახიობების ძებნა ან მსახიობი, რომელსაც მოდულის თანამოსაუბრის როლი აქვს, ყველა როლის ინდივიდების ასოცირება შეიძლება რთული იყოს. მცირე კომპანიაში ერთ ადამიანს შეუძლია მრავალი როლის შესრულება, ხოლო დიდ კომპანიაში შეიძლება არსებობდეს მრავალი ადამიანი, რომლებსაც აქვთ ერთი როლი. 

უფრო გონივრული ჩანს როლების განსაზღვრა, ვიდრე ადამიანების ან მომხმარებლების.

ამიტომ:

  • პროგრამული სისტემის მომხმარებელი განსაზღვრავს ცვლილების მიზეზებს;
  • პასუხისმგებლობა არის ფუნქციების ოჯახი, რომელიც აკმაყოფილებს კონკრეტული მსახიობის, ანუ სისტემის მომხმარებლის საჭიროებებს;
  • მსახიობები, მომხმარებელი ხდება ფუნქციონალური ჯგუფის ოჯახის ცვლილების წყარო, რომელიც უნდა აკმაყოფილებდეს მომხმარებლის საჭიროებას;
  • მომხმარებლის საჭიროებების ევოლუცია, ხელმძღვანელობს ფუნქციონირების ევოლუციას;

მყარი პრინციპები

მოდით ვნახოთ რამდენიმე მაგალითი

დავუშვათ, რომ გვაქვს წიგნის კლასი, რომელიც მოიცავს წიგნის კონცეფციას და მის ფუნქციურობას.

კლასის წიგნი {

    ფუნქცია getTitle () {

        დაბრუნება "დიდი წიგნი";

    }

    ფუნქცია getAuthor () {

        დაბრუნება "ალესანდრო ბარიკო";

    }

    შემდეგი გვერდის ფუნქცია () {

        // შემდეგი გვერდი

    }

    ფუნქცია printCurrentPage () {

        echo "მიმდინარე გვერდის შინაარსი";

    }

}

ეს ძალიან ნორმალური კლასია. ჩვენ გვაქვს წიგნი და კლასს შეუძლია მოგვცეს სათაური, მათ მოგვცეს ავტორი და მათ შეუძლიათ განაგრძონ წინსვლა. დაბოლოს, მას ასევე შეუძლია მიმდინარე გვერდის ეკრანზე დაბეჭდვა. 

ამასთან, მცირე პრობლემაა. 

ფიქრობთ წიგნის ობიექტის მენეჯმენტში მონაწილე მსახიობებზე, ვინ შეიძლება იყვნენ ისინი? 

აქ ადვილად შეგვიძლია ვიფიქროთ ორ განსხვავებულ მსახიობზე: წიგნის მენეჯმენტი (როგორც ბიბლიოთეკარი) და მონაცემთა წარდგენის მექანიზმი (მაგალითად, როგორ გვინდა მომხმარებლისთვის შინაარსის მიწოდება: ეკრანზე, მომხმარებლის გრაფიკული ინტერფეისი, მხოლოდ ტექსტური ინტერფეისი, შესაძლოა ბეჭდვა). 

ამიტომ, კლასთან ურთიერთქმედების ორი ძალიან განსხვავებული მსახიობი გვყავს.

მოკლედ რომ ვთქვათ, ამ კლასს აქვს ნაზავი:

  • ბიზნეს ლოგიკა 
  • პრეზენტაცია 

ეს შეიძლება იყოს პრობლემა, რადგან იგი არღვევს ერთიანი პასუხისმგებლობის პრინციპს (SRP). 

როგორ შეგვიძლია შევცვალოთ, როგორ გავაუმჯობესოთ ეს კოდი, რომ დავიცვათ ერთი პასუხისმგებლობის პრინციპი?

გადახედეთ შემდეგ კოდს:

კლასის წიგნი {

    ფუნქცია getTitle () {

        დაბრუნება "Oceano Mare";

    }

    ფუნქცია getAuthor () {

        დაბრუნება "ალესანდრო ბარიკო";

    }

    ფუნქციის გადაბრუნება () {

        // შემდეგი გვერდი

    }

    ფუნქცია getCurrentPage () {

        echo "მიმდინარე გვერდის შინაარსი";

    }

}

ინტერფეისი პრინტერი {

    ფუნქციის printPage ($ გვერდი);

}

კლასი StampaLibro ახორციელებს პრინტერს {

    ფუნქციის ბეჭდვითი გვერდები ($ გვერდი) {

        ექოს $ გვერდი;

    }

}

 

კლასი HtmlPrinter ახორციელებს პრინტერს {

    ფუნქციის ბეჭდვითი გვერდები ($ გვერდი) {

        ექო ' ' $ გვერდი. ' ';

    }

}

ეს ძალიან მარტივი მაგალითი გვიჩვენებს, თუ როგორ უნდა გამოვყოთ პრეზენტაცია ბიზნესის ლოგიკისგან და SRP– ის შესაბამისად, ის გთავაზობთ დიდ უპირატესობებს ჩვენი პროექტის მოქნილობაში.

მოდით ვნახოთ კიდევ ერთი მაგალითი:

ზემოთ მოყვანილი მაგალითის მსგავსია, როდესაც ობიექტს შეუძლია გადარჩენა და მოხსნა პრეზენტაციისგან.

კლასის წიგნი {

    ფუნქცია getTitle () {

        დაბრუნება "Oceano Mare";

    }

    ფუნქცია getAuthor () {

        დაბრუნება "ალესანდრო ბარიკო";

    }

    ფუნქციის გადაბრუნება () {

        // შემდეგი გვერდი

    }

    ფუნქცია getCurrentPage () {

        დააბრუნე "მიმდინარე გვერდის შინაარსი";

    }

    ფუნქციის შენახვა () {

        $ filename = '/ დოკუმენტები /'. $ this-> getTitolo (). '-'. $ ეს-> getAuthor ();

        file_put_contents ($ filename, სერიალიზაცია ($ $ ეს));

    }

}

როგორც ადრე, აქაც შეგვიძლია დავადგინოთ სხვადასხვა მსახიობები, როგორიცაა წიგნის მენეჯმენტი (როგორც ბიბლიოთეკარი) და გამძლეობა. ყოველთვის, როდესაც გვსურს შევცვალოთ გვერდიდან გვერდზე გადასვლის გზა, უნდა შევცვალოთ ეს კლასი. ცვლილების რამდენიმე მიზეზი შეიძლება გვქონდეს.

კლასის წიგნი {

    ფუნქცია getTitle () {

        დაბრუნება "Oceano Mare";

    }

    ფუნქცია getAuthor () {

        დაბრუნება "ალესანდრო ბარიკო";

    }

    ფუნქციის გადაბრუნება () {

        // შემდეგი გვერდი

    }

    ფუნქცია getCurrentPage () {

        დააბრუნე "მიმდინარე გვერდის შინაარსი";

    }

}

კლასი SimpleFilePersistence {

    ფუნქციის დაზოგვა (დაჯავშნა $ წიგნი) {

        $ filename = '/ დოკუმენტები /'. $ book-> getTitle (). '-'. $ book-> getAuthor ();

        file_put_contents ($ filename, სერიალიზაცია ($ book));

    }

}

დაჟინებული მოქმედების სხვა კლასში გადატანა აშკარად გამოყოფს პასუხისმგებლობას და ჩვენ თავისუფლად შეგვიძლია გავცვლით დაჟინების მეთოდებს ისე, რომ გავლენა არ მოახდინოთ წიგნის კლასზე. მაგალითად, DatabasePersistence კლასის დანერგვა ტრივიალური იქნება და წიგნის ოპერაციების გარშემო აგებული ჩვენი ბიზნეს ლოგიკა არ შეიცვლება.

განაგრძეთ მეორე პრინციპის წაკითხვა ღია / დახურული ->

1 კომენტარი

დატოვე კომენტარი

Il Tuo indirizzo ელ არასამთავრობო სარა pubblicato. მე campi sono obbligatori contrassegnati *

ლისკოვის პრინციპი
სასწავლო
ლისკოვის ჩანაცვლების პრინციპი, მესამე SOLID პრინციპი

ბავშვთა კლასებმა არასოდეს უნდა იმოქმედონ ან შეცვალონ მშობელთა კლასის განსაზღვრებებზე. ამ პრინციპის კონცეფცია შემოიტანა ბარბარა ლისკოვმა 1987 წლის კონფერენციის მთავარ მოხსენებაში და შემდეგ გამოქვეყნდა სტატიაში, ჯანეტ ვინგთან ერთად, 1994 წელს. მათი თავდაპირველი განმარტება

Google– ის მარკეტინგის ტენდენციები
სასწავლო
როგორ გამოვიყენოთ Google Trends რეალურ დროში მარკეტინგისთვის

კომპანიების მიერ 2020 წელს ერთ-ერთი მთავარი სირთულე იყო იმის გაგება, თუ რომელი პროდუქტის სექტორში უნდა განხორციელდეს ბიზნესის დივერსიფიკაცია: სინამდვილეში, სამრეწველო სექტორების უმეტესობამ განიცადა მძიმე შედეგები, რაც კომპანიების მხრიდან მათში შეღწევას თითქმის შეუძლებელს ხდის, განსაკუთრებით ახალი მოთამაშის როლს. წარმოების ძალიან მცირე სექტორები ...

ბიზნეს დაზვერვის სტრატეგია
მეთოდები
სტრატეგიები წარმატებული ბიზნეს დაზვერვისთვის

თქვენი ბიზნეს დაზვერვის წარმატებული სტრატეგიის შემუშავება იწყება მიზნების სწორი ხედვით. ქვემოთ ვხედავთ რამდენიმე ფუნდამენტურ საკითხს. არსებული ვითარების შეფასება მძიმე შეცდომა იქნება ამ ასპექტის შეფასება. არსებული ვითარების შეფასება ნიშნავს პროცესების, სტრუქტურების ანალიზს ...