Eclipse ជាវេទិកាបច្ចេកវិទ្យាសម្រាប់ 1C: ឧបករណ៍អភិវឌ្ឍន៍សហគ្រាស

ប្រហែល, លេបត្របាក់ តាំងពីយូរយារណាស់មកហើយ មិនត្រូវការការណែនាំពិសេសទេ។ មនុស្សជាច្រើនស្គាល់ Eclipse អរគុណចំពោះឧបករណ៍អភិវឌ្ឍន៍ Eclipse Java (JDT) វាគឺជា Java IDE ប្រភពបើកចំហដ៏ពេញនិយមនេះ ដែលអ្នកអភិវឌ្ឍន៍ភាគច្រើនភ្ជាប់ជាមួយពាក្យ "Eclipse" ។ ទោះជាយ៉ាងណាក៏ដោយ Eclipse គឺជាវេទិកាដែលអាចពង្រីកបានសម្រាប់ការរួមបញ្ចូលឧបករណ៍អភិវឌ្ឍន៍ (វេទិកា Eclipse) និង IDEs មួយចំនួនដែលត្រូវបានបង្កើតឡើងនៅលើមូលដ្ឋានរបស់វា រួមទាំង JDT ផងដែរ។ Eclipse គឺជាគម្រោង Eclipse ដែលជាគម្រោងកម្រិតកំពូលដែលសម្របសម្រួលការអភិវឌ្ឍន៍ Eclipse Platform និង JDT និង Eclipse SDK ដែលជាលទ្ធផលនៃការអភិវឌ្ឍន៍នោះ។ ជាចុងក្រោយ Eclipse គឺជាមូលនិធិប្រភពបើកចំហដែលមានសហគមន៍ដ៏ធំនៃគម្រោង មិនមែនទាំងអស់ត្រូវបានសរសេរជាភាសា Java ឬទាក់ទងនឹងឧបករណ៍អភិវឌ្ឍន៍ទេ (ឧទាហរណ៍ គម្រោង Eclipse IoT и វិទ្យាសាស្ត្រសូរ្យគ្រាស) ពិភពនៃ Eclipse មានភាពចម្រុះណាស់។

នៅក្នុងអត្ថបទនេះ ដែលជាទិដ្ឋភាពទូទៅនៅក្នុងធម្មជាតិ យើងនឹងព្យាយាមរកមើលមូលដ្ឋានគ្រឹះមួយចំនួននៃស្ថាបត្យកម្ម Eclipse ជាវេទិកាសម្រាប់បង្កើតឧបករណ៍អភិវឌ្ឍន៍រួមបញ្ចូលគ្នា និងផ្តល់គំនិតដំបូងអំពីសមាសធាតុ Eclipse ដែលបង្កើតជាមូលដ្ឋានគ្រឹះនៃបច្ចេកវិទ្យា។ វេទិកាសម្រាប់ "អ្នកកំណត់រចនាសម្ព័ន្ធថ្មី" 1C: សហគ្រាស។ 1C: ឧបករណ៍អភិវឌ្ឍន៍សហគ្រាស. ជាការពិតណាស់ ការពិនិត្យឡើងវិញបែបនេះនឹងជៀសមិនរួច មានលក្ខណៈស្រពិចស្រពិល និងមានកម្រិត រួមទាំងដោយសារតែយើងកំពុងផ្តោតការយកចិត្តទុកដាក់មិនត្រឹមតែលើអ្នកអភិវឌ្ឍន៍ Eclipse ដែលជាទស្សនិកជនគោលដៅប៉ុណ្ណោះទេ។ ទោះជាយ៉ាងណាក៏ដោយ យើងសង្ឃឹមថាសូម្បីតែអ្នកអភិវឌ្ឍន៍ Eclipse ដែលមានបទពិសោធន៍នឹងអាចស្វែងរកព័ត៌មានគួរឱ្យចាប់អារម្មណ៍នៅក្នុងអត្ថបទ។ ជាឧទាហរណ៍ យើងនឹងនិយាយអំពី "អាថ៌កំបាំងនៃសូរ្យគ្រាស" ដែលជាគម្រោងថ្មី និងមិនសូវស្គាល់ Eclipse Handlyដែលត្រូវបានបង្កើតឡើង និងគាំទ្រដោយ 1C ។

ការណែនាំអំពីស្ថាបត្យកម្ម Eclipse

ជាដំបូង សូមក្រឡេកមើលទិដ្ឋភាពទូទៅមួយចំនួននៃស្ថាបត្យកម្ម Eclipse ដោយប្រើឧទាហរណ៍ ឧបករណ៍អភិវឌ្ឍន៍ Eclipse Java (JDT) ។ ជម្រើសនៃ JDT ជាឧទាហរណ៍មិនមែនចៃដន្យទេ។ នេះ​ជា​បរិយាកាស​អភិវឌ្ឍន៍​រួម​ដំបូង​គេ​ដែល​បង្ហាញ​នៅ​ក្នុង​ Eclipse។ គម្រោង *DT Eclipse ផ្សេងទៀតដូចជា Eclipse C/C++ Development Tooling (CDT) ត្រូវបានបង្កើតឡើងនៅពេលក្រោយ ហើយខ្ចីទាំងគោលការណ៍ស្ថាបត្យកម្មមូលដ្ឋាន និងបំណែកកូដប្រភពនីមួយៗពី JDT។ មូលដ្ឋានគ្រឹះនៃស្ថាបត្យកម្មដែលបានដាក់ក្នុង JDT គឺពាក់ព័ន្ធដល់សព្វថ្ងៃនេះសម្រាប់ IDE ស្ទើរតែទាំងអស់ដែលបានសាងសង់នៅលើកំពូលនៃ Eclipse Platform រួមទាំង 1C: ឧបករណ៍អភិវឌ្ឍន៍សហគ្រាស។

ជាដំបូង វាគួរតែត្រូវបានកត់សម្គាល់ថា Eclipse ត្រូវបានកំណត់លក្ខណៈដោយស្រទាប់ស្ថាបត្យកម្មច្បាស់លាស់ ជាមួយនឹងការបំបែកមុខងារឯករាជ្យភាសាពីមុខងារដែលបានរចនាឡើងដើម្បីគាំទ្រភាសាសរសេរកម្មវិធីជាក់លាក់ និងការបំបែកផ្នែក "ស្នូល" ឯករាជ្យ UI ពីសមាសធាតុដែលពាក់ព័ន្ធ។ ជាមួយចំណុចប្រទាក់អ្នកប្រើដែលគាំទ្រ។

ដូច្នេះ Eclipse Platform កំណត់ហេដ្ឋារចនាសម្ព័ន្ធទូទៅ ដែលមិនអាស្រ័យលើភាសា ហើយឧបករណ៍អភិវឌ្ឍន៍ Java បន្ថែម Java IDE ដែលមានលក្ខណៈពិសេសពេញលេញទៅ Eclipse ។ ទាំង Eclipse Platform និង JDT មានធាតុផ្សំជាច្រើន ដែលនីមួយៗជាកម្មសិទ្ធិរបស់ UI-independent “core” ឬស្រទាប់ UI (រូបភាពទី 1)។

អង្ករ។ 1. Eclipse Platform និង JDT

ចូររាយបញ្ជីសមាសធាតុសំខាន់ៗនៃវេទិកា Eclipse៖

• ពេលរត់ - កំណត់រចនាសម្ព័ន្ធកម្មវិធីជំនួយ។ សូរ្យគ្រាសត្រូវបានកំណត់លក្ខណៈដោយស្ថាបត្យកម្មម៉ូឌុល។ សំខាន់ Eclipse គឺជាការប្រមូលផ្តុំនៃ "ចំណុចបន្ថែម" និង "ផ្នែកបន្ថែម" ។
• កន្លែងធ្វើការ - គ្រប់គ្រងគម្រោងមួយ ឬច្រើន។ គម្រោងមួយមានថតឯកសារ និងឯកសារដែលត្រូវបានគូសផែនទីដោយផ្ទាល់ទៅប្រព័ន្ធឯកសារ។
• Standard Widget Toolkit (SWT) - ផ្តល់នូវធាតុចំណុចប្រទាក់អ្នកប្រើជាមូលដ្ឋានរួមបញ្ចូលជាមួយប្រព័ន្ធប្រតិបត្តិការ។
• JFace - ផ្តល់នូវក្របខ័ណ្ឌ UI មួយចំនួនដែលបង្កើតឡើងនៅលើកំពូលនៃ SWT ។
• Workbench - កំណត់គំរូ Eclipse UI៖ អ្នកកែសម្រួល ទស្សនៈ ទស្សនវិស័យ។

