@Embedded ანოტაცია

ვაგრძელებთ წინა პოსტში განხილულ თემატიკას და ამ პოსტში გაგაცნობთ Hibernate-ს @Embeddable და @Embedded ანოტაციებს, რომლებიც საქმეს ერთად აკეთებენ. სანამ უშუალოდ მაგალითზე გადავიდოდე, მოვიყვან შემთხვევას როდის შეიძლება გამოვიყენოთ ეს ანოტაციები. მაგალითად, გვაქვს Person კლასი შესაბამისი ცხრილით მონაცემთა ბაზაში. დავუშვათ, რომ ამ ცხრილში ინახება ადამიანის მისამართი რამდენიმე ველის სახით. მაგალითად: საფოსტო კოდი, ქალაქი, ქვეყანა, ქუჩა. ცხადია, რომ ოთხი სხვადასხვა ველით წარმოდგენა არც ისე დიდი პრობლემაა, მაგრამ რას იტყოდით, ამ ველების ერთ Address ობიექტში "გახვევაზე" ? ანუ მონაცემთა ბაზაში ასე ცალ-ცალკე ველად იქნება, მაგრამ ჯავას კოდში ამ ოთხ ველზე ვიმოქმედებთ როგორც Address კლასზე. შემდეგი სურათები გვიჩვენებს სწორედ ამ მაგალითს.  ჩვენ აღვწერთ Address კლასს შესაბამისი ველებით და ამ კლასს თავზე დავაწერთ @Embeddable ანოტაციას. შემდეგ Address კლასის ტიპის ველი გვექნება Person კლასში და ამ ველს დავაწერთ @Embedded ანოტაციას.

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

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

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

S – Single-responsibility principle

O – Open-closed principle

L – Liskov substitution principle

I – Interface segregation principle

D – Dependency Inversion principle

ახლა სათითაოდ განვიხილოთ თითოეული მათგანი.

Single-responsibility Principle (S.R.P) - კლასს უნდა ჰქონდეს ერთი და მხოლოდ ერთი მიზეზი იმისთვის, რომ შეიცვალოს, ანუ ეს გულისხმობს, რომ კლასი უნდა ასრულებდეს მხოლოდ და მხოლოდ ერთ დავალებას.

Open-closed principle გულისხმობს, რომ ობიექტები (ან Entity-ები) უნდა იყოს ღია გაფართოებისთვის მიზნებისთვის, მაგრამ დახურული ცვლილებების მიმართ. ანუ სხვა სიტყვებით რომ ვთქვათ, კლასი  ადვილად უნდა ფართოვდებოდეს ამ კლასშივე ცვილებების გარეშე.

Liskov substitution principle - ყველა ქვეკლასი/შვილი კლასი უნდა იყოს შემცვლელი მისი base/მშობელი კლასის.

Interface Segregation principle (ISP) - გულისხმობს იმას, რომ არცერთ კლასს არ უნდა ჰქონდეს ვალდებულება დააიპლმენეტიროს მეთოდი, რომელიც არ სჭირდება მას, ანუ არცერთი კლასი არ უნდა იყოს დამოკიდებული მისთვის არასასურველ მეთოდზე. მაგალითად, გვაქვს ShapeCalculator კლასი, რომელიც სხვადასხვა სახის ფიგურების ფართობების ჯამს ითვლის და გვაქვს ShapeInter ინტერფეისი, რომელსაც აქვს area() მეთოდი. Square კლასი, რომელიც აიმპლემენტირებს ShapeInter ინტერფეისს თავისთვის განსაზღვრავს area() მეთოდს და მისი გამოთვლის წესს. ახლა ვთქვათ გვინდა მოცულობების ჯამის გამოთვლაც. ჩვენ თუ ShapeInter ინტერფეისში დავამატეთ volume() მეთოდი, მაშინ გამოვა, რომ Square-ს არ აქვს მოცულობა, რადგან ორგანზომილებიანი ფიგურაა და ტყუილად მოგვიწევს ამ კლასში არასასრუველი მეთოდის იმპლემენტირება. ამისთვის, ჩვენ უნდა შევქმნათ სხვა ინტერფეისი, მაგალითად ThreeDimShapeInter და იქ გვქონდეს volume() მეთოდი.

Dependency Inversion principle  გვეუბნება, რომ Entity-ები უნდა იყვნენ დამოკიდებულები აბსტრაქციებზე და არა კონკრეტიკებზე. High Level მოდული არ უნდა იყოს დამოკიდებული Low Level მოდულზე, მაგრამ ორივე შეიძლება დამოკიდებული იყოს აბსტრაქციებზე. მაგალითად, გვაქვს PasswordReminder კლასი და მას აქვს property სახელად connection, რომელიც მონაცემთა ბაზასთან კავშირისთვის გამოიყენება. რადგან Connection არის low level და  PasswordReminder არის high level, ასეთი სტრუქტურა დაარღვევს Dependency Inversion პრინციპს. თუ მოგვიწევს სხვა მონაცემთა ბაზასთან კავშირი, მოგვიწევს PasswordReminder კლასსის ცვლილებაც, როცა მას სულ არ უნდა აინტერესებდეს რომელ მონაცემთა ბაზას ვიყენებთ. ანუ უნდა გავაკეთოთ ინტერფეისი DBConnection და მისი იმპლემენტატორი კლასი, რომელშიც ეწერება ის ლოგიკა, რომელიც დაგვეხმარება მონაცემთა ბაზასთან კავშირში, ხოლო PasswordReminder კლასში connection property იქნება ინტერფეისის ტიპის.