Java tərtibatçısı üçün müsahibələrdən alınan sualların və cavabların təhlili. 14-cü hissə

Atəşfəşanlıq! Dünya durmadan hərəkət edir və biz də daim hərəkət edirik. Əvvəllər Java proqramçısı olmaq üçün bir az Java sintaksisini bilmək kifayət idi, qalanı gələcəkdi. Zaman keçdikcə Java tərtibatçısı olmaq üçün tələb olunan bilik səviyyəsi, tələb olunan biliklərin aşağı zolağının yuxarı qalxmasına davam edən rəqabət kimi əhəmiyyətli dərəcədə artmışdır. Əgər həqiqətən tərtibatçı olmaq istəyirsinizsə, bunu təbii qəbul etməli və sizin kimi yeni başlayanlar arasında fərqlənmək üçün hərtərəfli hazırlaşmalısınız. Bu gün nə edəcəyik, yəni 250+ sualı təhlil etməyə davam edəcəyik . Əvvəlki məqalələrdə biz bütün kiçik səviyyəli sualları araşdırdıq və bu gün orta səviyyəli sualları götürəcəyik. Qeyd edim ki, bunlar 100% orta səviyyəli suallar deyil, siz onların əksəriyyəti ilə kiçik səviyyəli müsahibədə tanış ola bilərsiniz, çünki məhz belə müsahibələrdə nəzəri bazanızın təfərrüatlı tədqiqi aparılır, orta səviyyəli tələbə üçün isə suallar daha çox onun təcrübəsinin araşdırılmasına yönəlib. Ancaq uzatmadan, başlayaq.

Orta

Ümumidir

1. Prosessual/funksional proqramlaşdırma ilə müqayisədə OOP-nin üstünlükləri və çatışmazlıqları hansılardır?

Juiniorun suallarının təhlilində bu sual var idi və ona uyğun olaraq mən artıq cavab verdim. Bu sualı və onun cavabını məqalənin bu hissəsində, 16 və 17-ci suallarda axtarın .

2. Aqreqasiya kompozisiyadan nə ilə fərqlənir?

OOP-da obyektlər arasında qarşılıqlı əlaqənin bir neçə növü var, ümumi "Münasibətə malikdir" anlayışı altında birləşir. Bu əlaqə bir obyektin digər obyektin tərkib hissəsi olduğunu göstərir. Eyni zamanda, bu əlaqənin iki alt növü var: Kompozisiya - bir obyekt başqa bir obyekt yaradır və digər obyektin ömrü yaradıcının ömründən asılıdır. Aqreqasiya - obyekt tikinti prosesi zamanı başqa obyektə keçid (göstərici) alır (bu halda digər obyektin ömrü yaradıcının ömründən asılı deyil). Daha yaxşı başa düşmək üçün konkret bir nümunəyə baxaq. Müəyyən bir avtomobil sinfimiz var - Avtomobil , öz növbəsində daxili sahələrə malikdir - Mühərrik və sərnişinlərin siyahısı - List<Passenger> , həmçinin hərəkətə başlamaq üçün bir üsul var - startMoving() :

public class Car {

 private Engine engine;
 private List<Passenger> passengers;

 public Car(final List<Passenger> passengers) {
   this.engine = new Engine();
   this.passengers = passengers;
 }

 public void addPassenger(Passenger passenger) {
   passengers.add(passenger);
 }

 public void removePassengerByIndex(Long index) {
   passengers.remove(index);
 }

 public void startMoving() {
   engine.start();
   System.out.println("Машина начала своё движение");
   for (Passenger passenger : passengers) {
     System.out.println("В машине есть пассажир - " + passenger.getName());
   }
 }
}

Bu halda, Kompozisiya Avtomobil və Mühərrik arasındakı əlaqədir , çünki avtomobilin performansı birbaşa mühərrik obyektinin mövcudluğundan asılıdır, çünki mühərrik = null olarsa, NullPointerException alacağıq . Öz növbəsində, mühərrik maşınsız mövcud ola bilməz (bizə maşınsız mühərrik nə üçün lazımdır?) və bir anda bir neçə maşına aid ola bilməz. Bu o deməkdir ki, Avtomobil obyektini silsək , Mühərrik obyektinə daha istinad olmayacaq və o, tezliklə Zibil Kollektoru tərəfindən silinəcək . Gördüyünüz kimi, bu münasibət çox sərtdir (güclü). Aqreqasiya Avtomobil və Sərnişin arasındakı əlaqədir , çünki Avtomobilin performansı heç bir şəkildə Sərnişin tipli obyektlərdən və onların sayından asılı deyil. Onlar ya avtomobili tərk edə bilərlər - removePassengerByIndex(Long index) və ya yenilərini daxil edə bilərlər - addPassenger(Passenger sərnişin) , buna baxmayaraq, avtomobil düzgün işləməyə davam edəcək. Öz növbəsində, Sərnişin obyektləri Avtomobil obyekti olmadan mövcud ola bilər . Anladığınız kimi, bu, tərkibdə gördüyümüzdən daha zəif bir əlaqədir. Amma bununla da bitmir, aqreqasiya yolu ilə digərinə bağlanan obyekt eyni zamanda digər obyektlərlə də verilmiş əlaqəyə malik ola bilər. Məsələn, siz Java tələbəsi olaraq eyni vaxtda ingilis dili, OOP və loqarifm kurslarına yazılmısınız, lakin eyni zamanda siz onların kritik vacib hissəsi deyilsiniz, onsuz normal işləmək mümkün deyil (məsələn, müəllim).

