10 គោលការណ៍សរសេរកម្មវិធីតម្រង់ទិសវត្ថុ រាល់អ្នកអភិវឌ្ឍន៍គួរដឹង

ជាញឹកញាប់ខ្ញុំជួបអ្នកអភិវឌ្ឍន៍ដែលមិនបានឮអំពីគោលការណ៍ SOLID (យើង បាននិយាយអំពីពួកគេយ៉ាងលម្អិតនៅទីនេះ. — ការបកប្រែ) ឬកម្មវិធីតម្រង់ទិសវត្ថុ (OOP) ឬធ្លាប់បានឮអំពីពួកវា ប៉ុន្តែកុំប្រើវាក្នុងការអនុវត្ត។ អត្ថបទនេះពិពណ៌នាអំពីអត្ថប្រយោជន៍នៃគោលការណ៍ OOP ដែលជួយអ្នកអភិវឌ្ឍន៍ក្នុងការងារប្រចាំថ្ងៃរបស់គាត់។ ពួកគេមួយចំនួនត្រូវបានគេស្គាល់យ៉ាងច្បាស់ ខ្លះទៀតមិនច្រើនទេ ដូច្នេះអត្ថបទនឹងមានប្រយោជន៍សម្រាប់អ្នកចាប់ផ្តើមដំបូង និងអ្នកសរសេរកម្មវិធីដែលមានបទពិសោធន៍។

យើងរំលឹក៖ សម្រាប់អ្នកអាន Habr ទាំងអស់ - ការបញ្ចុះតម្លៃ 10 rubles នៅពេលចុះឈ្មោះក្នុងវគ្គសិក្សា Skillbox ណាមួយដោយប្រើលេខកូដផ្សព្វផ្សាយ Habr ។

Skillbox ណែនាំ៖ វគ្គសិក្សាតាមអ៊ីនធឺណិត "អ្នកអភិវឌ្ឍន៍ Java".

ស្ងួត (កុំធ្វើម្តងទៀតដោយខ្លួនឯង)

គោលការណ៍​សាមញ្ញ​មួយ ខ្លឹមសារ​ច្បាស់​លាស់​ពី​ឈ្មោះ៖ «កុំ​ធ្វើ​ខ្លួន​ឯង​ឡើង​វិញ»។ សម្រាប់អ្នកសរសេរកម្មវិធី នេះមានន័យថាតម្រូវការដើម្បីជៀសវាងកូដស្ទួន ក៏ដូចជាឱកាសក្នុងការប្រើប្រាស់ abstraction នៅក្នុងការងាររបស់ពួកគេ។

ប្រសិនបើមានផ្នែកដដែលៗចំនួនពីរនៅក្នុងកូដនោះ ពួកគេគួរតែបញ្ចូលទៅក្នុងវិធីសាស្រ្តមួយ។ ប្រសិនបើតម្លៃ hardcoded ត្រូវបានប្រើច្រើនជាងមួយដង វាមានតម្លៃបំប្លែងវាទៅជាតម្លៃថេរសាធារណៈ។

នេះគឺចាំបាច់ដើម្បីសម្រួលកូដ និងធ្វើឱ្យវាកាន់តែងាយស្រួលក្នុងការរក្សា ដែលជាគោលដៅចម្បងរបស់ OOP ។ អ្នក​ក៏​មិន​គួរ​ប្រើ​ជ្រុល​ពេក​ដែរ ព្រោះ​កូដ​ដូចគ្នា​នឹង​មិន​ឆ្លង​កាត់​ការ​ផ្ទៀងផ្ទាត់​ជាមួយ​ទាំង OrderId និង SSN។

ការ​ផ្លាស់​ប្តូ​រ encapsulating

ផលិតផលសូហ្វវែររបស់ក្រុមហ៊ុនភាគច្រើនកំពុងវិវត្តន៍ឥតឈប់ឈរ។ នេះមានន័យថាការផ្លាស់ប្តូរត្រូវធ្វើចំពោះកូដ វាត្រូវតែគាំទ្រ។ អ្នកអាចធ្វើឱ្យជីវិតរបស់អ្នកកាន់តែងាយស្រួលដោយប្រើ encapsulation ។ វានឹងអនុញ្ញាតឱ្យអ្នកធ្វើតេស្ត និងរក្សាមូលដ្ឋានកូដដែលមានស្រាប់របស់អ្នកកាន់តែមានប្រសិទ្ធភាព។ នេះគឺជាឧទាហរណ៍មួយ។.

ប្រសិនបើអ្នកសរសេរជាភាសាចាវ៉ា កំណត់វិធីសាស្រ្តឯកជន និងអថេរតាមលំនាំដើម.