វាត្រូវតែនិយាយថា Eclipse Platform ក៏ផ្តល់នូវសមាសធាតុមានប្រយោជន៍ជាច្រើនទៀតសម្រាប់ការកសាងឧបករណ៍អភិវឌ្ឍន៍រួមបញ្ចូលគ្នា រួមមាន Debug, Compare, Search និង Team។ ការលើកឡើងពិសេសគួរតែត្រូវបានធ្វើឡើងពី JFace Text ដែលជាមូលដ្ឋានសម្រាប់បង្កើត "កម្មវិធីនិពន្ធឆ្លាតវៃ" នៃកូដប្រភព។ ជាអកុសល សូម្បីតែការពិនិត្យ cursory នៃសមាសភាគទាំងនេះ ក៏ដូចជាសមាសធាតុស្រទាប់ UI ក៏មិនអាចធ្វើទៅបានក្នុងវិសាលភាពនៃអត្ថបទនេះ ដូច្នេះនៅក្នុងផ្នែកដែលនៅសល់នៃផ្នែកនេះ យើងនឹងកំណត់ខ្លួនយើងទៅនឹងទិដ្ឋភាពទូទៅនៃសមាសធាតុ "ស្នូល" សំខាន់ៗនៃ Eclipse Platform និង JDT ។

ពេលវេលាដំណើរការស្នូល

ហេដ្ឋារចនាសម្ព័ន្ធកម្មវិធីជំនួយ Eclipse គឺផ្អែកលើ អូស៊ីជី និងផ្តល់ដោយគម្រោង សូរ្យគ្រាស Equinox. កម្មវិធីជំនួយ Eclipse នីមួយៗគឺជាបណ្តុំ OSGi ។ ការបញ្ជាក់របស់ OSGi កំណត់ជាពិសេសយន្តការសម្រាប់កំណែ និងដំណោះស្រាយអាស្រ័យ។ បន្ថែមពីលើយន្តការស្តង់ដារទាំងនេះ Equinox ណែនាំគំនិត ចំណុចពង្រីក. កម្មវិធីជំនួយនីមួយៗអាចកំណត់ចំណុចបន្ថែមផ្ទាល់ខ្លួនរបស់វា ហើយថែមទាំងណែនាំមុខងារបន្ថែម (“ផ្នែកបន្ថែម”) ដល់ប្រព័ន្ធដោយប្រើចំណុចបន្ថែមដែលកំណត់ដោយកម្មវិធីជំនួយដូចគ្នា ឬផ្សេងទៀត។ ការពិពណ៌នាលម្អិតនៃយន្តការ OSGi និង Equinox គឺហួសពីវិសាលភាពនៃអត្ថបទនេះ។ អនុញ្ញាតឱ្យយើងចំណាំថាម៉ូឌុលនៅក្នុង Eclipse គឺសរុប (ប្រព័ន្ធរងណាមួយ រួមទាំង Runtime មានកម្មវិធីជំនួយមួយ ឬច្រើន) ហើយស្ទើរតែទាំងអស់នៅក្នុង Eclipse គឺជាផ្នែកបន្ថែមមួយ។ ជាងនេះទៅទៀត គោលការណ៍ទាំងនេះត្រូវបានបង្កប់នៅក្នុងស្ថាបត្យកម្ម Eclipse តាំងពីយូរយារណាស់មកហើយ មុនពេលមានការដាក់ឱ្យប្រើប្រាស់ OSGi (នៅពេលនោះ ពួកគេបានប្រើប្រាស់បច្ចេកវិទ្យាផ្ទាល់ខ្លួនរបស់ពួកគេ ដែលស្រដៀងទៅនឹង OSGi)។

កន្លែងធ្វើការស្នូល

ស្ទើរតែគ្រប់បរិយាកាសអភិវឌ្ឍន៍រួមបញ្ចូលគ្នាដែលបង្កើតឡើងនៅលើកំពូលនៃវេទិកា Eclipse ដំណើរការជាមួយកន្លែងធ្វើការ Eclipse ។ វាជាកន្លែងធ្វើការដែលជាធម្មតាមានកូដប្រភពនៃកម្មវិធីដែលបានបង្កើតឡើងនៅក្នុង IDE ។ ផែនទីកន្លែងធ្វើការដោយផ្ទាល់ទៅប្រព័ន្ធឯកសារ និងមានគម្រោងដែលមានថតឯកសារ និងឯកសារ។ គម្រោង ថតឯកសារ និងឯកសារទាំងនេះត្រូវបានគេហៅថា ធនធាន កន្លែងធ្វើការ។ ការអនុវត្តកន្លែងធ្វើការនៅក្នុង Eclipse បម្រើជាឃ្លាំងសម្ងាត់ទាក់ទងនឹងប្រព័ន្ធឯកសារ ដែលធ្វើឱ្យវាអាចធ្វើទៅបានដើម្បីបង្កើនល្បឿនឆ្លងកាត់មែកធាងធនធានយ៉ាងខ្លាំង។ លើសពីនេះទៀត កន្លែងធ្វើការផ្តល់នូវសេវាកម្មបន្ថែមមួយចំនួន រួមទាំង យន្តការជូនដំណឹងសម្រាប់ការផ្លាស់ប្តូរធនធាន и ហេដ្ឋារចនាសម្ព័ន្ធអ្នកសាងសង់បន្ថែម.

សមាសធាតុធនធានស្នូល (org.eclipse.core.resources plugin) ទទួលខុសត្រូវចំពោះការគាំទ្រកន្លែងធ្វើការ និងធនធានរបស់វា។ ជាពិសេស សមាសភាគនេះផ្តល់នូវការចូលដំណើរការតាមកម្មវិធីទៅកាន់កន្លែងធ្វើការក្នុងទម្រង់ គំរូធនធាន. ដើម្បីធ្វើការប្រកបដោយប្រសិទ្ធភាពជាមួយគំរូនេះ អតិថិជនត្រូវការវិធីសាមញ្ញមួយដើម្បីបង្ហាញតំណទៅកាន់ធនធាន។ ក្នុងករណីនេះ វាជាការចង់លាក់វត្ថុដែលរក្សាទុកដោយផ្ទាល់នូវស្ថានភាពនៃធនធាននៅក្នុងគំរូពីការចូលប្រើរបស់អតិថិជន។ បើមិនដូច្នោះទេ ក្នុងករណីឧទាហរណ៍ ការលុបឯកសារ អតិថិជនអាចបន្តកាន់វត្ថុដែលលែងមាននៅក្នុងគំរូ ដោយមានបញ្ហាជាបន្តបន្ទាប់។ Eclipse ដោះស្រាយបញ្ហានេះដោយប្រើអ្វីដែលគេហៅថា ដោះស្រាយ ធនធាន។ Handle ដើរតួជាគន្លឹះ (វាស្គាល់តែផ្លូវទៅកាន់ធនធានក្នុងកន្លែងធ្វើការ) និងគ្រប់គ្រងទាំងស្រុងនូវការចូលទៅកាន់វត្ថុគំរូខាងក្នុង ដែលរក្សាទុកព័ត៌មានដោយផ្ទាល់អំពីស្ថានភាពនៃធនធាន។ ការរចនានេះគឺជាការបំរែបំរួលនៃគំរូ ដៃ/ដងខ្លួន.

