Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Объектіге бағытталған бағдарламалаудағы композициялық қатынас. Деректер қорының жобалауында, объектіге бағытталған бағдарламалау және жобалауда, "бар" (немесе "иеленеді") – бір объект (көбінесе құрастырылған объект деп аталады, сондай-ақ бөлік, құраушы немесе мүше объект) екінші объектіге ("құрастырылған тип" деп аталады) "қатысты" (оның бөлігі немесе мүшесі) болады және меншік құқығының ережелеріне сәйкес әрекет етеді. Қарапайым тілмен айтқанда, объектідегі "бар" қатынасы – объектінің мүшелік өрісі деп аталады. Көптеген "бар" қатынастары иелену иерархиясын құру үшін бірігеді.
Composition relationship in object oriented programming
In database design, object oriented programming and design, has a (has a or has a) is a composition relationship where one object (often called the constituted object, or part/constituent/member object) "belongs to" (is part or member of) another object (called the composite type), and behaves according to the rules of ownership. In simple words, has a relationship in an object is called a member field of an object. Multiple has a relationships will combine to form a possessive hierarchy.
Субъектінің қатынас моделі
Деректер қорындағы қатынастар әдетте Entity-relationship модельінде көрсетіледі. Оң жақтағы диаграммадан көріп отырғаныңыздай, бір есептік жазбада бірнеше кейіпкер болуы мүмкін. Бұл есептік жазбаның кейіпкермен "иелену" қатынасында екенін көрсетеді.
In databases has a relationships are usually represented in an Entity–relationship model. As you can see by the diagram on the right an account can have multiple characters. This shows that account has a "has a" relationship with character.
UML сынып диаграммасы
Объектіге бағытталған бағдарламалауда бұл қатынас Бірыңғай модельдеу тілінің кластық диаграммасымен бейнеленеді. Бұл қатынас композиция деп те аталады. Оң жақтағы кластық диаграммадан көрініп тұрғанындай, автомобильдің "карбюраторы бар" немесе автомобиль "карбюратордан құралған". Алмаз қара түсті болса, ол композицияны көрсетеді, яғни алмазға жақын жатқан нысан екінші нысаннан тұрады немесе оны қамтиды. Ал ақ алмаз агрегацияны көрсетеді, яғни алмазға жақын нысан екінші нысанға ие болуы мүмкін.
In object oriented programming this relationship can be represented with a Unified Modeling Language Class diagram. This has a relationship is also known as composition. As you can see from the Class Diagram on the right a car "has a" carburetor, or a car is "composed of" a carburetor. When the diamond is coloured black it signifies composition, i. e. the object on the side closest to the diamond is made up of or contains the other object. While the white diamond signifies aggregation, which means that the object closest to the diamond can have or possess the other object.
C++ тілінде
Нақты әлемді модельдеуде композиция мен агрегацияны ажыратудың тағы бір жолы – кіріктірілген нысанның салыстырмалы өмір сүру мерзімін қарастыру. Мысалы, егер Автокөлік нысаны Шасси нысанын қамтитын болса, Шасси Автокөліктің өмір бойында ауыстырылмайды. Оның өмір сүру мерзімі Автокөліктің өмір сүру мерзімімен сәйкес келеді, сондықтан бұл қарым-қатынас композиция болып табылады. Ал егер Автокөлік нысаны Тыныс нысандары жиынтығын қамтитын болса, онда бұл Тыныс нысандары тозығып, бірнеше рет алмастырылуы мүмкін. Егер Автокөлік қолдануға жарамсыз болса, кейбір Тыныстар сақталап, басқа Автокөлікке берілуі мүмкін. Қалай болғанда да, Тыныс нысандарының өмір сүру мерзімі Автокөлік нысанынан өзгеше, демек қарым-қатынас агрегация болып табылады. Егер жоғарыда сипатталған қарым-қатынастарды іске асыру үшін C++ бағдарламалық класын жасасақ, Автокөлік нысаны дерек мүшесі ретінде толық Шасси нысанын қамтиды. Бұл Шасси нысаны Автокөлік класының конструкторында (немесе конструкторда дерек мүшесінің дерек типі ретінде анықталып, оның қасиеттері конструкторда беріледі) құрылады. Автокөлік класының толық қамтылған дерек мүшесі болғандықтан, Автокөлік класы нысаны жойылғанда Шасси нысаны да жойылады. Ал Автокөлік класының дерек мүшелері, Тыныс нысандарына сілтеме жасайтын болса, олар C++ көрсеткіштері болады. Тыныс нысандары сырттан құрылып, жойылуы мүмкін, тіпті басқа Автокөлік нысанының дерек мүшелеріне тағайындалуы мүмкін. Тыныс нысандары Автокөлік нысаны жойылғаннан кейін де дербес өмір сүру мерзіміне ие болады.
Another way to distinguish between composition and aggregation in modeling the real world, is to consider the relative lifetime of the contained object. For example, if a Car object contains a Chassis object, a Chassis will most likely not be replaced during the lifetime of the Car. It will have the same lifetime as the car itself; so the relationship is one of composition. On the other hand, if the Car object contains a set of Tire objects, these Tire objects may wear out and get replaced several times. Or if the Car becomes unusable, some Tires may be salvaged and assigned to another Car. At any rate, the Tire objects have different lifetimes than the Car object; therefore the relationship is one of aggregation. If one were to make a C++ software Class to implement the relationships described above, the Car object would contain a complete Chassis object in a data member. This Chassis object would be instantiated in the constructor of the Car class (or defined as the data type of the data member and its properties assigned in the constructor.) And since it would be a wholly contained data member of the Car class, the Chassis object would no longer exist if a Car class object was to be deleted. On the other hand, the Car class data members that point to Tire objects would most likely be C++ pointers. Tire objects could be instantiated and deleted externally, or even assigned to data members of a different Car object. Tire objects would have an independent lifetime separate from when the Car object was deleted.