គោលការណ៍បើក / បិទ

គោលការណ៍នេះអាចត្រូវបានគេចងចាំយ៉ាងងាយស្រួលដោយការអានសេចក្តីថ្លែងការណ៍ខាងក្រោម៖ "អង្គភាពកម្មវិធី (ថ្នាក់ ម៉ូឌុល មុខងារ។ល។) គួរតែបើកសម្រាប់ផ្នែកបន្ថែម ប៉ុន្តែបិទសម្រាប់ការកែប្រែ។" នៅក្នុងការអនុវត្ត នេះមានន័យថា ពួកគេអាចអនុញ្ញាតឱ្យផ្លាស់ប្តូរអាកប្បកិរិយារបស់ពួកគេដោយមិនចាំបាច់ផ្លាស់ប្តូរកូដប្រភព។

គោលការណ៍មានសារៈសំខាន់នៅពេលដែលការផ្លាស់ប្តូរកូដប្រភពទាមទារការកែប្រែកូដ ការធ្វើតេស្តឯកតា និងនីតិវិធីផ្សេងទៀត។ កូដដែលអនុវត្តតាមគោលការណ៍បើក/បិទមិនផ្លាស់ប្តូរនៅពេលពង្រីក ដូច្នេះមានបញ្ហាតិចជាងមុនជាមួយវា។

នេះគឺជាឧទាហរណ៍នៃកូដដែលបំពានគោលការណ៍នេះ។

ប្រសិនបើអ្នកត្រូវការផ្លាស់ប្តូរអ្វីមួយនៅក្នុងវា វានឹងចំណាយពេលច្រើន ដោយសារផ្នែកទាំងអស់នៃកូដដែលមានទំនាក់ទំនងជាមួយបំណែកដែលចង់បាននឹងត្រូវផ្លាស់ប្តូរ។

ដោយវិធីនេះ ការបើកចំហ-បិទ គឺជាគោលការណ៍មួយនៃ SOLID ។

គោលការណ៍ទំនួលខុសត្រូវតែមួយ (SRP)

គោលការណ៍មួយទៀតពីសំណុំ SOLID ។ វាចែងថា "មានមូលហេតុតែមួយគត់ដែលបណ្តាលឱ្យមានការផ្លាស់ប្តូរនៅក្នុងថ្នាក់" ។ ថ្នាក់ដោះស្រាយបញ្ហាតែមួយគត់។ វាអាចមានវិធីសាស្រ្តជាច្រើន ប៉ុន្តែពួកវានីមួយៗត្រូវបានប្រើដើម្បីដោះស្រាយបញ្ហាទូទៅប៉ុណ្ណោះ។ វិធីសាស្រ្តនិងលក្ខណៈសម្បត្តិទាំងអស់គួរតែបម្រើតែនេះប៉ុណ្ណោះ។

តម្លៃនៃគោលការណ៍នេះគឺថាវាបន្ធូរការភ្ជាប់គ្នារវាងសមាសភាគកម្មវិធីនីមួយៗ និងកូដ។ ប្រសិនបើអ្នកបន្ថែមមុខងារច្រើនជាងមួយទៅថ្នាក់មួយ វាណែនាំទំនាក់ទំនងរវាងមុខងារទាំងពីរ។ ដូចនេះ ប្រសិនបើអ្នកផ្លាស់ប្តូរមួយក្នុងចំណោមពួកវា មានឱកាសខ្ពស់ក្នុងការបំផ្លាញទីពីរ ដែលភ្ជាប់ជាមួយទីមួយ។ ហើយនេះមានន័យថាការបង្កើនវដ្តនៃការធ្វើតេស្តដើម្បីកំណត់បញ្ហាទាំងអស់ជាមុន។

គោលការណ៍បញ្ច្រាសភាពអាស្រ័យ (DIP)

ខាងលើគឺជាឧទាហរណ៍កូដដែល AppManager ពឹងផ្អែកលើ EventLogWriter ដែលនៅក្នុងវេនត្រូវបានភ្ជាប់យ៉ាងជិតស្និទ្ធជាមួយ AppManager ។ ប្រសិនបើអ្នកត្រូវការវិធីផ្សេងដើម្បីបង្ហាញការជូនដំណឹង មិនថាវារុញ សារ SMS ឬអ៊ីមែល អ្នកត្រូវផ្លាស់ប្តូរថ្នាក់ AppManager ។

បញ្ហាអាចត្រូវបានដោះស្រាយដោយប្រើ DIP ។ ដូច្នេះជំនួសឱ្យ AppManager យើងស្នើសុំ EventLogWriter ដែលនឹងត្រូវបានបញ្ចូលដោយប្រើក្របខ័ណ្ឌ។

