Java иштеп чыгуучусу үчүн интервьюдан алынган суроолордун жана жооптордун анализи. 3-бөлүк

Салам! Атайын даярдыксыз учакта учууну үйрөнүү мүмкүн болбогондой эле, керектүү теориялык базаны изилдөөгө көп саат коротпостон Java иштеп чыгуучусу болуу да мүмкүн эмес. Бүгүн биз так ушул боюнча иштейбиз: биз Java иштеп чыгуучулары үчүн 250+ интервью суроолорун жана ошого жараша аларга жоопторду талдоону улантабыз . Бул жерде талдоо биринчи жана экинчи бөлүктөрү болуп саналат. Ооба, албетте, сиз бардык суроолорсуз эле жакшы Java иштеп чыгуучусу боло аласыз. Бирок, эгер сиз Java тorнин сырларын жакшы түшүнсөңүз, анда бул сизге артыкчылык берип, келечектеги иш берүүчүңүздүн көз алдында сизди эң ​​керектүү талапкер кылат.

20. Инкапсуляцияга кайсы тил элементтери жооп берет?

Эсибизде болгондой, инкапсуляция класстын ишке ашыруу деталдарын жашырып жатат. Башкача айтканда, биздин класс сырттан колдонулганда, ички мазмуну жана логикасы ачык эмес. Ал эми бул үчүн тилдин кайсы элементтери жооп берет? Албетте, кирүү өзгөрткүчтөрү ! Биз жашырышыбыз керек болгон нерсени купуя өзгөрткүч менен белгилейбиз . Мисалы, класстын жеке талаалары же белгилүү бир ички функцияларды ишке ашырууга жардам берген ички ыкмалар. Жана биз тышкы мүмкүнчүлүктү камсыз кылгыбыз келген нерсеге биз жалпыга жеткorктүүлүк өзгөрткүчтү кошобуз . Мисалы, кээ бир функцияларды камсыз кылуу үчүн жооптуу метод (анын ичинде көптөгөн жеке ыкмалар колдонулушу мүмкүн) же класстын жеке талааларына жетүү үчүн ошол эле алгычтар жана орнотуучулар. О, ошондой эле бизде демейки жана корголгон модификаторлор бар , аларды класстын тандалган бөлүктөрүнө кирүүнүн ийкемдүү жана конкреттүү конфигурациялары үчүн колдонсо болот.

21. Тилдин кайсы элементтери мураска жооп берет?

Мурас - бул башка класстын негизинде класстарды түзүүгө мүмкүндүк берүүчү механизм. Java тorнде кеңейтүү ачкыч сөзү ушул максат үчүн колдонулат . Мисалы, бизде белгилүү бир Cat классы бар жана биз анын мураскерин түзгүбүз келет - Lion . Коддо ал төмөнкүдөй көрүнөт:

public class Lion extends Cat

Бул Lion классы статикалык ыкмалардан башка Cat классынын бардык ыкмаларын жана өзгөрмөлөрүн мурастайт дегенди билдирет. Ошондой эле, мурас үчүн жооптуу тил элементтерин камтыйт super . Бул ушуга окшош шилтеме , бирок бул ал чакырылган an objectке тиешелүү болсо, super учурдагы негизги an objectке тиешелүү. Адатта супер колдонулат:

1. Супер класстын конструкторун чакыруу үчүн: Мисалы, Cat классынын конструктордо инициализацияланышы керек болгон ички өзгөрмө аты бар. Lion классынын конструкторунда бул мындай болот:

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