3. Təcrübədə hansı GoF nümunələrindən istifadə etmisiniz? Nümunələr verin.

Mən bu suala əvvəllər cavab vermişəm, ona görə də təhlilə keçid buraxacağam , birinci suala baxın. Mən də dizayn nümunələri haqqında gözəl bir fırıldaqçı vərəq məqaləsi tapdım , onu əlimdə saxlamağı çox tövsiyə edirəm.

4. Proxy obyekti nədir? Nümunələr verin

Proksi, real obyektlərin əvəzinə xüsusi əvəzedici obyektləri və ya başqa sözlə, proxy obyektləri əvəz etməyə imkan verən struktur dizayn nümunəsidir. Bu proksi obyektlər orijinal obyektə edilən zəngləri kəsərək, zəng orijinala ötürülməzdən əvvəl və ya sonra bəzi məntiqlərin daxil edilməsinə imkan verir. Proksi obyektindən istifadə nümunələri:

• Uzaqdan bir proxy olaraq - yerli olaraq təmsil edilməli olan uzaq bir obyektə (fərqli ünvan məkanındakı obyekt) ehtiyacımız olduqda istifadə olunur. Bu halda, proksi əlaqə yaratma, kodlaşdırma, dekodlaşdırma və s. ilə məşğul olacaq, müştəri isə ondan yerli məkanda yerləşən orijinal obyekt kimi istifadə edəcək.

• Virtual proxy kimi - resurs tutumlu obyekt lazım olduqda istifadə olunur. Bu halda, proxy obyekti əslində hələ mövcud olmayan real obyektin təsviri kimi bir şey kimi xidmət edir. Bu obyektə real sorğu (metod çağırışı) göndərildikdə, yalnız bundan sonra orijinal obyekt yüklənir və metod yerinə yetirilir. Bu yanaşma həm də tənbəl başlatma adlanır; bu, çox rahat ola bilər, çünki bəzi hallarda orijinal obyekt faydalı olmaya bilər və sonra onu yaratmaq üçün heç bir xərc tələb olunmayacaq.

• Təhlükəsizlik proksisi kimi - müştəri hüquqlarına əsasən bəzi obyektlərə girişi idarə etmək lazım olduqda istifadə olunur. Yəni, giriş hüququ olmayan müştəri orijinal obyektə daxil olmağa cəhd edərsə, proksi onu ələ keçirəcək və icazə verməyəcək.

Gəlin virtual proksi nümunəsinə baxaq: Bizim bəzi işləyici interfeysimiz var:

public interface Processor {
 void process();
}

Onun həyata keçirilməsi çoxlu resursdan istifadə edir, lakin eyni zamanda tətbiq hər dəfə işə salındıqda istifadə olunmaya bilər:

public class HiperDifficultProcessor implements Processor {
 @Override
 public void process() {
   // некоторый сверхсложная обработка данных
 }
}

Proksi sinfi:

public class HiperDifficultProcessorProxy implements Processor {
private HiperDifficultProcessor processor;

 @Override
 public void process() {
   if (processor == null) {
     processor = new HiperDifficultProcessor();
   }
   processor.process();
 }
}

Gəlin onu əsas işə salaq :

Processor processor = new HiperDifficultProcessorProxy();
// тут тяжеловсеного оригинального an object, ещё не сущетсвует
// но при этом есть an object, который его представляет и у которого можно вызывать его методы
processor.process(); // лишь теперь, an object оригинал был создан

Qeyd edim ki, bir çox çərçivələr proksidən istifadə edir və Bahar üçün bu əsas nümunədir (Bahar həm içəridən, həm də xaricdən tikilir). Bu nümunə haqqında daha çox oxuyun .

5. Java 8-də hansı yeniliklər elan edilib?