អង្ករ។ រូបភាពទី 2 បង្ហាញពីពាក្យ Handle/Body idiom ដូចដែលបានអនុវត្តចំពោះគំរូធនធាន។ ចំណុចប្រទាក់ IResource តំណាងឱ្យចំណុចទាញនៃធនធាន និងជា API មិនដូចថ្នាក់ធនធាន ដែលអនុវត្តចំណុចប្រទាក់នេះ និងថ្នាក់ធនធានព័ត៌មាន ដែលតំណាងឱ្យតួដែលមិនមែនជា APIs ។ យើងសង្កត់ធ្ងន់ថា ចំណុចទាញដឹងតែផ្លូវទៅកាន់ធនធានដែលទាក់ទងទៅនឹងឫសកន្លែងធ្វើការ ហើយមិនមានតំណភ្ជាប់ទៅកាន់ព័ត៌មានធនធានទេ។ វត្ថុព័ត៌មានធនធានបង្កើតបានជា "មែកធាងធាតុ" ។ រចនាសម្ព័ន្ធទិន្នន័យនេះត្រូវបានបង្កើតឡើងទាំងស្រុងនៅក្នុងអង្គចងចាំ។ ដើម្បីស្វែងរកឧទាហរណ៍ព័ត៌មានធនធានដែលត្រូវគ្នានឹងចំណុចទាញ មែកធាងធាតុត្រូវបានឆ្លងកាត់ដោយយោងតាមផ្លូវដែលផ្ទុកនៅក្នុងចំណុចទាញនោះ។

អង្ករ។ 2. IResource និង ResourceInfo

ដូចដែលយើងនឹងឃើញនៅពេលក្រោយ ការរចនាជាមូលដ្ឋាននៃគំរូធនធាន (យើងអាចហៅវាថា ចំណុចទាញ) ត្រូវបានប្រើនៅក្នុង Eclipse សម្រាប់ម៉ូដែលផ្សេងទៀតផងដែរ។ សម្រាប់ពេលនេះ ចូររាយបញ្ជីលក្ខណៈសម្បត្តិប្លែកៗមួយចំនួននៃការរចនានេះ៖

• ចំណុចទាញគឺជាវត្ថុតម្លៃ។ វត្ថុតម្លៃគឺជាវត្ថុដែលមិនអាចផ្លាស់ប្តូរបាន ដែលសមភាពមិនផ្អែកលើអត្តសញ្ញាណ។ វត្ថុបែបនេះអាចត្រូវបានប្រើប្រាស់ដោយសុវត្ថិភាពជាសោនៅក្នុងធុង hashed ។ ចំណុចទាញជាច្រើនអាចយោងធនធានដូចគ្នា។ ដើម្បីប្រៀបធៀបពួកវា អ្នកត្រូវប្រើវិធីសាស្ត្រស្មើ(វត្ថុ)។
• Handle កំណត់ឥរិយាបថរបស់ធនធាន ប៉ុន្តែមិនមានព័ត៌មានអំពីស្ថានភាពនៃធនធាន (ទិន្នន័យតែមួយគត់ដែលវារក្សាទុកគឺ "គន្លឹះ" ដែលជាផ្លូវទៅកាន់ធនធាន)។
• Handle អាចសំដៅទៅលើធនធានដែលមិនទាន់មាន (ទាំងធនធានដែលមិនទាន់ត្រូវបានបង្កើត ឬធនធានដែលត្រូវបានលុបរួចហើយ)។ អត្ថិភាពនៃធនធានអាចត្រូវបានពិនិត្យដោយប្រើវិធីសាស្ត្រ IResource.exists() ។
• ប្រតិបត្តិការមួយចំនួនអាចត្រូវបានអនុវត្តដោយផ្អែកតែលើព័ត៌មានដែលរក្សាទុកក្នុងចំណុចទាញដោយខ្លួនឯង (ហៅថាប្រតិបត្តិការតែដៃប៉ុណ្ណោះ)។ ឧទាហរណ៍គឺ IResource.getParent(), getFullPath(), ល។ ធនធានមិនចាំបាច់មានសម្រាប់ប្រតិបត្តិការបែបនេះដើម្បីជោគជ័យនោះទេ។ ប្រតិបត្តិការដែលទាមទារធនធានដើម្បីឱ្យជោគជ័យបោះ CoreException ប្រសិនបើធនធានមិនមាន។

Eclipse ផ្តល់នូវយន្តការដ៏មានប្រសិទ្ធភាពមួយសម្រាប់ការជូនដំណឹងអំពីការផ្លាស់ប្តូរធនធានកន្លែងធ្វើការ (រូបភាពទី 3) ។ ធនធានអាចផ្លាស់ប្តូរជាលទ្ធផលនៃសកម្មភាពដែលបានអនុវត្តនៅក្នុង Eclipse IDE ខ្លួនវាផ្ទាល់ ឬជាលទ្ធផលនៃការធ្វើសមកាលកម្មជាមួយប្រព័ន្ធឯកសារ។ ក្នុងករណីទាំងពីរនេះ អតិថិជនដែលជាវការជូនដំណឹងត្រូវបានផ្តល់ព័ត៌មានលម្អិតអំពីការផ្លាស់ប្តូរនៅក្នុងទម្រង់នៃ "ធនធាន deltas" ។ ដីសណ្តពណ៌នាអំពីការផ្លាស់ប្តូររវាងរដ្ឋពីរនៃធនធានកន្លែងធ្វើការ (អនុ-) មែកធាង ហើយខ្លួនវាផ្ទាល់ជាមែកធាង ដែលថ្នាំងនីមួយៗពណ៌នាអំពីការផ្លាស់ប្តូរទៅធនធាន និងមានបញ្ជីដីសណ្តនៅកម្រិតបន្ទាប់ដែលពិពណ៌នាអំពីការផ្លាស់ប្តូរធនធានកុមារ។

អង្ករ។ 3. IResourceChangeEvent និង IResourceDelta

យន្តការជូនដំណឹងដោយផ្អែកលើ deltas ធនធានមានលក្ខណៈដូចខាងក្រោមៈ

• ការផ្លាស់ប្តូរតែមួយ និងការផ្លាស់ប្តូរជាច្រើនត្រូវបានពិពណ៌នាដោយប្រើរចនាសម្ព័ន្ធដូចគ្នា ចាប់តាំងពីតំបន់ដីសណ្តត្រូវបានសាងសង់ដោយប្រើគោលការណ៍នៃសមាសភាពឡើងវិញ។ អតិថិជនដែលជាវអាចដំណើរការការជូនដំណឹងអំពីការផ្លាស់ប្តូរធនធានដោយប្រើតំណពូជដដែលៗតាមរយៈមែកធាងនៃដីសណ្ត។
• តំបន់ដីសណ្តមានព័ត៌មានពេញលេញអំពីការផ្លាស់ប្តូរធនធាន រួមទាំងចលនារបស់វា និង/ឬការផ្លាស់ប្តូរនៅក្នុង "សញ្ញាសម្គាល់" ដែលភ្ជាប់ជាមួយវា (ឧទាហរណ៍ កំហុសក្នុងការចងក្រងត្រូវបានតំណាងជាសញ្ញាសម្គាល់)។
• ដោយសារសេចក្តីយោងធនធានត្រូវបានធ្វើឡើងតាមរយៈចំណុចទាញ ដីសណ្តអាចយោងធនធានពីចម្ងាយដោយធម្មជាតិ។

ដូចដែលយើងនឹងឃើញក្នុងពេលឆាប់ៗនេះ ធាតុផ្សំសំខាន់ៗនៃការរចនានៃយន្តការជូនដំណឹងអំពីការផ្លាស់ប្តូរគំរូធនធានក៏ពាក់ព័ន្ធផងដែរសម្រាប់ម៉ូដែលដែលផ្អែកលើចំណុចទាញផ្សេងទៀត។

ស្នូល JDT