2. Аталык талааларга жана ыкмаларга кирүү үчүн: мисалы, Cat классында бизде инициализацияланган жаш талаа бар :

   public class Cat {
      int age = 10;

Ошол эле учурда, Lion'да бизде бирдей инициализацияланган талаа бар :

public class Lion extends Cat {
   int age = 15;

Жана эгер биз Lion an objectинен ата-энелик an objectинин жаш өзгөрмөсүнө кирүүнү кааласак , муну super аркылуу кылышыбыз керек :

super.name

22. Полиморфизмге кайсы тил элементтери жооп берет?

Полиморфизм – бир кол коюлган an objectтин көптөгөн формаларды (бир нече ишке ашыруу) алуу жөндөмдүүлүгү. Биз ишенимдүү түрдө айта алабыз, Java-да аткарылган жана кеңейтилген ачкыч сөздөр полиморфизм үчүн жооптуу . ишке ашырат - интерфейсибизди түзүп жатканда, биз анын мүмкүн болгон формаларынын бирин кандайдыр бир класста ишке ашырабыз, бирок бул жалгыз форма эмес, туурабы? Келгиле, ишке ашыруучу аспаптар кандай болорун эстеп көрөлү :

public class Cat implements Animal

Ал эми Cat классында биз Animal интерфейсинде берилген бардык абстракттуу ыкмаларды ишке ашырышыбыз керек . Бул мураска да тиешелүү: тукум класста биз методдун буга чейин болгон ишке ашырылышын жокко чыгара алабыз. Мисалы: бир нече тукум -> бир эле ыкманын бир нече түрдүү жокко чыгаруулары. Ооба, же суперкласс абстракттуу болгон жана анын ар бир тукуму үчүн өзгөчө жол менен ишке ашырылышы керек болгон белгилүү бир ыкмасы бар. Башкача айтканда, ыкма көп формада болот деп айта алабыз. Ошондой эле, @Override annotationсы бизге бул жагынан жардам бере алат , ал ишке ашырылган методдордун үстүнө жайгаштырылган жана биз ишке ашырууну же жокко чыгарууну каалай турганыбызды (эгерде ишке ашыруу суперкласста мурунтан эле бар болсо) суперкласстын же интерфейстин тигил же бул ыкмасын көрсөтөт. Бул милдеттүү эмес жана каталарды аныктоону жеңилдетүү үчүн колдонулат. Бул annotation менен сиз компиляторго суперкласс/интерфейс ыкмасын жокко чыгаргыңыз/ишке ашырууну каалап жатканыңызды көрсөтөсүз жана бул ыкма кол тамгасында ката кетирбөөнү камсыздайт.

23. СОЛИД деген эмне? Мисалдар келтиргиле

SOLID Роберт Мартин тарабынан иштелип чыккан OOP үчүн беш Негизги Дизайн Принциптеринин кыскартылган аббревиатурасы. S – Бирдиктүү жоопкерчorк принциби – класстын бир гана максаты жана бир максаты болушу керек деген бирдиктүү жоопкерчorк принциби. Башкача айтканда, бардыгын жасаган класстарды түзбөшүңүз керек. Бул учурда, сиз "Кудайдын an objectисинин" антипаттернди кайра чыгара аласыз. Эгер сизде Cat an objectи болсо , анда бул инстанцияга тиешеси жок бизнес логикасы эмес, анын ички функциялары менен гана өз ара аракеттенүүчү методдор камтылууга тийиш. Мисалы, бул типтеги an objectтерди кандайдыр бир жерде сактоо. Бул тышкы функцияларды ( Cat га салыштырмалуу ) башка класстарга, кээ бир кызматтарга өткөрүп берүү керек, алардын милдети ушул типтеги an objectтер үчүн бизнес логикасын камсыз кылуу болуп саналат. О - Ачык-жабык принцип - ачыктык/жабыктык принциби. Бул программалык камсыздоо an objectтери (класстар, интерфейстер) кеңейтүү үчүн ачык, бирок өзгөртүү үчүн жабык болушу керек дегенди билдирет. Мисалы, бизге мурунтан эле бар Cat классынын функционалдуулугуна окшош функция керек болчу , бирок бир аз башкачараак. Cat классынын функционалдуулугун өзгөртүүнүн , ал мурда колдонулган жерлерди бузуунун ордуна, биз мурас же композицияны колдонобуз . Натыйжада, биз Cat классынын өзгөртүлгөн функционалдуулугу менен өз максатыбызга жеттик , бирок ошол эле учурда биз аны өзгөрткөн жокпуз жана эч нерсени бузган жокпуз. L - Liskov алмаштыруу принциби - Барбара Лисковдун алмаштыруу принциби. Принцип базалык типти колдонгон функция аны билбей туруп базалык типтин субтиптерин колдоно алышы керек деп айтылат. Мисалы, биздин Cat классыбыз анын урпактарынын бири менен алмаштырылышы керек, айталы, Lion , жүрүм-турумун түп тамырынан бери өзгөртпөстөн. Жалпы логика (жүрүм-турум) ошол эле бойдон калат, бирок тигил же бул функцияны ишке ашыруунун деталдары өзгөрөт. I - Interface segregation принцип - интерфейсти бөлүү принциби. Бул принцип бир универсалдуу интерфейске караганда көп адистештирилген (тар багытталган) интерфейстерге ээ болуу жакшыраак экенин айтат. Мисалы, колдонуучу кандайдыр бир интерфейсти ишке ашырат, анын ичинен ага ушул гана метод керек, бирок бул интерфейсте каалаган методдун логикасына эч кандай тиешеси жок дагы тогуз метод бар. Бул учурда, колдонуучуга он интерфейс ыкмасын ишке ашыруу керек болот, анын тогузу ага керексиз! Анын ордуна, зарыл болгон учурда ишке ашырыла турган он түрдүү интерфейсти жасаган жакшы. Ооба, же он эмес, бирок интерфейстин жалпы максаты менен тыгыз байланышкан ыкмаларга ээ болгон бир нече. D - Көз карандылыктын инversion принциби— көз карандылыктын инversion принциби. Принципте жогору деңгээлдеги модулдар төмөнкү деңгээлдеги модулдардан көз каранды болбошу керек деп айтылат. Бул принцип «абстракция деталдарга көз каранды болбошу керек, деталдар абстракцияга көз каранды болушу керек» деп да сүрөттөлөт. Башкача айтканда, интерфейстерге шилтеме кылуу менен логикабызды түзүшүбүз керек, андан кийин гана класстары талап кылынган интерфейсти ишке ашырган бул функцияга конкреттүү an objectтерди өткөрүп беришибиз керек. Мисалы, бизде Cat интерфейси жана анын кээ бир ишке ашыруулары болсо, айталы, Lion жана HomeCat , биз өз ара аракеттенүү логикабызды атайын Cat интерфейсинин түрү менен курабыз жана андан кийин гана Lion же HomeCatтин конкреттүү ишке ашыруусун алмаштырабыз , бирок тескерисинче эмес.

24. Класс, an object, интерфейс деген эмне?

Эсибизде болгондой, Java бул OOP тor. Башкача айтканда, Java программалары an objectилердин ортосундагы өз ара аракеттенүүгө негизделген. Көрсө, программа кумурсканын уюгуна окшош экен, ал жерде ар бир кумурска an object болуп саналат. Объекттер – бул ички маалыматтар менен өз ара аракеттенүү үчүн ар кандай ыкмаларды (функцияларды) камтыган кээ бир топтоштурулган маалыматтар. Ал эми класстар - an objectтерди түзүү үчүн инструкциялар, шаблондор. Башкача айтканда, бир эле нускамага ылайык курулган, ар кандай же бирдей маалымат баалуулуктары менен толтурулган көптөгөн an objectтер болушу мүмкүн. Турмуштан мисал келтире турган болсок, класс бул имараттын чийме, ал эми an object бул чийме боюнча атайын түзүлгөн имарат деп айтсак болот. Интерфейстер класстардын аналогдору, алардын жардамы менен an objectтерди түзүү мүмкүн эмес. Алардын максаты Java үчүн абстракция элементин кошуу болуп саналат. Тагыраак айтканда, класстар менен an objectтердин ортосундагы мамилелерге ийкемдүүлүктү кошуу. Ийкемдүүлүк деп биз мурда сүрөттөлгөн полиморфизмди жана абстракцияны түшүнөбүз, бул өз кезегинде колдонмонун ички архитектурасын куруу үчүн көптөгөн мүмкүнчүлүктөрдү ачат.

25. POJO классы деген эмне? Мындай класска мисал келтиргиле

POJO - Plain Old Java Object - жакшы эски Java an objectи: класстын жөнөкөй an objectиси, ал кандайдыр бир конкреттүү класстан тукум кууп өтпөгөн жана бизнес модели үчүн зарыл болгондордон тышкары эч кандай сервистик интерфейстерди ишке ашырbyte. Башка сөз менен айтканда , POJO классы бул жөн гана атайын талаптары жок класс. Бир гана талап - белгилүү бир рамкага байланган ар кандай коңгуроолордун жана ышкырыктардын жоктугу. Эреже катары, мындай класстар башка класстардан мурастаbyte ( ошол эле пакеттеги POJO класстарынан тышкары), интерфейстерди ишке ашырbyte - кээде Serializable же Cloneable сыяктуу стандарттык китепканадан маркер интерфейстери үчүн өзгөчө жагдай жасалат - annotationларды колдонбоңуз жана үчүнчү тараптын китепканаларынан көз каранды эмес. Бирок POJOs бизнес логикасы жана ар кандай түрдөгү конструкторлор менен методдорго ээ болушу мүмкүн экенин белгилейм . Эгер класстын семантикасына өзгөртүүлөрдү киргизбеген annotationларга уруксат берсеңиз (ансыз an objectтин максаты жана анын иштөө логикасы өзгөрбөйт), POJOs ошондой эле XML же JSONден сериядан ажыратылган JPA Entity an objectтерин жана DTO an objectтерин камтышы мүмкүн , эрежелери annotationларда көрсөтүлгөн. Ошондой эле POJO класстары үчүн тең жана hashCode codeдорун жокко чыгаруу сунушталат , анткени бул алардын ролун жакшыраак аткарууга жардам бериши мүмкүн. 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. Класс кандай элементтерди камтышы мүмкүн?

Класс төмөнкү элементтерди камтышы мүмкүн:

• класс талаалары;
• статикалык класс талаалары;
• инициализация блогу;
• статикалык баштоо блогу;
• конструкторлор (бош дайыма демейки боюнча аныкталат);
• методдору;
• статикалык методдор;
• ар кандай annotationлар (класстын өзүнөн же анын компоненттеринин үстүнөн orнип калышы мүмкүн);
• generics ;
• башка класстардан мурастоо ( кеңейтүү ) же интерфейстерден ( инструкциялардан ) ишке ашыруу.

27. Java тorндеги мурасты түшүндүргүлө. Супер ачкыч сөздү колдонуунун кандай пайдасы бар?

Жогоруда мен мурас жана Javaдагы супер ачкыч сөзү жөнүндө айттым. Дагы бир нече маанилүү ойлорду айта кетейин:

1. Бир гана классты мурастоого болот: Javaда бир нече тукум куучулук жок (бирок Java 8де демейки ыкмалардын пайда болушу менен бул билдирүү абдан талаштуу болуп калат).
2. Жеке ыкмалар жана талаалар да тукум кууп өткөн, алар жөн гана мураскордон аларга кире алbyte (бирок, мисалы, бизде жеке талаа бар болсо жана ал үчүн коомдук же корголгон алуучулар жана орнотуучулар бар болсо, талаа менен иштөөгө болот. алар аркылуу).
3. акыркы класстар тукум кууп өткөн эмес.
4. акыркы ыкмалар жокко чыгарылbyte (бирок алар тукум кууп өтүп, ашыкча жүктөлүшү мүмкүн).
5. статикалык методдор жана өзгөрмөлөр тукум кууbyte (анткени алар an objectтерге эмес, класстарга байланган).
6. Абстрактуу класстардан мурастоодо алардын абстракттуу методдорун ишке ашыруу талап кылынат, же учурдагы класс да абстракттуу деп жарыяланышы керек.
7. Эгерде ата-энелерде демейки эмес конструкторлор бар болсо, алар бала класста жокко чыгарылууга тийиш (бирок @Override алардын үстүнө жазылган эмес).
8. Тукумдагы жокко чыгарылган ыкмаларды кирүү модификатору менен узартса болот: private -> default -> protected -> public .
9. Тукумдагы жокко чыгарылган ыкмалар жазылган өзгөчөлүктөрдү тарытат, мисалы: Exception -> IOException -> FileNotFoundException.

28. Метод кол тамгасы деген эмне? Туура жана туура эмес кол коюуларга мисал келтиргиле

Методдун кол тамгасы - бул ыкманын аталышы жана кирүүчү параметрлердин түрлөрү (жана параметрлердин тартиби маанилүү). Метод колтамгасы кайтаруу маанисин же ал ыргыткан өзгөчөлүктү камтыbyte. Туура кол коюунун мисалы:

doSomething(int, double, double)

Туура эмес кол коюунун мисалы:

void doSomething(int firstArg, int secondArg) throws Exception

Метод кол тамгасы, кайтаруу түрү жана ыргытылган өзгөчөлүктөрдүн тизмеси менен айкалышып, метод келишими деп аталат . Бүгүнкү күндө баары ушул. Көрүшкөнчө!