DIP ធ្វើឱ្យវាអាចជំនួសម៉ូឌុលនីមួយៗយ៉ាងងាយស្រួលជាមួយអ្នកដទៃដោយការផ្លាស់ប្តូរម៉ូឌុលអាស្រ័យ។ វាធ្វើឱ្យវាអាចផ្លាស់ប្តូរម៉ូឌុលមួយដោយមិនប៉ះពាល់ដល់អ្នកដទៃ។

សមាសភាពជំនួសឱ្យមរតក

មានវិធីសំខាន់ពីរក្នុងការប្រើកូដឡើងវិញ៖ មរតក និងសមាសភាព ដែលទាំងពីរនេះមានគុណសម្បត្តិ និងគុណវិបត្តិរៀងៗខ្លួន។ ជាធម្មតាទីពីរត្រូវបានគេពេញចិត្តព្រោះវាមានភាពបត់បែនជាង។

សមាសភាពផ្តល់ឱ្យអ្នកនូវសមត្ថភាពក្នុងការផ្លាស់ប្តូរឥរិយាបថនៃថ្នាក់នៅពេលដំណើរការដោយកំណត់លក្ខណៈសម្បត្តិរបស់វា។ នៅពេលអនុវត្តចំណុចប្រទាក់ polymorphism ត្រូវបានប្រើដែលផ្តល់នូវការអនុវត្តដែលអាចបត់បែនបាន។

សូម្បីតែ Java ដែលមានប្រសិទ្ធភាពដោយ Joshua Bloch ផ្តល់ដំបូន្មានឱ្យជ្រើសរើសសមាសភាពលើមរតក។

គោលការណ៍ជំនួស Barbara Liskov (LSP)

គោលការណ៍មួយទៀតពីប្រអប់ឧបករណ៍ SOLID ។ វាចែងថាប្រភេទរងត្រូវតែអាចជំនួសបានសម្រាប់ប្រភេទ supertype ។ នោះគឺវិធីសាស្រ្ត និងមុខងារដែលធ្វើការជាមួយ superclass គួរតែអាចដំណើរការដោយគ្មានបញ្ហាជាមួយ subclasss របស់វា។

LSP ត្រូវបានផ្សារភ្ជាប់ជាមួយនឹងគោលការណ៍ទំនួលខុសត្រូវតែមួយ និងគោលការណ៍ទទួលខុសត្រូវរួម។ ប្រសិនបើ class ផ្តល់មុខងារច្រើនជាង subclass នោះថ្នាក់ក្រោយនឹងមិនគាំទ្រមុខងារមួយចំនួនទេ ដោយបំពានគោលការណ៍នេះ។

នេះគឺជាបំណែកនៃកូដដែលផ្ទុយនឹង LSP ។

វិធីសាស្រ្តផ្ទៃ (ចតុកោណ r) គណនាផ្ទៃដីនៃចតុកោណកែង។ កម្មវិធីនឹងគាំងបន្ទាប់ពីដំណើរការ Square ពីព្រោះ Square មិនមែនជាចតុកោណនៅទីនេះទេ។ យោងតាមគោលការណ៍ LSP មុខងារដែលប្រើសេចក្តីយោងទៅថ្នាក់មូលដ្ឋានគួរតែអាចប្រើវត្ថុនៃថ្នាក់ដែលបានមកពីដោយគ្មានការណែនាំបន្ថែម។

គោលការណ៍នេះ ដែលជានិយមន័យជាក់លាក់នៃប្រភេទរងមួយ ត្រូវបានស្នើឡើងដោយ Barbara Liskov នៅក្នុងសុន្ទរកថាសន្និសីទឆ្នាំ 1987 ដែលមានចំណងជើងថា "ការសង្ខេបទិន្នន័យ និងឋានានុក្រម" ដូច្នេះឈ្មោះរបស់វា។

គោលការណ៍បំបែកចំណុចប្រទាក់ (ISP)

គោលការណ៍រឹងមួយទៀត។ យោងតាមវាចំណុចប្រទាក់ដែលមិនត្រូវបានប្រើមិនគួរត្រូវបានអនុវត្តទេ។ ការធ្វើតាមគោលការណ៍នេះជួយឱ្យប្រព័ន្ធរក្សាភាពបត់បែន និងសមរម្យសម្រាប់ការកែតម្រូវឡើងវិញ នៅពេលដែលការផ្លាស់ប្តូរត្រូវបានធ្វើឡើងចំពោះតក្កវិជ្ជាប្រតិបត្តិការ។

