Pagsusuri ng mga tanong at sagot mula sa mga panayam para sa developer ng Java. Bahagi 3

Kamusta! Kung paanong imposibleng matutong lumipad ng eroplano nang walang espesyal na pagsasanay, imposible rin na maging isang developer ng Java nang hindi gumugugol ng mahabang oras sa pag-aaral ng kinakailangang teoretikal na batayan. Ngayon ay gagawin namin ito nang eksakto: patuloy naming susuriin ang 250+ mga tanong sa panayam para sa mga developer ng Java at, nang naaayon, mga sagot sa kanila. Narito ang una at ikalawang bahagi ng pagsusuri. Oo, siyempre, maaari kang maging isang mahusay na developer ng Java nang wala ang lahat ng mga tanong na ito. Gayunpaman, kung mayroon kang isang mahusay na pag-unawa sa mga ins at out ng wikang Java, ito ay magbibigay sa iyo ng isang kalamangan, na gagawin kang isang mas kanais-nais na kandidato sa mga mata ng iyong magiging employer.

20. Anong mga elemento ng wika ang responsable para sa encapsulation?

Tulad ng natatandaan namin, itinatago ng encapsulation ang mga detalye ng pagpapatupad ng isang klase. Iyon ay, kapag ang aming klase ay ginagamit sa panlabas, ang panloob na nilalaman at lohika ay hindi halata. At anong mga elemento ng wika ang may pananagutan dito? Naturally, i-access ang mga modifier ! Minarkahan namin ang kailangan naming itago gamit ang 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 sa gusto naming bigyan ng external na access, idinaragdag namin ang pampublikong access modifier . Halimbawa, isang paraan na responsable para sa pagbibigay ng ilang functionality (kung saan maraming pribadong pamamaraan ang maaaring gamitin) o ang parehong mga getter at setter para sa pag-access ng mga pribadong field ng isang klase. Oh, at mayroon din kaming default at protektadong mga modifier , na magagamit sa mas nababaluktot at partikular na configuration ng access sa mga piling bahagi ng klase.

21. Aling mga elemento ng wika ang may pananagutan sa pamana?

Ang inheritance ay isang mekanismo na nagbibigay-daan sa iyong lumikha ng mga klase batay sa isa pang klase. Sa Java, ginagamit ang extends na keyword para sa layuning ito . Halimbawa, mayroon kaming isang partikular na klase na Cat , at gusto naming likhain ang kahalili nito - Lion . Sa code ito ay magmumukhang ganito:

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. Gayundin, ang mga elemento ng wika na responsable para sa mana ay kinabibilangan ng super . Ito ay isang reference na katulad nito , ngunit habang ito ay tumutukoy sa object kung saan ito tinawag, super ay tumutukoy sa kasalukuyang parent object. Karaniwang ginagamit ang super :

1. Para tumawag ng superclass constructor: Halimbawa, ang Cat class ay may panloob na variable na pangalan na kailangang masimulan sa constructor. Sa constructor ng klase ng Lion magiging ganito ang hitsura:

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