គំរូធនធានកន្លែងធ្វើការ Eclipse គឺជាគំរូភាសាមូលដ្ឋាន - agnostic ។ សមាសភាគ JDT Core (កម្មវិធីជំនួយ org.eclipse.jdt.core) ផ្តល់ API សម្រាប់រុករក និងវិភាគរចនាសម្ព័ន្ធកន្លែងធ្វើការតាមទស្សនៈរបស់ Java ដែលហៅថា "គំរូ Java" (ម៉ូដែល Java) API នេះ​ត្រូវ​បាន​កំណត់​ក្នុង​លក្ខខណ្ឌ​នៃ​ធាតុ Java ដែល​ផ្ទុយ​ទៅ​នឹង API គំរូ​ធនធាន​មូលដ្ឋាន ដែល​ត្រូវ​បាន​កំណត់​ក្នុង​លក្ខខណ្ឌ​នៃ folder និង​ឯកសារ។ ចំណុចប្រទាក់ចម្បងនៃមែកធាងធាតុ Java ត្រូវបានបង្ហាញនៅក្នុងរូបភព។ ៤.

អង្ករ។ 4. ធាតុគំរូ Java

គំរូ Java ប្រើពាក្យ handle/body idiom ដូចគ្នានឹងគំរូធនធាន (រូបភាពទី 5)។ IJavaElement គឺជាចំណុចទាញ ហើយ JavaElementInfo ដើរតួជាតួខ្លួន។ ចំណុចប្រទាក់ IJavaElement កំណត់ពិធីការទូទៅចំពោះធាតុ Java ទាំងអស់។ វិធីសាស្រ្តមួយចំនួនរបស់វាគឺសម្រាប់តែដោះស្រាយប៉ុណ្ណោះ៖ getElementName(), getParent(), ល។ វត្ថុ JavaElementInfo រក្សាទុកស្ថានភាពនៃធាតុដែលត្រូវគ្នា៖ រចនាសម្ព័ន្ធ និងគុណលក្ខណៈរបស់វា។

អង្ករ។ 5. IJavaElement និង JavaElementInfo

គំរូ Java មានភាពខុសប្លែកគ្នាខ្លះក្នុងការអនុវត្តការរចនាចំណុចទាញ/តួមូលដ្ឋាន បើប្រៀបធៀបទៅនឹងគំរូធនធាន។ ដូចដែលបានកត់សម្គាល់ខាងលើ នៅក្នុងគំរូធនធាន មែកធាងធាតុ ដែលថ្នាំងរបស់ពួកគេជាវត្ថុព័ត៌មានធនធាន គឺមានទាំងស្រុងនៅក្នុងអង្គចងចាំ។ ប៉ុន្តែគំរូ Java អាចមានចំនួនធាតុធំជាងធនធានមែកធាង ព្រោះវាតំណាងឱ្យរចនាសម្ព័ន្ធខាងក្នុងរបស់ឯកសារ .java និង .class ផងដែរ៖ ប្រភេទ វាល និងវិធីសាស្ត្រ។

ដើម្បីជៀសវាងការបង្កើតមែកធាងនៃធាតុទាំងមូលនៅក្នុងអង្គចងចាំ ការអនុវត្តគំរូ Java ប្រើទំហំកំណត់ LRU ឃ្លាំងសម្ងាត់នៃព័ត៌មានធាតុ ដែលគន្លឹះគឺដោះស្រាយ IJavaElement ។ វត្ថុព័ត៌មានធាតុត្រូវបានបង្កើតតាមតម្រូវការ នៅពេលដែលមែកធាងធាតុត្រូវបានរុករក។ ក្នុងករណីនេះ ធាតុដែលប្រើញឹកញាប់តិចបំផុតត្រូវបានបណ្តេញចេញពីឃ្លាំងសម្ងាត់ ហើយការប្រើប្រាស់អង្គចងចាំរបស់ម៉ូដែលនៅតែមានកម្រិតចំពោះទំហំឃ្លាំងសម្ងាត់ដែលបានបញ្ជាក់។ នេះគឺជាអត្ថប្រយោជន៍មួយទៀតនៃការរចនាផ្អែកលើចំណុចទាញ ដែលលាក់ទាំងស្រុងនូវព័ត៌មានលម្អិតនៃការអនុវត្តពីកូដអតិថិជន។

យន្តការ​សម្រាប់​ការ​ជូន​ដំណឹង​ការ​ផ្លាស់​ប្តូ​រ​ទៅ​លើ​ធាតុ Java គឺ​ជា​ទូទៅ​ស្រដៀង​គ្នា​នឹង​យន្តការ​សម្រាប់​ការ​តាមដាន​ការ​ផ្លាស់​ប្តូ​រ​ធនធាន​កន្លែង​ធ្វើការ​ដែល​បាន​ពិភាក្សា​ខាង​លើ​។ អតិថិជនដែលចង់តាមដានការផ្លាស់ប្តូរនៅក្នុងគំរូ Java ជាវការជូនដំណឹង ដែលត្រូវបានតំណាងជាវត្ថុ ElementChangedEvent ដែលមាន IJavaElementDelta (រូបភាព 6) ។

អង្ករ។ 6. ElementChangedEvent និង IJavaElementDelta