ភាគច្រើន ស្ថានភាពនេះកើតឡើងនៅពេលដែលចំណុចប្រទាក់មានមុខងារជាច្រើនក្នុងពេលតែមួយ ហើយម៉ាស៊ីនភ្ញៀវត្រូវការតែមួយក្នុងចំណោមពួកវាប៉ុណ្ណោះ។

ចាប់តាំងពីការសរសេរចំណុចប្រទាក់គឺជាកិច្ចការដ៏លំបាកមួយ ការផ្លាស់ប្តូរវាបន្ទាប់ពីការងារត្រូវបានបញ្ចប់ដោយមិនធ្វើឱ្យខូចអ្វីទាំងអស់នឹងក្លាយជាបញ្ហាប្រឈមមួយ។

អត្ថប្រយោជន៍នៃគោលការណ៍ ISP នៅក្នុង Java គឺថា វិធីសាស្ត្រទាំងអស់ត្រូវតែអនុវត្តជាមុនសិន ហើយមានតែពេលនោះទេ ពួកគេអាចប្រើដោយថ្នាក់។ ដូច្នេះគោលការណ៍ធ្វើឱ្យវាអាចកាត់បន្ថយចំនួនវិធីសាស្រ្ត។

កម្មវិធីសម្រាប់ចំណុចប្រទាក់ មិនមែនជាការអនុវត្តទេ។

អ្វីគ្រប់យ៉ាងនៅទីនេះគឺច្បាស់ពីឈ្មោះ។ ការអនុវត្តគោលការណ៍នេះនាំទៅដល់ការបង្កើតកូដដែលអាចបត់បែនបានដែលអាចធ្វើការជាមួយការអនុវត្តថ្មីនៃចំណុចប្រទាក់។

អ្នកគួរប្រើប្រភេទចំណុចប្រទាក់សម្រាប់អថេរ ប្រភេទត្រឡប់ ឬប្រភេទអាគុយម៉ង់វិធីសាស្ត្រ។ ឧទាហរណ៍មួយកំពុងប្រើ SuperClass ជាជាង SubClass ។

នោះគឺ៖

បញ្ជីលេខ = getNumbers();

ប៉ុន្តែមិនមែន៖

លេខ ArrayList = getNumbers();

នេះគឺជាការអនុវត្តជាក់ស្តែងនៃអ្វីដែលបានពិភាក្សាខាងលើ។

គោលការណ៍នៃគណៈប្រតិភូ

ឧទាហរណ៍ទូទៅគឺវិធីសាស្ត្រ equals() និង hashCode() នៅក្នុង Java ។ នៅពេលដែលវាចាំបាច់ដើម្បីប្រៀបធៀបវត្ថុពីរ សកម្មភាពនេះត្រូវបានផ្ទេរទៅថ្នាក់ដែលត្រូវគ្នាជំនួសឱ្យម៉ាស៊ីនភ្ញៀវមួយ។

អត្ថប្រយោជន៍នៃគោលការណ៍គឺថាមិនមានការចម្លងកូដទេហើយវាមានលក្ខណៈសាមញ្ញក្នុងការផ្លាស់ប្តូរអាកប្បកិរិយា។ វាក៏អនុវត្តចំពោះប្រតិភូព្រឹត្តិការណ៍ផងដែរ។

គោលការណ៍ទាំងអស់នេះអនុញ្ញាតឱ្យអ្នកសរសេរកូដដែលអាចបត់បែនបាន ស្រស់ស្អាត និងអាចទុកចិត្តបានជាមួយនឹងភាពស្អិតរមួតខ្ពស់ និងការភ្ជាប់ទាប។ ជាការពិតណាស់ ទ្រឹស្ដីគឺល្អ ប៉ុន្តែសម្រាប់អ្នកអភិវឌ្ឍន៍ដើម្បីប្រើប្រាស់ចំណេះដឹងដែលទទួលបាន ការអនុវត្តគឺចាំបាច់។ នៅពេលដែលអ្នកបានស្ទាត់នូវគោលការណ៍ OOP ជំហានបន្ទាប់របស់អ្នកប្រហែលជាត្រូវរៀនពីគំរូរចនា ដើម្បីដោះស្រាយបញ្ហាទូទៅនៃការអភិវឌ្ឍន៍កម្មវិធី។

Skillbox ណែនាំ៖

• វគ្គសិក្សាជាក់ស្តែង "អ្នកអភិវឌ្ឍន៍ចល័ត PRO".
• បានអនុវត្តវគ្គសិក្សាតាមអ៊ីនធឺណិត "អ្នកវិភាគទិន្នន័យនៅក្នុង Python".
• វគ្គសិក្សាជាក់ស្តែងរយៈពេលពីរឆ្នាំ "ខ្ញុំជាអ្នកបង្កើតគេហទំព័រ PRO".

ប្រភព: www.habr.com