2. Upang ma-access ang mga field at pamamaraan ng magulang: halimbawa, sa klase ng Cat mayroon kaming nasimulang field ng edad :

   public class Cat {
      int age = 10;

Kasabay nito, mayroon kaming parehong nasimulang field sa Lion :

public class Lion extends Cat {
   int age = 15;

At kung gusto nating ma-access ang variable ng edad ng parent object mula sa Lion object , kailangan nating gawin ito sa pamamagitan ng super :

super.name

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

Ang polymorphism ay ang kakayahan ng isang bagay ng isang lagda na magkaroon ng maraming anyo (maraming pagpapatupad). Ligtas nating masasabi na sa Java ang mga nagpapatupad at nagpapalawak ng mga keyword ay responsable para sa polymorphism . nagpapatupad - kapag lumikha kami ng aming interface, ipinapatupad namin ang isa sa mga posibleng form nito sa ilang klase, ngunit hindi lang ito ang form, hindi ba? Tandaan natin kung ano ang hitsura ng mga nagpapatupad :

public class Cat implements Animal

At sa klase ng Cat dapat nating ipatupad ang lahat ng abstract na pamamaraan na ipinakita sa interface ng Animal . Ang parehong napupunta para sa mana: sa isang descendant class maaari naming i-override ang isang umiiral nang pagpapatupad ng isang pamamaraan. Halimbawa: ilang inapo -> ilang magkakaibang override ng parehong paraan. Well, alinman sa superclass ay abstract at mayroon itong isang tiyak na pamamaraan na kailangang ipatupad sa isang espesyal na paraan para sa bawat isa sa mga inapo nito. Iyon ay, maaari nating sabihin na ang pamamaraan ay magkakaroon ng maraming anyo. Gayundin, ang @Override annotation ay makakatulong sa amin dito , na inilalagay sa itaas ng mga ipinatupad na pamamaraan at nagpapahiwatig na gusto naming ipatupad o i-override (kung ang pagpapatupad ay umiiral na sa superclass) ng isa o ibang paraan ng superclass o interface. Ito ay opsyonal at ginagamit para mas madaling makakita ng mga error. Sa annotation na ito, ipinapahiwatig mo sa compiler na gusto mong i-override/ipatupad ang isang superclass/interface na paraan, at titiyakin nito na hindi ka magkakamali sa lagda ng pamamaraan.

23. Ano ang SOLID? Magbigay ng halimbawa

Ang SOLID ay isang acronym para sa Five Basic Design Principles para sa OOP, na nilikha ni Robert Martin. S - Single-responsibility principle - ang prinsipyo ng solong responsibilidad, na nagsasaad na ang isang klase ay dapat magkaroon lamang ng isang layunin at isang layunin. Iyon ay, hindi ka dapat lumikha ng mga klase na ginagawa ang lahat. Sa kasong ito, maaari mong kopyahin ang antipattern na "Banal na Bagay". Kung mayroon kang Cat object , dapat itong maglaman ng mga pamamaraan na nakikipag-ugnayan lamang sa panloob na pagpapagana nito, at hindi lohika ng negosyo na hindi nauugnay sa pagkakataong ito. Halimbawa, ilang uri ng pag-save ng mga bagay na may ganitong uri sa isang lugar. Ang panlabas na pag-andar na ito (na may kaugnayan sa Cat ) ay kailangang ilipat sa ibang mga klase, ang ilang mga serbisyo na ang gawain ay magbigay ng lohika ng negosyo para sa mga bagay na may ganitong uri. O - Open-closed na prinsipyo - prinsipyo ng openness/closedness. Nangangahulugan ito na ang mga entity ng software (mga klase, interface) ay dapat na bukas para sa extension, ngunit sarado para sa pagbabago. Halimbawa, kailangan namin ng functionality na katulad ng functionality ng dati nang Cat class , ngunit bahagyang naiiba. Sa halip na baguhin ang functionality ng Cat class , sirain ang mga lugar kung saan ito ginagamit na, ginagamit namin ang inheritance o komposisyon . Bilang resulta, nakamit namin ang aming layunin gamit ang binagong functionality ng klase ng Cat , ngunit sa parehong oras ay hindi namin ito binago o nasira ang anuman. L - Liskov substitution principle - Barbara Liskov's substitution principle. Ang prinsipyo ay nagsasaad na ang isang function na gumagamit ng base type ay dapat na gumamit ng mga subtype ng base type nang hindi nalalaman. Halimbawa, ang aming klase ng Cat ay dapat na mapagpapalit sa alinman sa mga inapo nito, sabi ng Lion , nang hindi nagbabago ang pag-uugali. Ang pangkalahatang lohika (pag-uugali) ay nananatiling pareho, ngunit ang mga detalye ng pagpapatupad ng ito o ang functionality na iyon ay nagbabago. I - Interface segregation principle - ang prinsipyo ng interface separation. Ang prinsipyong ito ay nagsasaad na mas mahusay na magkaroon ng maraming dalubhasang (makitid na nakatutok) na mga interface kaysa sa isang unibersal. Halimbawa, ang isang gumagamit ay nagpapatupad ng ilang interface, kung saan kailangan lang niya ang pamamaraang ito, ngunit ang interface na ito ay may siyam pang mga pamamaraan na walang kinalaman sa lohika ng nais na pamamaraan. Sa kasong ito, kakailanganin ng user na ipatupad ang sampung pamamaraan ng interface, siyam sa mga ito ay hindi kailangan para sa kanya! Sa halip, mas mahusay na gumawa ng sampung iba't ibang mga interface na maaaring ipatupad kung kinakailangan. Well, o hindi sampu, ngunit marami, na magkakaroon ng mga pamamaraan na malapit na nauugnay sa karaniwang layunin ng interface. D - Dependency Inversion Principle— ang prinsipyo ng dependency inversion. Ang prinsipyo ay nagsasaad na ang mga module sa mas mataas na antas ay hindi dapat umasa sa mga module sa mas mababang antas. Ang prinsipyong ito ay inilarawan din bilang "ang abstraction ay hindi dapat nakadepende sa mga detalye, ang mga detalye ay dapat nakadepende sa abstraction." Iyon ay, dapat nating buuin ang ating lohika sa pamamagitan ng pagtukoy sa mga interface, at pagkatapos lamang ipasa ang mga partikular na bagay sa pagpapaandar na ito, ang mga klase kung saan nagpapatupad ng kinakailangang interface. Halimbawa, kung mayroon kaming interface ng Cat at ilan sa mga pagpapatupad nito, halimbawa, Lion at HomeCat , binubuo namin ang aming logic sa pakikipag-ugnayan partikular sa uri ng interface ng Cat , at pagkatapos ay papalitan lamang ang isang partikular na pagpapatupad ng Lion o HomeCat , ngunit hindi kabaligtaran.

24. Ano ang isang klase, bagay, interface?

Tulad ng naaalala natin, ang Java ay isang wikang OOP. Iyon ay, ang mga programa ng Java ay binuo sa pakikipag-ugnayan sa pagitan ng mga bagay. Ito ay lumiliko na ang programa ay tulad ng isang anthill, kung saan ang bawat langgam ay isang bagay. Ang mga bagay ay ilang nakagrupong data na naglalaman ng iba't ibang pamamaraan (function) upang makipag-ugnayan sa panloob na data na ito. At ang mga klase ay mga tagubilin, mga template para sa paglikha ng mga bagay. Iyon ay, maaaring mayroong maraming mga bagay na binuo ayon sa parehong pagtuturo, na puno ng iba't ibang o magkaparehong mga halaga ng data. Upang magbigay ng isang halimbawa mula sa buhay, maaari nating sabihin na ang isang klase ay isang pagguhit ng isang gusali, at ang isang bagay ay isang partikular na nilikha na gusali batay sa pagguhit na ito. Ang mga interface ay mga analogue ng mga klase na may pagkakaiba na ang mga bagay ay hindi malikha gamit ang mga ito. Ang kanilang layunin ay magdagdag ng elemento ng abstraction sa Java. Mas tiyak, upang magdagdag ng flexibility sa mga ugnayan sa pagitan ng mga klase at mga bagay. Sa pamamagitan ng kakayahang umangkop, ibig sabihin namin ang polymorphism at abstraction na inilarawan nang mas maaga, na kung saan ay nagbubukas ng maraming pagkakataon para sa pagbuo ng panloob na arkitektura ng application.

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

POJO - Plain Old Java Object - isang magandang lumang Java object: isang simpleng object ng isang klase na hindi minana mula sa anumang partikular na klase at hindi nagpapatupad ng anumang mga interface ng serbisyo na lampas sa kailangan para sa business model. Sa madaling salita , ang klase ng POJO ay isang klase lamang na walang mga espesyal na kinakailangan. 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 naturang klase ay hindi nagmamana mula sa iba pang mga klase (maliban sa mga klase ng POJO mula sa parehong pakete), hindi nagpapatupad ng mga interface - kung minsan ang isang pagbubukod ay ginawa para sa mga marker interface mula sa karaniwang library tulad ng Serializable o Cloneable - huwag gumamit ng mga anotasyon at huwag umasa sa mga third-party na aklatan. Ngunit tandaan ko na ang mga POJO ay maaaring magkaroon ng mga pamamaraan na may lohika ng negosyo at mga konstruktor ng anumang uri. Kung papayagan mo ang mga anotasyon na hindi gumagawa ng mga pagbabago sa mga semantika ng klase (nang hindi magbabago ang layunin ng object at ang lohika ng operasyon nito), maaari ding isama ng mga POJO ang mga entity ng JPA Entity at mga object ng DTO na na-deserialize mula sa XML o JSON , ang mga patakaran kung saan tinukoy sa mga anotasyon. Maipapayo rin na i-override ang equals at hashCode para sa mga klase ng POJO , dahil maaaring makatulong ito sa kanila na gampanan ang kanilang tungkulin nang mas mahusay. 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 klase ay maaaring maglaman ng mga sumusunod na elemento:

• mga patlang ng klase;
• static na mga patlang ng klase;
• bloke ng pagsisimula;
• static na initialization block;
• constructors (walang laman ay palaging tinukoy sa pamamagitan ng default);
• paraan;
• static na pamamaraan;
• iba't ibang anotasyon (na maaaring mag-hang sa itaas ng klase mismo o mga bahagi nito);
• generics ;
• inheritance mula sa ibang klase ( extends ) o pagpapatupad mula sa mga interface ( implements ).

27. Ipaliwanag ang pamana sa Java. Ano ang mga pakinabang ng paggamit ng super keyword?

Sa itaas napag-usapan ko na ang tungkol sa pamana at ang sobrang keyword sa Java. Hayaan akong magbanggit ng ilan pang mahahalagang punto:

1. Posibleng magmana lamang ng isang klase: walang maramihang pamana sa Java (ngunit sa pagdating ng mga default na pamamaraan sa Java 8, ang pahayag na ito ay magiging napakakontrobersyal).
2. Ang mga pribadong pamamaraan at field ay minana rin, hindi lang sila magkakaroon ng access sa kanila mula sa tagapagmana (ngunit kung tayo, halimbawa, ay may pribadong field at mayroong pampubliko o protektadong mga getter at setter para dito, ang field ay maaaring gamitin sa sa pamamagitan nila).
3. ang mga huling klase ay hindi minana.
4. Ang mga huling pamamaraan ay hindi na-override (ngunit maaari silang mamana at ma-overload).
5. Ang mga static na pamamaraan at mga variable ay hindi minana (dahil ang mga ito ay nakatali hindi sa mga bagay, ngunit sa mga klase).
6. Kapag nagmana mula sa mga abstract na klase, ang pagpapatupad ng kanilang mga abstract na pamamaraan ay kinakailangan, o ang kasalukuyang klase 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 ibabaw nila).
8. Ang mga overridden na pamamaraan sa descendant ay maaaring palawigin gamit ang isang access modifier: pribado -> default -> protektado -> pampubliko .
9. Maaaring paliitin ng mga overridden na pamamaraan sa descendant ang mga exception na nakasulat, halimbawa: Exception -> IOException -> FileNotFoundException.

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

Ang lagda ng isang pamamaraan ay ang pangalan ng pamamaraan kasama ang mga uri ng mga papasok na parameter (at ang pagkakasunud-sunod ng mga parameter ay mahalaga). Ang lagda ng pamamaraan ay hindi kasama ang halaga ng pagbabalik o ang mga pagbubukod na ibinabato nito. Halimbawa ng tamang lagda:

doSomething(int, double, double)

Isang halimbawa ng maling lagda:

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!