គំរូ Java មិនមានព័ត៌មានអំពីតួវិធីសាស្ត្រ ឬដំណោះស្រាយឈ្មោះទេ ដូច្នេះសម្រាប់ការវិភាគលម្អិតនៃកូដដែលសរសេរក្នុង Java JDT Core ផ្តល់នូវគំរូបន្ថែម (មិនផ្អែកលើចំណុចទាញ)៖ មែកធាងវាក្យសម្ព័ន្ធអរូបី (មែកធាងវាក្យសម្ព័ន្ធអរូបី, AST) ។ AST តំណាងឱ្យលទ្ធផលនៃការញែកអត្ថបទប្រភព។ ថ្នាំង AST ត្រូវគ្នាទៅនឹងធាតុនៃរចនាសម្ព័ន្ធនៃម៉ូឌុលប្រភព (សេចក្តីប្រកាស ប្រតិបត្តិករ កន្សោម។ ទម្រង់នៃតំណភ្ជាប់ទៅអ្វីដែលគេហៅថា ចង. ការចងគឺជាវត្ថុដែលតំណាងឱ្យអង្គភាពដែលមានឈ្មោះ ដូចជាប្រភេទ វិធីសាស្ត្រ និងអថេរ ដែលគេស្គាល់ចំពោះអ្នកចងក្រង។ មិនដូចថ្នាំង AST ដែលបង្កើតជាមែកធាង ការចងគាំទ្រការយោងឆ្លង ហើយជាទូទៅបង្កើតជាក្រាហ្វ។ ថ្នាក់អរូបី ASTNode គឺជាថ្នាក់មូលដ្ឋានទូទៅសម្រាប់ថ្នាំង AST ទាំងអស់។ ថ្នាក់រង ASTNode ត្រូវគ្នាទៅនឹងរចនាសម្ព័ន្ធសំយោគជាក់លាក់នៃភាសា Java ។

ដោយសារតែដើមឈើវាក្យសម្ព័ន្ធអាចប្រើប្រាស់អង្គចងចាំយ៉ាងច្រើន JDT ទុកតែ AST មួយប៉ុណ្ណោះសម្រាប់កម្មវិធីនិពន្ធសកម្ម។ មិនដូចគំរូ Java ទេ AST ជាធម្មតាត្រូវបានមើលថាជាគំរូ "មធ្យម" "បណ្តោះអាសន្ន" ដែលធាតុដែលអតិថិជនមិនគួរមានឯកសារយោងទៅខាងក្រៅបរិបទនៃប្រតិបត្តិការដែលនាំទៅដល់ការបង្កើត AST ។

គំរូទាំងបីដែលបានរាយបញ្ជី (Java model, AST, bindings) រួមគ្នាបង្កើតជាមូលដ្ឋានសម្រាប់បង្កើត "ឧបករណ៍អភិវឌ្ឍន៍ឆ្លាតវៃ" នៅក្នុង JDT រួមទាំងកម្មវិធីនិពន្ធ Java ដ៏មានអានុភាពជាមួយនឹង "អ្នកជំនួយ" ផ្សេងៗ សកម្មភាពផ្សេងៗសម្រាប់ដំណើរការកូដប្រភព (រួមទាំងការរៀបចំបញ្ជីនៃការនាំចូល។ ឈ្មោះ​និង​ការ​ធ្វើ​ទ្រង់ទ្រាយ​ដោយ​យោង​តាម​រចនាប័ទ្ម​ដែល​បាន​ប្ដូរ​តាម​បំណង) ឧបករណ៍​ស្វែង​រក​និង​ការ​កែ​សម្រួល។ ក្នុងករណីនេះ គំរូ Java ដើរតួនាទីពិសេស ព្រោះវាត្រូវបានប្រើជាមូលដ្ឋានសម្រាប់តំណាងដែលមើលឃើញនៃរចនាសម្ព័ន្ធនៃកម្មវិធីដែលកំពុងត្រូវបានបង្កើតឡើង (ឧទាហរណ៍ នៅក្នុង Package Explorer, Outline, Search, Call Hierarchy និង ប្រភេទ ឋានានុក្រម) ។

សមាសធាតុ Eclipse ដែលប្រើក្នុង 1C:Enterprise Development Tools

នៅក្នុងរូបភព។ រូបភាពទី 7 បង្ហាញពីសមាសធាតុ Eclipse ដែលបង្កើតជាមូលដ្ឋានគ្រឹះនៃវេទិកាបច្ចេកវិទ្យាសម្រាប់ 1C:Enterprise Development Tools ។

អង្ករ។ 7. Eclipse ជាវេទិកាសម្រាប់ 1C: ឧបករណ៍អភិវឌ្ឍន៍សហគ្រាស

វេទិកា Eclipse ផ្តល់ហេដ្ឋារចនាសម្ព័ន្ធមូលដ្ឋាន។ យើងបានពិនិត្យមើលទិដ្ឋភាពមួយចំនួននៃហេដ្ឋារចនាសម្ព័ន្ធនេះនៅក្នុងផ្នែកមុន។

គ្រោងការណ៍គំរូនៃសូរ្យគ្រាស (អេមអេហ្វអេហ្វ។) ផ្តល់នូវមធ្យោបាយទូទៅនៃការធ្វើគំរូទិន្នន័យរចនាសម្ព័ន្ធ។ EMF ត្រូវបានរួមបញ្ចូលជាមួយ Eclipse Platform ប៉ុន្តែក៏អាចប្រើដោយឡែកពីគ្នានៅក្នុងកម្មវិធី Java ធម្មតាផងដែរ។ ជាញឹកញាប់ អ្នកអភិវឌ្ឍន៍ Eclipse ថ្មីបានស្គាល់ EMF រួចហើយ ទោះបីជាពួកគេមិនទាន់យល់ច្បាស់ពីភាពស្មុគ្រស្មាញនៃវេទិកា Eclipse ក៏ដោយ។ ហេតុផលមួយក្នុងចំណោមហេតុផលសម្រាប់ប្រជាប្រិយភាពដែលសមនឹងទទួលបានគឺការរចនាជាសកល ដែលរួមមាន ក្នុងចំណោមរបស់ផ្សេងទៀត API កម្រិតមេតាបង្រួបបង្រួម ដែលអនុញ្ញាតឱ្យអ្នកធ្វើការជាមួយគំរូ EMF ណាមួយតាមរបៀបទូទៅ។ ការអនុវត្តជាមូលដ្ឋានសម្រាប់វត្ថុគំរូដែលផ្តល់ដោយ EMF និងប្រព័ន្ធរងសម្រាប់ការបង្កើតកូដគំរូដោយផ្អែកលើគំរូមេតាបានបង្កើនល្បឿននៃការអភិវឌ្ឍន៍យ៉ាងខ្លាំង និងកាត់បន្ថយចំនួនកំហុស។ EMF ក៏មានយន្តការសម្រាប់ស៊េរីស៊េរី តាមដានការផ្លាស់ប្តូរគំរូ និងច្រើនទៀត។

ដូចជាឧបករណ៍ដែលមានគោលបំណងទូទៅពិតប្រាកដ EMF គឺសមរម្យសម្រាប់ការដោះស្រាយបញ្ហាគំរូជាច្រើន ប៉ុន្តែប្រភេទមួយចំនួននៃម៉ូដែល (ឧទាហរណ៍ ម៉ូដែលដែលផ្អែកលើចំណុចទាញដែលបានពិភាក្សាខាងលើ) អាចត្រូវការឧបករណ៍គំរូពិសេសបន្ថែមទៀត។ ការនិយាយអំពី EMF គឺជាកិច្ចការដែលគ្មានការដឹងគុណ ជាពិសេសនៅក្នុងដែនកំណត់ដែលមានកំណត់នៃអត្ថបទមួយ ព្រោះនេះគឺជាប្រធានបទនៃសៀវភៅដាច់ដោយឡែក និងក្រាស់ជាង។ អនុញ្ញាតឱ្យយើងកត់សំគាល់ថាប្រព័ន្ធដែលមានគុណភាពខ្ពស់នៃការធ្វើទូទៅដែលផ្អែកលើ EMF បានអនុញ្ញាតឱ្យបង្កើតគម្រោងទាំងមូលដែលឧទ្ទិសដល់ការធ្វើគំរូ ដែលត្រូវបានរួមបញ្ចូលនៅក្នុងគម្រោងកម្រិតកំពូល។ ការបង្កើតគំរូពងក្រពើ រួមជាមួយ EMF ខ្លួនឯង។ គម្រោងមួយបែបនេះគឺ Eclipse Xtext ។

Eclipse Xtext ផ្តល់ហេដ្ឋារចនាសម្ព័ន្ធ "គំរូអត្ថបទ" ។ Xtext ប្រើ ANTLR សម្រាប់ការញែកអត្ថបទប្រភព និង EMF សម្រាប់តំណាងឱ្យ ASG លទ្ធផល (ក្រាហ្វអរូបីអរូបី ដែលជាការរួមបញ្ចូលគ្នានៃ AST និងការចង) ត្រូវបានគេហៅថា "គំរូន័យន័យ" ផងដែរ។ វេយ្យាករណ៍នៃភាសាដែលយកគំរូតាម Xtext ត្រូវបានពិពណ៌នាជាភាសារបស់ Xtext ។ នេះអនុញ្ញាតឱ្យអ្នកមិនត្រឹមតែបង្កើតការពិពណ៌នាវេយ្យាករណ៍សម្រាប់ ANTLR ប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងទទួលបានយន្តការសៀរៀល AST (ឧ. Xtext ផ្តល់ទាំង parser និង unparser) ជំនួយបរិបទ និងសមាសធាតុភាសាមួយចំនួនទៀត។ ម្យ៉ាងវិញទៀត ភាសាវេយ្យាករណ៍ដែលប្រើក្នុង Xtext គឺមានភាពបត់បែនតិចជាងនិយាយភាសាវេយ្យាករណ៍ដែលប្រើក្នុង ANTLR។ ដូច្នេះ ជួនកាលវាចាំបាច់ដើម្បី "ពត់" ភាសាដែលបានអនុវត្តទៅជា Xtext ដែលជាធម្មតាមិនមែនជាបញ្ហាទេ ប្រសិនបើយើងកំពុងនិយាយអំពីភាសាដែលកំពុងត្រូវបានបង្កើតឡើងពីដំបូង ប៉ុន្តែប្រហែលជាមិនអាចទទួលយកបានសម្រាប់ភាសាដែលមានវាក្យសម្ព័ន្ធដែលបានបង្កើតឡើងរួចហើយ។ ទោះបីជាយ៉ាងណាក៏ដោយ Xtext បច្ចុប្បន្នគឺជាឧបករណ៍ដែលមានលក្ខណៈចាស់ទុំ សំបូរបែប និងអាចប្រើប្រាស់បានច្រើនបំផុតនៅក្នុង Eclipse សម្រាប់បង្កើតភាសាសរសេរកម្មវិធី និងឧបករណ៍សម្រាប់អភិវឌ្ឍន៍សម្រាប់ពួកគេ។ ជាពិសេស វាគឺជាឧបករណ៍ដ៏ល្អសម្រាប់ការធ្វើគំរូយ៉ាងឆាប់រហ័ស ភាសាជាក់លាក់នៃដែន (ភាសាជាក់លាក់នៃដែន DSL) ។ បន្ថែមពីលើ "ស្នូលភាសា" ដែលបានរៀបរាប់ខាងលើដោយផ្អែកលើ ANTLR និង EMF Xtext ផ្តល់នូវសមាសធាតុកម្រិតខ្ពស់ដែលមានប្រយោជន៍ជាច្រើន រួមទាំងយន្តការធ្វើលិបិក្រម ការសាងសង់បន្ថែម "កម្មវិធីនិពន្ធឆ្លាតវៃ" និងច្រើនទៀត ប៉ុន្តែទុកចោល។ គំរូភាសាដែលមានមូលដ្ឋាន។ ដូច EMF ដែរ Xtext គឺជាប្រធានបទដែលសក្តិសមសម្រាប់សៀវភៅដាច់ដោយឡែកមួយ ហើយយើងស្ទើរតែមិនអាចនិយាយដោយសង្ខេបអំពីសមត្ថភាពរបស់វាទាំងអស់នៅពេលនេះ។

1C: ឧបករណ៍អភិវឌ្ឍន៍សហគ្រាសប្រើប្រាស់យ៉ាងសកម្មទាំង EMF ខ្លួនវាផ្ទាល់ និងគម្រោង Eclipse Modeling មួយចំនួនផ្សេងទៀត។ ជាពិសេស Xtext គឺជាមូលដ្ឋានគ្រឹះមួយនៃឧបករណ៍អភិវឌ្ឍន៍សម្រាប់ 1C:Enterprise languages ​​ជាភាសាសរសេរកម្មវិធី និងភាសាសំណួរដែលភ្ជាប់មកជាមួយ។ មូលដ្ឋានមួយទៀតសម្រាប់ឧបករណ៍អភិវឌ្ឍន៍ទាំងនេះគឺគម្រោង Eclipse Handly ដែលយើងនឹងពិភាក្សាលម្អិតបន្ថែមទៀត (នៃសមាសធាតុ Eclipse ដែលបានរាយបញ្ជី វានៅតែត្រូវបានគេស្គាល់តិចបំផុត)។

Eclipse Handlyដែលជាគម្រោងរងនៃគម្រោងកម្រិតកំពូលនៃបច្ចេកវិទ្យា Eclipse បានលេចចេញជាលទ្ធផលនៃការរួមចំណែកកូដដំបូងដល់មូលនិធិ Eclipse ដែលធ្វើឡើងដោយ 1C នៅក្នុងឆ្នាំ 2014។ ចាប់តាំងពីពេលនោះមក 1C បានបន្តគាំទ្រដល់ការអភិវឌ្ឍន៍គម្រោង៖ អ្នកគ្រប់គ្រងដោយដៃគឺជាបុគ្គលិករបស់ក្រុមហ៊ុន។ គម្រោងនេះមានទំហំតូច ប៉ុន្តែវាកាន់កាប់កន្លែងពិសេសមួយនៅក្នុង Eclipse៖ គោលដៅចម្បងរបស់វាគឺដើម្បីគាំទ្រដល់ការអភិវឌ្ឍន៍នៃម៉ូដែលដែលផ្អែកលើចំណុចទាញ។

គោលការណ៍ស្ថាបត្យកម្មជាមូលដ្ឋាននៃម៉ូដែលដែលមានមូលដ្ឋានលើចំណុចទាញ ដូចជាពាក្យសំដីចំណុចទាញ/តួ ត្រូវបានពិភាក្សាខាងលើដោយប្រើគំរូធនធាន និងគំរូ Java ជាឧទាហរណ៍។ វាក៏បានកត់សម្គាល់ផងដែរថាទាំងគំរូធនធាននិងគំរូ Java គឺជាមូលដ្ឋានគ្រឹះដ៏សំខាន់សម្រាប់ឧបករណ៍អភិវឌ្ឍន៍ Eclipse Java (JDT) ។ ហើយចាប់តាំងពីគម្រោង * DT Eclipse ស្ទើរតែទាំងអស់មានស្ថាបត្យកម្មស្រដៀងនឹង JDT វាមិនមែនជាការបំផ្លើសដ៏អស្ចារ្យទេក្នុងការនិយាយថាម៉ូដែលដែលមានមូលដ្ឋានលើចំណុចទាញមានមូលដ្ឋានលើជាច្រើន ប្រសិនបើមិនមែន IDE ទាំងអស់ដែលបានសាងសង់នៅលើកំពូលនៃវេទិកា Eclipse នោះទេ។ ឧទាហរណ៍ ឧបករណ៍អភិវឌ្ឍន៍ Eclipse C/C++ (CDT) មានគំរូ C/C++ ដែលមានមូលដ្ឋានលើចំណុចទាញ ដែលដើរតួនាទីដូចគ្នានៅក្នុងស្ថាបត្យកម្ម CDT ដូចម៉ូដែល Java ធ្វើនៅក្នុង JDT ។

មុនពេល Handly Eclipse មិនបានផ្តល់បណ្ណាល័យឯកទេសសម្រាប់បង្កើតគំរូភាសាដែលផ្អែកលើចំណុចទាញនោះទេ។ ម៉ូដែល​ដែល​មាន​បច្ចុប្បន្ន​ត្រូវ​បាន​បង្កើត​ឡើង​ជា​ចម្បង​ដោយ​ការ​សម្រប​ខ្លួន​ដោយ​ផ្ទាល់​នូវ​កូដ​គំរូ Java (aka copy/paste) ក្នុងករណីដែលវាអនុញ្ញាត Eclipse Public License (EPL) ។ (ជាក់ស្តែង នេះជាធម្មតាមិនមែនជាបញ្ហាផ្លូវច្បាប់សម្រាប់គម្រោង Eclipse ដោយខ្លួនវាផ្ទាល់ ប៉ុន្តែមិនមែនសម្រាប់ផលិតផលប្រភពបិទជិតនោះទេ។) បន្ថែមពីលើភាពខុសឆ្គងរបស់វា បច្ចេកទេសនេះណែនាំអំពីបញ្ហាល្បីឈ្មោះ៖ ការចម្លងកូដដែលណែនាំដោយនៅពេលសម្របខ្លួនទៅនឹងកំហុស។ ល។ អ្វី​ដែល​អាក្រក់​ជាង​នេះ​គឺ​ថា​គំរូ​លទ្ធផល​នៅ​តែ​ជា "របស់​ខ្លួន​ឯង" ហើយ​មិន​ទាញ​យក​ប្រយោជន៍​ពី​សក្តានុពល​សម្រាប់​ការ​បង្រួបបង្រួម​ឡើយ។ ប៉ុន្តែការញែកចេញនូវគោលគំនិត និងពិធីការទូទៅសម្រាប់គំរូភាសាដែលផ្អែកលើចំណុចទាញអាចនាំឱ្យមានការបង្កើតសមាសធាតុដែលអាចប្រើឡើងវិញបានសម្រាប់ធ្វើការជាមួយពួកគេ ស្រដៀងទៅនឹងអ្វីដែលបានកើតឡើងនៅក្នុងករណី EMF ដែរ។

វាមិនមែនថា Eclipse មិនយល់ពីបញ្ហាទាំងនេះទេ។ ត្រលប់ទៅឆ្នាំ 2005 Martin Aeschlimannសង្ខេបបទពិសោធន៍នៃការអភិវឌ្ឍន៍គំរូ CDT, ប្រកែក តម្រូវការក្នុងការបង្កើតហេដ្ឋារចនាសម្ព័ន្ធទូទៅសម្រាប់គំរូភាសា រួមទាំងគំរូដែលផ្អែកលើចំណុចទាញ។ ប៉ុន្តែដូចដែលកើតឡើងជាញឹកញាប់ ដោយសារកិច្ចការដែលមានអាទិភាពខ្ពស់ ការអនុវត្តគំនិតទាំងនេះមិនដែលឈានដល់វាទេ។ ទន្ទឹមនឹងនេះដែរ កត្តាកត្តានៃ * DT code នៅតែជាប្រធានបទមួយក្នុងចំនោមប្រធានបទដែលមិនមានការវិវឌ្ឍន៍នៅក្នុង Eclipse ។

ក្នុងន័យជាក់លាក់មួយ គម្រោង Handly ត្រូវបានរចនាឡើងដើម្បីដោះស្រាយបញ្ហាប្រហាក់ប្រហែលនឹង EMF ប៉ុន្តែសម្រាប់ម៉ូដែលដែលមានមូលដ្ឋានលើចំណុចទាញ និងជាភាសាចម្បង (ឧទាហរណ៍ តំណាងឱ្យធាតុនៃរចនាសម្ព័ន្ធនៃភាសាសរសេរកម្មវិធីមួយចំនួន)។ គោលដៅចម្បងដែលបានកំណត់នៅពេលរចនា Handly ត្រូវបានរាយខាងក្រោម៖

• ការកំណត់អត្តសញ្ញាណអរូបីសំខាន់ៗនៃប្រធានបទ។
• កាត់បន្ថយការខិតខំប្រឹងប្រែង និងការកែលម្អគុណភាពនៃការអនុវត្តគំរូភាសាដែលផ្អែកលើចំណុចទាញតាមរយៈការប្រើប្រាស់កូដឡើងវិញ។
• ការផ្តល់ API កម្រិតមេតាបង្រួបបង្រួមទៅនឹងគំរូលទ្ធផល ធ្វើឱ្យវាអាចបង្កើតសមាសធាតុ IDE ទូទៅដែលដំណើរការជាមួយគំរូដែលផ្អែកលើភាសា។
• ភាពបត់បែន និងវិសាលភាព។
• ការរួមបញ្ចូលជាមួយ Xtext (ក្នុងស្រទាប់ដាច់ដោយឡែក) ។

ដើម្បីរំលេចគំនិត និងពិធីការទូទៅ ការអនុវត្តដែលមានស្រាប់នៃគំរូដែលផ្អែកលើភាសាត្រូវបានវិភាគ។ ចំណុចប្រទាក់ចម្បង និងការអនុវត្តជាមូលដ្ឋានដែលផ្តល់ដោយ Handly ត្រូវបានបង្ហាញនៅក្នុងរូបភព។ ៨.

អង្ករ។ 8. ចំណុចប្រទាក់ទូទៅ និងការអនុវត្តជាមូលដ្ឋាននៃធាតុ Handly

ចំណុចប្រទាក់ IElement តំណាងឱ្យចំណុចទាញនៃធាតុមួយ និងជារឿងធម្មតាសម្រាប់ធាតុទាំងអស់នៃម៉ូដែលដែលមានមូលដ្ឋានលើដៃ។ ធាតុថ្នាក់អរូបីអនុវត្តយន្តការចំណុចទាញ/តួទូទៅ (រូបភាព 9) ។

អង្ករ។ 9. IElement និងការអនុវត្តចំណុចទាញទូទៅ/រាងកាយ

លើសពីនេះទៀត Handly ផ្តល់នូវយន្តការទូទៅសម្រាប់ការជូនដំណឹងអំពីការផ្លាស់ប្តូរនៅក្នុងធាតុគំរូ (រូបភាព 10) ។ ដូចដែលអ្នកអាចឃើញ វាមានលក្ខណៈស្រដៀងទៅនឹងយន្តការជូនដំណឹងដែលបានអនុវត្តនៅក្នុងគំរូធនធាន និងគំរូ Java ហើយប្រើ IElementDelta ដើម្បីផ្តល់នូវតំណាងបង្រួបបង្រួមនៃព័ត៌មានការផ្លាស់ប្តូរធាតុ។

អង្ករ។ 10. ចំណុចប្រទាក់ទូទៅ និងការអនុវត្តជាមូលដ្ឋាននៃយន្តការជូនដំណឹងដោយដៃ

ផ្នែក Handly ដែលបានពិភាក្សាខាងលើ (រូបភាព 9 និង 10) អាចត្រូវបានប្រើដើម្បីតំណាងស្ទើរតែគ្រប់ម៉ូដែលដែលផ្អែកលើចំណុចទាញ។ សម្រាប់ការបង្កើត ភាសា ម៉ូដែល គម្រោងផ្តល់នូវមុខងារបន្ថែម - ជាពិសេស ចំណុចប្រទាក់ទូទៅ និងការអនុវត្តជាមូលដ្ឋានសម្រាប់ធាតុនៃរចនាសម្ព័ន្ធអត្ថបទប្រភព ដែលហៅថា ធាតុប្រភព (រូបភាពទី 8) ។ ចំណុចប្រទាក់ ISourceFile តំណាងឱ្យឯកសារប្រភព ហើយ ISourceConstruct តំណាងឱ្យធាតុនៅក្នុងឯកសារប្រភព។ ថ្នាក់អរូបី SourceFile និង SourceConstruct អនុវត្តយន្តការទូទៅដើម្បីគាំទ្រការធ្វើការជាមួយឯកសារប្រភព និងធាតុរបស់ពួកគេ ឧទាហរណ៍ ធ្វើការជាមួយសតិបណ្ដោះអាសន្នអត្ថបទ ការចងទៅនឹងកូអរដោនេនៃធាតុនៅក្នុងអត្ថបទប្រភព ការផ្សះផ្សាគំរូជាមួយនឹងមាតិកាបច្ចុប្បន្ននៃសតិបណ្ដោះអាសន្នចម្លងដែលកំពុងដំណើរការ ល។ ការអនុវត្តយន្តការទាំងនេះជាធម្មតាមានបញ្ហាប្រឈម ហើយ Handly អាចកាត់បន្ថយយ៉ាងខ្លាំងនូវកិច្ចខិតខំប្រឹងប្រែងក្នុងការអភិវឌ្ឍគំរូភាសាដែលផ្អែកលើចំណុចទាញដោយផ្តល់នូវការអនុវត្តមូលដ្ឋានដែលមានគុណភាពខ្ពស់។

បន្ថែមពីលើយន្តការស្នូលដែលបានរាយបញ្ជីខាងលើ Handly ផ្តល់នូវហេដ្ឋារចនាសម្ព័ន្ធសម្រាប់បណ្តុំអត្ថបទ និងរូបថត ការគាំទ្រសម្រាប់ការរួមបញ្ចូលជាមួយអ្នកកែសម្រួលកូដប្រភព (រួមទាំងការរួមបញ្ចូលក្រៅប្រអប់ជាមួយកម្មវិធីនិពន្ធ Xtext) ក៏ដូចជាសមាសធាតុ UI ទូទៅមួយចំនួនដែល ធ្វើការជាមួយកម្មវិធីនិពន្ធកូដប្រភពដោយដៃដូចជា គ្រោងការណ៍គ្រោង។ ដើម្បីបង្ហាញពីសមត្ថភាពរបស់វា គម្រោងនេះផ្តល់នូវឧទាហរណ៍ជាច្រើន រួមទាំងការអនុវត្តគំរូ Java នៅក្នុង Handly ។ (បើប្រៀបធៀបទៅនឹងការអនុវត្តពេញលេញនៃគំរូ Java នៅក្នុង JDT គំរូនេះត្រូវបានធ្វើឱ្យសាមញ្ញបន្តិចដោយចេតនាសម្រាប់ភាពច្បាស់លាស់កាន់តែច្រើន។ )

ដូចដែលបានកត់សម្គាល់ពីមុន ការផ្តោតសំខាន់មួយក្នុងអំឡុងពេលការរចនាដំបូងរបស់ Handly និងការអភិវឌ្ឍន៍ជាបន្តបន្ទាប់គឺ និងបន្តទៅលើការធ្វើមាត្រដ្ឋាន និងភាពបត់បែន។

ជាគោលការណ៍ ម៉ូដែលដែលមានមូលដ្ឋានលើចំណុចទាញធ្វើមាត្រដ្ឋានបានយ៉ាងល្អ "តាមការរចនា"។ ឧទាហរណ៍ ចំណុចទាញ/តួខ្លួន idiom អនុញ្ញាតឱ្យអ្នកកំណត់ចំនួនអង្គចងចាំដែលប្រើប្រាស់ដោយគំរូមួយ។ ប៉ុន្តែក៏មាន nuances ផងដែរ។ ដូច្នេះនៅពេលសាកល្បង Handly សម្រាប់ការធ្វើមាត្រដ្ឋាន បញ្ហាមួយត្រូវបានរកឃើញនៅក្នុងការអនុវត្តយន្តការជូនដំណឹង - នៅពេលដែលធាតុមួយចំនួនធំត្រូវបានផ្លាស់ប្តូរ ការសាងសង់ deltas ចំណាយពេលច្រើនពេក។ វាបានប្រែក្លាយថាបញ្ហាដូចគ្នានេះមានវត្តមាននៅក្នុងគំរូ JDT Java ដែលលេខកូដដែលត្រូវគ្នាត្រូវបានកែសម្រួលម្តង។ យើងបានជួសជុលកំហុសនៅក្នុង Handly និងរៀបចំបំណះស្រដៀងគ្នាសម្រាប់ JDT ដែលត្រូវបានទទួលដោយអំណរគុណ។ នេះគ្រាន់តែជាឧទាហរណ៍មួយដែលការណែនាំ Handly ទៅក្នុងការអនុវត្តគំរូដែលមានស្រាប់អាចមានប្រយោជន៍ ពីព្រោះក្នុងករណីនេះ កំហុសបែបនេះអាចត្រូវបានជួសជុលនៅកន្លែងតែមួយ។

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

ភាពបត់បែនក៏មានទិដ្ឋភាពផ្សេងទៀតផងដែរ។ ឧទាហរណ៍ Handly ស្ទើរតែគ្មានការរឹតបន្តឹងលើរចនាសម្ព័ន្ធនៃគំរូ ហើយអាចត្រូវបានប្រើដើម្បីធ្វើគំរូទាំងភាសាគោលបំណងទូទៅ និងភាសាជាក់លាក់នៃដែន។ នៅពេលបង្កើតរចនាសម្ព័ន្ធនៃឯកសារប្រភព Handly មិនចេញវេជ្ជបញ្ជាទម្រង់ជាក់លាក់ណាមួយនៃការតំណាង AST ហើយជាគោលការណ៍មិនតម្រូវឱ្យមានវត្តមានរបស់ AST ខ្លួនឯងទេ ដូច្នេះហើយធានាបាននូវភាពឆបគ្នាជាមួយស្ទើរតែគ្រប់យន្តការវិភាគ។ ជាចុងក្រោយ Handly គាំទ្រការរួមបញ្ចូលពេញលេញជាមួយ Eclipse workspace ប៉ុន្តែក៏អាចធ្វើការដោយផ្ទាល់ជាមួយប្រព័ន្ធឯកសារផងដែរ ដោយសារការរួមបញ្ចូលរបស់វាជាមួយ ប្រព័ន្ធឯកសារ Eclipse (EFS) ។

កំណែបច្ចុប្បន្ន ដោយដៃ 0.6 បានចេញនៅខែធ្នូ ឆ្នាំ 2016។ ទោះបីជាការពិតដែលថាគម្រោងនេះកំពុងស្ថិតក្នុងស្ថានភាពនៃការបង្កកំណើត ហើយ API មិនទាន់ត្រូវបានជួសជុលនៅឡើយទេ ប៉ុន្តែ Handly ត្រូវបានគេប្រើរួចហើយនៅក្នុងផលិតផលពាណិជ្ជកម្មធំៗចំនួនពីរដែលបានប្រថុយនឹងការដើរតួជា "អ្នកចិញ្ចឹមដំបូង" ហើយខ្ញុំត្រូវតែនិយាយ។ កុំសោកស្តាយវានៅឡើយទេ។

ដូចដែលបានកត់សម្គាល់ខាងលើ ផលិតផលមួយក្នុងចំណោមផលិតផលទាំងនេះគឺ 1C:Enterprise Development Tools ដែល Handly ត្រូវបានប្រើតាំងពីដើមដំបូងរហូតដល់ធាតុគំរូនៃរចនាសម្ព័ន្ធកម្រិតខ្ពស់នៃ 1C:Enterprise languages ​​ជាភាសាសរសេរកម្មវិធី និងភាសាសំណួរដែលមានស្រាប់។ . ផលិតផល​មួយ​ទៀត​មិន​សូវ​មាន​អ្នក​ស្គាល់​ច្រើន​ទេ។ នេះ។ ស្ទូឌីយោ Codasipដែលជាបរិយាកាសរចនារួមបញ្ចូលគ្នាសម្រាប់កម្មវិធីដំណើរការសំណុំការណែនាំជាក់លាក់ (ASIP) ដែលប្រើទាំងនៅក្នុងក្រុមហ៊ុនឆេក Codasip ខ្លួនវា និងដោយអតិថិជនរបស់ខ្លួន រួមទាំង AMD បាន, AVG, mobileye, រចនាស៊ីហ្គាម៉ា. Codasip បានប្រើប្រាស់ Handly នៅក្នុងការផលិតតាំងពីឆ្នាំ 2015 ដោយចាប់ផ្តើមជាមួយនឹងកំណែ Handly 0.2។ ការចេញផ្សាយចុងក្រោយបំផុតរបស់ Codasip Studio ប្រើប្រាស់កំណែ 0.5 ដែលបានចេញផ្សាយក្នុងខែមិថុនា ឆ្នាំ 2016។ Ondřej Ilčík ដែលដឹកនាំការអភិវឌ្ឍន៍ IDE នៅ Codasip កំពុងទាក់ទងជាមួយគម្រោងនេះ ដោយផ្តល់មតិកែលម្អសំខាន់ៗក្នុងនាម "អ្នកអនុម័តភាគីទីបី" ។ គាត់ថែមទាំងអាចស្វែងរកពេលទំនេរខ្លះ ដើម្បីចូលរួមដោយផ្ទាល់ក្នុងការអភិវឌ្ឍន៍គម្រោង ដោយអនុវត្តស្រទាប់ UI (~4000 បន្ទាត់នៃកូដ) សម្រាប់ឧទាហរណ៍ Handly ដែលជាគំរូ Java ។ ព័ត៌មានដៃដំបូងលម្អិតបន្ថែមទៀតអំពីការប្រើប្រាស់ Handly ដោយអ្នកអនុម័តអាចរកបាននៅលើទំព័រ រឿង​ជោគជ័យ គម្រោង។

យើងសង្ឃឹមថាបន្ទាប់ពីការចេញផ្សាយកំណែ 1.0 ជាមួយនឹងការធានានៃស្ថេរភាព API និងគម្រោងចាកចេញពីស្ថានភាព incubation, Handly នឹងមានអ្នកអនុម័តថ្មី។ ក្នុងពេលជាមួយគ្នានេះ គម្រោងបន្តសាកល្បង និងកែលម្អ API បន្ថែមទៀត ដោយបានចេញផ្សាយការចេញផ្សាយ "សំខាន់" ចំនួនពីរក្នុងមួយឆ្នាំ - ក្នុងខែមិថុនា (កាលបរិច្ឆេទដូចគ្នានឹងការចេញផ្សាយ Eclipse ដំណាលគ្នា) និងខែធ្នូ ដោយផ្តល់នូវកាលវិភាគដែលអាចព្យាករណ៍បានដែលអ្នកអនុម័តអាចពឹងផ្អែកលើ។ យើងក៏អាចបន្ថែមថា "អត្រាកំហុស" របស់គម្រោងនៅតែស្ថិតក្នុងកម្រិតទាបជាប់លាប់ ហើយ Handly បានធ្វើការប្រកបដោយភាពជឿជាក់នៅក្នុងផលិតផលរបស់អ្នកទទួលយកដំបូងតាំងពីកំណែដំបូង។ ដើម្បីស្វែងយល់បន្ថែម Eclipse Handly អ្នកអាចប្រើ ការចាប់ផ្តើមបង្រៀន и ទិដ្ឋភាពទូទៅនៃស្ថាបត្យកម្ម.

ប្រភព: www.habr.com