Java 8-in gətirdiyi yeniliklər aşağıdakılardır:

• Funksional interfeyslər əlavə edildi, bunun hansı heyvan olduğunu burada oxuyun .

• Funksional interfeyslərlə yaxından əlaqəli olan Lambda ifadələri, onların istifadəsi haqqında daha çox oxuyun .

• Məlumat kolleksiyalarının rahat emalı üçün Stream API əlavə edildi , daha ətraflı burada oxuyun .

• Metodlara bağlantılar əlavə edildi .

• ForEach() metodu İterable interfeysinə əlavə edilmişdir .

• Java.time paketinə yeni tarix və vaxt API əlavə edildi, burada ətraflı təhlil .

• Təkmilləşdirilmiş Concurrent API .

• Null dəyərləri düzgün idarə etmək üçün istifadə olunan Könüllü sarğı sinifini əlavə etməklə , burada bu mövzuda əla məqalə tapa bilərsiniz .

• İnterfeyslər üçün statik və defolt metodlardan istifadə etmək qabiliyyətinin əlavə edilməsi (bu, mahiyyət etibarı ilə Java-nı çoxlu varisliyə yaxınlaşdırır), burada daha ətraflı məlumat .

• Collection(removeIf(), spliterator()) sinfinə yeni metodlar əlavə edildi .

• Java Core-da kiçik təkmilləşdirmələr.

6. Yüksək koheziya və aşağı birləşmə nədir? Nümunələr verin.

Yüksək Uyğunluq və ya Yüksək Uyğunluq müəyyən bir sinifdə bir-biri ilə sıx əlaqəli olan və məqsədləri üçün birləşdirilən elementləri ehtiva edən anlayışdır. Məsələn, İstifadəçi sinifindəki bütün metodlar istifadəçi davranışını təmsil etməlidir. Bir sinif əlaqəsiz elementləri ehtiva edərsə, aşağı birləşməyə malikdir. Məsələn, e-poçt ünvanı doğrulama metodunu ehtiva edən İstifadəçi sinfi:

public class User {
private String name;
private String email;

 public String getName() {
   return this.name;
 }

 public void setName(final String name) {
   this.name = name;
 }

 public String getEmail() {
   return this.email;
 }

 public void setEmail(final String email) {
   this.email = email;
 }

 public boolean isValidEmail() {
   // некоторая логика валидации емейла
 }
}

İstifadəçi sinfi istifadəçinin e-poçt ünvanının saxlanmasına cavabdeh ola bilər, lakin onu təsdiqləmək və ya e-poçt göndərmək üçün deyil. Buna görə də, yüksək uyğunluğa nail olmaq üçün doğrulama metodunu ayrıca faydalılıq sinfinə köçürük:

public class EmailUtil {
 public static boolean isValidEmail(String email) {
   // некоторая логика валидации емейла
 }
}

Və biz onu lazım olduqda istifadə edirik (məsələn, istifadəçini saxlamadan əvvəl). Low Coupling və ya Low Coupling proqram modulları arasında aşağı qarşılıqlı asılılığı təsvir edən konsepsiyadır. Əslində, qarşılıqlı asılılıq birinin dəyişdirilməsinin digərinin dəyişdirilməsini tələb etməsidir. İki sinif bir-biri ilə sıx bağlıdırsa, güclü birləşməyə (və ya sıx birləşməyə) malikdir. Məsələn, bir-birinə istinadları saxlayan və bir-birinin metodlarını çağıran iki konkret sinif. Sərbəst birləşdirilən sinifləri inkişaf etdirmək və saxlamaq daha asandır. Onlar bir-birindən müstəqil olduqları üçün paralel olaraq inkişaf etdirilə və sınaqdan keçirilə bilər. Üstəlik, onlar bir-birinə təsir etmədən dəyişdirilə və yenilənə bilər. Güclü birləşmiş siniflərin nümunəsinə baxaq. Bir neçə tələbə sinfimiz var:

public class Student {
 private Long id;
 private String name;
 private List<Lesson> lesson;
}

Hansı dərslərin siyahısını ehtiva edir:

public class Lesson {
 private Long id;
 private String name;
 private List<Student> students;
}

Hər dərsdə iştirak edən tələbələrə keçid var. İnanılmaz dərəcədə güclü tutuş, sizcə, elə deyilmi? Onu necə azaltmaq olar? Əvvəlcə tələbələrin fənlərin siyahısı deyil, onların identifikatorlarının siyahısı olduğundan əmin olaq:

public class Student {
 private Long id;
 private String name;
 private List<Long> lessonIds;
}

İkincisi, dərs sinfinin bütün tələbələri bilməsi lazım deyil, ona görə də onların siyahısını tamamilə silək:

public class Lesson {
 private Long id;
 private String name;
}

Beləliklə, daha asan oldu və əlaqə çox zəiflədi, elə deyilmi?

OOP

7. Java-da çoxlu varisliyi necə həyata keçirə bilərsiniz?

Çoxlu irsiyyət obyekt yönümlü konsepsiyanın xüsusiyyətidir, burada bir sinif birdən çox ana sinifdən xassələri miras ala bilər. Problem həm super sinifdə, həm də alt sinifdə eyni imzaya malik metodlar olduqda yaranır. Metod çağırarkən kompilyator hansı sinif metodunun çağırılmalı olduğunu müəyyən edə bilmir və hətta üstünlük təşkil edən sinif metodunu çağırarkən belə. Buna görə də, Java çoxlu miras almağı dəstəkləmir! Ancaq bir növ boşluq var, bundan sonra danışacağıq. Daha əvvəl qeyd etdiyim kimi, Java 8-in buraxılması ilə interfeyslərə standart metodlara sahib olmaq imkanı əlavə edildi . Əgər interfeysi həyata keçirən sinif bu metodu ləğv etmirsə, bu defolt tətbiqdən istifadə olunacaq (mücərrəd metodun tətbiqi kimi standart metodu ləğv etmək lazım deyil). Bu halda, bir sinifdə müxtəlif interfeysləri həyata keçirmək və onların standart metodlarından istifadə etmək mümkündür. Bir nümunəyə baxaq. Defolt fly() metodu ilə bəzi flayer interfeysimiz var :

public interface Flyer {
 default void fly() {
   System.out.println("Я лечу!!!");
 }
}

Walker interfeysi, standart walk() metodu ilə :

public interface Walker {
 default void walk() {
   System.out.println("Я хожу!!!");
 }
}

Üzgüçü interfeysi, swim() metodu ilə :

public interface Swimmer {
 default void swim() {
   System.out.println("Я плыву!!!");
 }
}

Yaxşı, indi bütün bunları bir ördək sinfində həyata keçirək:

public class Duck implements Flyer, Swimmer, Walker {
}

Və ördəyimizin bütün üsullarını işə salaq:

Duck donald = new Duck();
donald.walk();
donald.fly();
donald.swim();

Konsolda biz alacağıq: Bu o deməkdir ki, biz çoxlu varisliyi düzgün təsvir etmişik, baxmayaraq ki, bu belə deyil. Onu da qeyd edim ki, əgər sinif bu metodlarda eyni metod adlarına və eyni arqumentlərə malik standart metodlarla interfeyslər tətbiq edərsə, kompilyator uyğunsuzluqdan şikayət etməyə başlayacaq, çünki həqiqətən hansı metoddan istifadə etmək lazım olduğunu başa düşmür. Bir neçə çıxış yolu var:

• İnterfeyslərdə metodların adını dəyişin ki, onlar bir-birindən fərqlənsin.
• Tətbiq sinfində bu cür mübahisəli üsulları ləğv edin.
• Bu mübahisəli metodları həyata keçirən sinifdən miras alın (sonra sinifiniz onun həyata keçirilməsindən tam olaraq istifadə edəcək).

8. Final, finally və finalize() metodları arasında fərq nədir?

final bir sinifə, metoda və ya dəyişənə məhdudiyyət qoymaq üçün istifadə olunan açar sözdür, məhdudiyyət mənası:

• Dəyişən üçün - ilkin işə salındıqdan sonra dəyişəni yenidən təyin etmək mümkün deyil.
• Metod üçün metod alt sinifdə (xələf sinfində) ləğv edilə bilməz.
• Bir sinif üçün - sinif miras alına bilməz.

nəhayət, kod blokundan əvvəl açar sözdür, istisnaları idarə edərkən, try bloku ilə birlikdə və tutma bloku ilə birlikdə (və ya bir-birini əvəz edə bilər) istifadə olunur. Bu blokdakı kod istisnanın atılıb-atılmamasından asılı olmayaraq istənilən halda icra olunur. Məqalənin bu hissəsində , 104-cü sualda, bu blokun icra olunmayacağı istisna hallardan bəhs edilir. finalize() hər bir obyekt zibil kollektoru tərəfindən silinməzdən əvvəl çağırılan Obyekt sinifinin metodudur , bu metod (sonuncu) adlandırılacaq və işğal edilmiş resursları təmizləmək üçün istifadə olunur. Hər bir obyektin miras aldığı Object sinfinin metodları haqqında ətraflı məlumat üçün məqalənin bu hissəsindəki 11-ci suala baxın. Yaxşı, bu günü bitirəcəyik. Növbəti hissədə görüşənədək!