Paggalugad ng mga tanong at sagot mula sa isang job interview para sa isang Java developer position. Bahagi 3

Hi! Kung paanong imposibleng matutunan kung paano magpalipad ng eroplano nang walang espesyal na pagsasanay, hindi ka maaaring maging isang developer ng Java nang hindi gumugugol ng mahabang oras sa pag-aaral ng mga kinakailangang teoretikal na pundasyon. At iyon mismo ang gagawin namin ngayon: patuloy naming tutuklasin ang mga tanong na nakatagpo sa mga panayam sa trabaho para sa mga developer ng Java, at, siyempre, titingnan namin ang mga sagot. Narito ang una at ikalawang bahagi ng pangkalahatang-ideya na ito. Walang alinlangan na maaari kang maging isang mahusay na developer ng Java nang wala ang lahat ng mga tanong na ito. Iyon ay sinabi, kung mayroon kang isang mahusay na pag-unawa sa lahat ng mga intricacies ng Java, tiyak na magkakaroon ka ng isang kalamangan at magiging mas kaakit-akit sa mga mata ng iyong magiging employer.

20. Anong mga elemento ng wika ang nagbibigay-daan sa encapsulation?

Alalahanin natin na ang encapsulation ay tungkol sa pagtatago ng mga detalye ng pagpapatupad ng isang klase. Sa madaling salita, kapag ang klase natin ang ginamit, hindi halata sa mga tagalabas ang loob at panloob na lohika nito. At anong mga elemento ng wika ang may pananagutan dito? I-access ang mga modifier , siyempre! Anumang bagay na kailangan naming itago, minarkahan namin ng pribadong modifier. Halimbawa, ang mga pribadong field ng isang klase o ilang mga panloob na pamamaraan na tumutulong sa pagpapatupad ng ilang panloob na pag-andar. At para sa anumang bagay na gusto naming bigyan ng external na access, idinaragdag namin ang pampublikong access modifier. Halimbawa, isang paraan na nagpapatupad ng ilang functionality (na maaaring internal na gumamit ng maraming pribadong pamamaraan) o, siyempre, mga getter at setter para sa pag-access sa mga pribadong field ng isang klase. Hindi pa namin nabanggit ang mga default at protektadong modifier, na maaaring magamit nang mas flexible at partikular na i-customize ang access sa ilang partikular na bahagi ng klase.

21. Anong mga elemento ng wika ang nagbibigay-daan sa pamana?

Ang inheritance ay isang mekanismo na nagbibigay-daan sa iyong lumikha ng mga klase batay sa isa pang klase. Ang Java ay may extends na keyword para dito. Halimbawa, ipagpalagay na mayroon kaming klase ng Cat , at gusto naming lumikha ng klase ng batang Lion . Sa code, magiging ganito ang hitsura:

public class Lion extends Cat

At nangangahulugan ito na ang klase ng Lion ay nagmamana ng lahat ng mga pamamaraan at mga variable ng klase ng Cat , maliban sa mga static na variable. Ang isa pang elemento ng wika na responsable para sa pamana ay super . Ito ay isang sanggunian na katulad nito . Ang keyword na ito ay tumutukoy sa bagay kung saan ito ay isinangguni. Ang sobrang keyword ay tumutukoy sa magulang ng kasalukuyang bagay. Karaniwang ginagamit ang super :

1. Upang tawagan ang constructor ng isang superclass. Halimbawa, ang klase ng Cat ay may panloob na variable ng pangalan na dapat masimulan sa constructor. Sa constructor ng klase ng Lion , ganito ang magiging hitsura:

   
   public Lion(final String name) {
      super(name);
   }

2. Upang sumangguni sa mga patlang at pamamaraan ng magulang. Halimbawa, sa klase ng Cat , mayroon kaming nasimulan na field ng edad :

   
   public class Cat {
      int age = 10;

Ngunit mayroon kaming parehong nasimulang field sa Lion :

public class Lion extends Cat {
   int age = 15;

At kung sa isang object ng Lion gusto nating sumangguni sa variable ng edad ng parent object, kailangan nating gawin ito sa pamamagitan ng super :

super.name

22. Anong mga elemento ng wika ang may pananagutan sa polymorphism?

Ang polymorphism ay ang kakayahan ng isang bagay na may isang lagda na magkaroon ng maraming anyo (maraming pagpapatupad). Maaari naming kumpiyansa na sabihin na ang Java's implements at extends keywords ay responsable para sa polymorphism. Kapag mayroon kaming interface, pinapayagan kami ng mga implement na magbigay ng isang posibleng pagpapatupad, ngunit hindi iyon ang tanging pagpapatupad, hindi ba? Balikan natin kung ano ang hitsura ng paggamit ng mga implement :

public class Cat implements Animal

Pagkatapos sa klase ng Cat , kailangan nating ipatupad ang lahat ng abstract na pamamaraan sa interface ng Animal . Inheritance din: sa child class, maaari naming i-override ang kasalukuyang pagpapatupad ng isang paraan. Nangangahulugan ito na sa maraming klase ng bata, maaari tayong magkaroon ng iba't ibang mga override ng parehong paraan. O ang isang superclass ay maaaring abstract at may isang tiyak na pamamaraan na dapat ipatupad sa isang espesyal na paraan sa bawat isa sa mga child class nito. Sa madaling salita, ang paraang ito ay magkakaroon ng maraming magkakaibang pagpapatupad. Ang @Override annotation ay makakatulong din sa amin dito. Ito ay inilalagay sa itaas ng mga ipinatupad na pamamaraan at nagpapahiwatig na gusto nating ipatupad o i-override (kung mayroon nang pagpapatupad sa superclass) ng isang partikular na paraan ng isang superclass o interface. Ito ay opsyonal at tumutulong na mas madaling makakita ng mga error. Ginagamit mo ang annotation na ito para sabihin sa compiler na gusto mong i-override/ipatupad ang superclass/interface na paraan. Pagkatapos ay titiyakin ng compiler na hindi ka magkakamali sa lagda ng pamamaraan.

23. Ano ang SOLID? Magbigay ng mga halimbawa

Ang SOLID ay isang acronym para sa limang pangunahing prinsipyo ng disenyo ng OOP ni Robert Martin. S (Single-responsibility principle) : nagsasaad na ang isang klase ay dapat magkaroon lamang ng isang layunin/responsibilidad. Sa madaling salita, hindi ka dapat gumawa ng mga klase na ginagawa ang lahat. Kung gagawin mo, maaari mong kopyahin ang anti-pattern na "God Object". Kung mayroon kang object ng Cat , dapat ay mayroon itong mga pamamaraan para lamang sa pakikipag-ugnayan sa panloob na pagpapagana nito, ngunit hindi ito dapat maglaman ng anumang logic ng negosyo na hindi nauugnay sa pagkakataong iyon. Halimbawa, ilang mekanismo para sa pag-iimbak ng mga bagay ng ganitong uri. Ang functionality na ito (external sa entity ng isang Cat ) ay dapat ilipat sa ibang mga klase o serbisyo, na ang gawain ay magbigay ng business logic para sa mga kaukulang bagay. O (Open-closed na prinsipyo) : Ang prinsipyong ito ay inilarawan bilang mga sumusunod: software entity (mga klase, module, function, atbp.) ay dapat na bukas para sa extension ngunit sarado para sa pagbabago. Halimbawa, ipagpalagay na kailangan namin ng functionality na katulad ng ngunit bahagyang naiiba sa functionality ng aming kasalukuyang Cat class. Sa halip na baguhin ang functionality ng klase ng Cat at sa gayon ay masira ang code saanman ito ginagamit, maaari naming gamitin ang inheritance o komposisyon . Kaya, nakamit namin ang aming layunin na baguhin ang functionality ng klase ng Cat , at ginagawa namin ito nang hindi binabago ang klase mismo at walang sinisira ang anuman. L (Liskov Substitution Principle) : ito ang prinsipyo ng pagpapalit ni Barbara Liskov. Sinasabi ng prinsipyo na ang isang function na kumukuha ng base type ay dapat na gumamit ng mga subtype ng base type na iyon nang hindi nalalaman kung ano ang nangyayari. Halimbawa, ang aming klase ng Cat ay dapat na mapalitan ng alinman sa mga inapo nito, halimbawa, Lion , nang hindi binago ang pag-uugali nito. Ang pangkalahatang lohika (pag-uugali) ay nananatiling pareho, ngunit ang mga detalye ng pagpapatupad ng partikular na pag-andar ay nagbabago. I (Interface segregation principle) : ang prinsipyong ito ay nagsasaad na mas mainam na magkaroon ng maraming dalubhasang (makitid na nakatutok) na mga interface kaysa sa isang unibersal. Halimbawa, ipagpalagay na ang isang developer ay nagpapatupad ng ilang interface. Kailangan lang nila ng isa sa mga pamamaraan nito, ngunit ang interface ay may siyam pang pamamaraan na hindi nauugnay sa lohika ng kinakailangang pamamaraan. Sa kasong ito, kakailanganin ng developer na magpatupad ng sampung paraan ng interface, siyam sa mga ito ay kalabisan para sa kanila! Sa halip, mas mabuting gumawa ng sampung magkakaibang interface na maaari mong ipatupad kung kinakailangan. Well, kung hindi sampu, pagkatapos ay ilan, bawat isa ay may mga pamamaraan na malapit na nauugnay sa iisang layunin ng interface. D (Dependency inversion principle): Sinasabi ng prinsipyo na ang mga mas mataas na antas ng mga module ay hindi dapat umasa sa mga mas mababang antas ng mga module. Ang prinsipyong ito ay nagsasaad din, "Ang abstraction ay hindi dapat nakadepende sa mga detalye. Ang mga detalye ay dapat nakadepende sa mga abstraction." Dapat nating buuin ang ating lohika sa pamamagitan ng pagtukoy sa mga interface at pagpasa sa mga konkretong bagay ng mga klase na nagpapatupad ng kinakailangang interface. Halimbawa, ipagpalagay na mayroon kaming interface ng Cat at ilang mga pagpapatupad, halimbawa, Lion at HouseCat . Binubuo namin ang aming logic na partikular para makipag-ugnayan sa interface ng Cat . Pagkatapos ay pinapalitan lang namin ang interface ng isang partikular na pagpapatupad ( Lion o HouseCat ), ngunit hindi ang kabaligtaran.

24. Ano ang klase, bagay, at interface?

Matatandaan namin na ang Java ay isang wikang OOP. Iyon ay, ang mga programa ng Java ay binuo batay sa mga pakikipag-ugnayan sa pagitan ng mga bagay. Ang isang programa ay parang anthill, kung saan ang bawat langgam ay isang bagay. Ang mga bagay ay mga koleksyon ng data na kinabibilangan ng iba't ibang pamamaraan (function) para sa pakikipag-ugnayan sa panloob na data na ito. Ang mga klase ay mga tagubilin o template para sa paglikha ng mga bagay. Nangangahulugan ito na maaari tayong magkaroon ng maraming bagay na binuo ayon sa parehong mga tagubilin ngunit puno ng iba't ibang (o pareho) na data. Sa pagkuha ng isang halimbawa mula sa totoong buhay, masasabi nating ang isang klase ay isang blueprint ng isang gusali, at ang isang bagay ay isang gusaling partikular na itinayo ayon sa blueprint. Ang mga interface ay katulad ng mga klase, ngunit hindi namin magagamit ang mga ito upang lumikha ng mga bagay. Ang kanilang layunin ay magdagdag ng abstraction sa Java. Mas tiyak, nagdaragdag sila ng kakayahang umangkop sa relasyon sa pagitan ng mga klase at mga bagay. Sa pamamagitan ng flexibility, ang ibig naming sabihin ay ang polymorphism at abstraction na inilarawan dati, na lumilikha ng maraming pagkakataon para sa pagbuo ng panloob na arkitektura ng isang application.

25. Ano ang klase ng POJO? Magbigay ng halimbawa ng ganitong klase

Ang POJO (Plain Old Java Object) ay isang simpleng object ng klase na hindi nagmana mula sa anumang partikular na klase at hindi nagpapatupad ng anumang mga interface ng serbisyo na lampas sa kailangan para sa modelo ng negosyo. Sa madaling salita, ang klase ng POJO ay isang klase lamang na walang espesyal na pangangailangan. Ang tanging kinakailangan ay ang kawalan ng iba't ibang mga kampana at sipol na nakatali sa isang partikular na balangkas. Bilang isang patakaran, ang mga klase na ito ay hindi nagmamana ng iba pang mga klase (maliban sa mga klase ng POJO sa parehong pakete), hindi nagpapatupad ng mga interface (kung minsan ang isang pagbubukod ay ginawa para sa mga interface ng marker mula sa karaniwang library tulad ng Serializable o Cloneable ), huwag gumamit ng mga anotasyon , at hindi umaasa sa mga third party na aklatan. Tandaan natin na ang isang POJO ay maaaring magkaroon ng mga pamamaraan na naglalaman ng lohika ng negosyo at mga constructor ng anumang uri. Kung papayagan namin ang mga anotasyon na hindi nagbabago sa mga semantika ng klase (ibig sabihin, ang mga anotasyon na ang kawalan ay hindi nagbabago sa layunin o lohika ng bagay), kung gayon ang mga POJO ay maaari ding magsama ng mga entity ng JPA at mga bagay na DTO na na-deserialize mula sa XML o JSON , na ang mga panuntunan ay tinukoy sa mga anotasyon. Ang isa pang bagay na dapat tandaan tungkol sa mga klase ng POJO ay ang magandang i-override ang kanilang mga katumbas at hashCode na pamamaraan dahil makakatulong ito sa kanila na magampanan nang mas mahusay ang kanilang tungkulin. Halimbawa ng klase ng POJO :

public class User {
   private Long id;
   private String firstName;
   private String lastName;
   private Long age;
 
   public User(final Long id, final String firstName, final String lastName, final long age) {
       this.id = id;
       this.firstName = firstName;
       this.lastName = lastName;
       this.age = age;
   }
 
   public Long getId() {
       return this.id;
   }
 
   public String getFirstName() {
       return this.firstName;
   }
 
   public String getLastName() {
       return this.lastName;
   }
 
   public Long getAge() {
       return this.age;
   }
 
   @Override
   public boolean equals(final Object o) {
       if (this == o) return true;
       if (o == null || this.getClass() != o.getClass()) return false;
       final User user = (User) o;
       return Objects.equals(this.id, user.id) &&
               Objects.equals(this.firstName, user.firstName) &&
               Objects.equals(this.lastName, user.lastName) &&
               Objects.equals(this.age, user.age);
   }
 
   @Override
   public int hashCode() {
       return Objects.hash(this.id, this.firstName, this.lastName, this.age);
   }
}

26. Anong mga elemento ang maaaring taglayin ng isang klase?

Ang isang klase ay maaaring maglaman ng mga sumusunod na elemento:

• mga patlang ng halimbawa;
• static na mga patlang;
• isang bloke ng pagsisimula;
• isang static na initialization block;
• mga konstruktor (isang walang laman na konstruktor ay palaging idineklara bilang default);
• paraan;
• static na pamamaraan;
• iba't ibang anotasyon (na maaaring ilapat sa klase mismo o sa mga bahaging bumubuo nito);
• generics ;
• inheritance ng ibang klase ( extends ) o mga pagpapatupad ng interface ( implements ).

27. Sabihin sa amin ang tungkol sa pamana sa Java. Ano ang mga detalye ng super keyword?

Sa itaas, napag-usapan ko dati ang tungkol sa pamana at ang sobrang keyword sa Java. Babanggitin ko ang ilan pang mahahalagang punto:

1. Isang klase lang ang maaari nating ma-inherit: Walang multiple inheritance ang Java sa Java. Sa pagdating ng mga default na pamamaraan sa Java 8, ang pahayag na ito ay magiging napakakontrobersyal.
2. Ang mga pribadong pamamaraan at larangan ay minana rin. Hindi lang sila ma-access mula sa child class (ngunit kung tayo, halimbawa, ay may pribadong field at may pampubliko o protektadong mga getter at setter, magagamit natin ang mga ito para ma-access ang field).
3. ang mga huling klase ay hindi maipapamana.
4. hindi maaaring ma-override ang mga panghuling pamamaraan (ngunit maaari silang mamana at ma-overload).
5. Ang mga static na pamamaraan at mga variable ay hindi minana (dahil ang mga ito ay naka-attach sa mga klase, hindi mga bagay).
6. Kapag nagmana ng mga abstract na klase, ang kanilang mga abstract na pamamaraan ay dapat ipatupad, o ang child class ay dapat ding ideklarang abstract.
7. Kung may mga hindi default na constructor sa magulang, dapat na ma-override ang mga ito sa child class (ngunit ang @Override ay hindi nakasulat sa itaas ng mga ito).
8. Maaari mong i-extend ang access modifier sa mga overridden na pamamaraan sa child class: private -> default -> protected -> public .
Ang mga pamamaraan na na-override sa klase ng bata ay maaaring magtapon ng mas makitid na mga eksepsiyon, halimbawa: Exception -> IOException -> FileNotFoundException.

28. Ano ang mga lagda ng pamamaraan? Magbigay ng mga halimbawa ng tama at maling lagda

Ang lagda ng pamamaraan ay ang pangalan ng pamamaraan kasama ang mga uri ng mga parameter ng input (ang pagkakasunud-sunod ng mga parameter ay mahalaga). Ang lagda ng pamamaraan ay hindi kasama ang halaga ng pagbabalik o ang mga pagbubukod na inihagis ng pamamaraan. Halimbawa ng tamang lagda:

doSomething(int, double, double)

Halimbawa ng maling pirma:

void doSomething(int firstArg, int secondArg) throws Exception

Ang lagda ng pamamaraan, na sinamahan ng uri ng pagbabalik at ang listahan ng mga pagbubukod na itinapon, ay tinatawag na kontrata ng pamamaraan . Yan lamang para sa araw na ito! See you later!