تجزیه و تحلیل پرسش و پاسخ از مصاحبه برای توسعه دهنده جاوا. قسمت 3

سلام! همانطور که یادگیری پرواز با هواپیما بدون آموزش خاص غیرممکن است، تبدیل شدن به یک توسعه دهنده جاوا نیز بدون صرف ساعت های طولانی برای مطالعه مبانی نظری لازم غیرممکن است. امروز دقیقاً روی این کار خواهیم کرد: ما به تجزیه و تحلیل بیش از 250 سؤال مصاحبه برای توسعه دهندگان جاوا و بر این اساس، پاسخ به آنها ادامه خواهیم داد. در اینجا بخش اول و دوم تحلیل آمده است. بله، مطمئناً، بدون این همه سؤال می توانید یک توسعه دهنده خوب جاوا شوید. با این حال، اگر درک خوبی از نکات و نکات زبان جاوا داشته باشید، به شما مزیتی می‌دهد و شما را در نظر کارفرمای آینده خود کاندیدای مطلوب‌تری می‌سازد.

20. چه عناصر زبانی مسئول کپسولاسیون هستند؟

همانطور که به یاد داریم، کپسوله سازی جزئیات پیاده سازی یک کلاس را پنهان می کند. یعنی وقتی کلاس ما به صورت خارجی استفاده می شود، محتویات داخلی و منطق آن مشخص نیست. و چه عناصری از زبان مسئول این امر هستند؟ به طور طبیعی، به اصلاح کننده ها دسترسی پیدا کنید ! آنچه را که باید پنهان کنیم با اصلاح کننده خصوصی علامت گذاری می کنیم . به عنوان مثال، فیلدهای خصوصی یک کلاس یا برخی از روش های داخلی که به پیاده سازی عملکرد داخلی خاصی کمک می کنند. و به چیزی که می خواهیم دسترسی خارجی به آن ارائه دهیم، اصلاح کننده دسترسی عمومی را اضافه می کنیم . به عنوان مثال، متدی که مسئول ارائه برخی عملکردها است (که در آن روش‌های خصوصی زیادی می‌توان استفاده کرد) یا همان دریافت‌کننده‌ها و تنظیم‌کننده‌ها برای دسترسی به فیلدهای خصوصی یک کلاس. اوه، و ما همچنین اصلاح‌کننده‌های پیش‌فرض و محافظت‌شده را داریم که می‌توان از آنها برای پیکربندی انعطاف‌پذیرتر و خاص‌تر دسترسی به بخش‌های انتخابی کلاس استفاده کرد.

21. کدام عناصر زبانی مسئول وراثت هستند؟

وراثت مکانیزمی است که به شما امکان می دهد کلاس هایی را بر اساس کلاس دیگری ایجاد کنید. در جاوا از کلمه کلیدی extends برای این منظور استفاده می شود . به عنوان مثال، ما یک کلاس خاص Cat داریم و می خواهیم جانشین آن - Lion را ایجاد کنیم . در کد چیزی شبیه به این خواهد بود:

public class Lion extends Cat

و این بدان معنی است که کلاس Lion تمام متدها و متغیرهای کلاس Cat را به جز متدهای استاتیک به ارث می برد. همچنین عناصر زبان مسئول وراثت عبارتند از super . این یک مرجع مشابه این است ، اما در حالی که این به شیئی که روی آن فراخوانی شده است، اشاره دارد، super به شی والد فعلی اشاره دارد. به طور معمول از super استفاده می شود:

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 به متغیر age شی والد دسترسی پیدا کنیم ، باید این کار را از طریق super انجام دهیم :

super.name

22. کدام عناصر زبانی مسئول چندشکلی هستند؟

چند شکلی توانایی یک شی با یک امضا برای به خود گرفتن اشکال مختلف (پیاده سازی چندگانه) است. به جرات می توان گفت که در جاوا کلمات کلیدی پیاده سازی و گسترش دهنده مسئول چندشکلی هستند . Implements - وقتی اینترفیس خود را ایجاد می کنیم، یکی از فرم های ممکن آن را در کلاسی پیاده سازی می کنیم، اما این تنها فرم نیست، درست است؟ بیایید به یاد بیاوریم که پیاده سازی چگونه به نظر می رسد :

public class Cat implements Animal

و در کلاس Cat باید تمام متدهای انتزاعی ارائه شده در رابط Animal را پیاده سازی کنیم . وراثت نیز به همین صورت است: در یک کلاس descendant می‌توانیم یک پیاده‌سازی موجود از یک متد را لغو کنیم. به عنوان مثال: چندین نسل -> چندین جایگزین متفاوت از یک روش. خوب، یا سوپرکلاس انتزاعی بود و روش خاصی دارد که باید برای هر یک از فرزندانش به روشی خاص اجرا شود. یعنی می توانیم بگوییم که این روش اشکال مختلفی خواهد داشت. همچنین، حاشیه‌نویسی @Override می‌تواند در این مورد به ما کمک کند ، که در بالای متدهای پیاده‌سازی شده قرار می‌گیرد و نشان می‌دهد که می‌خواهیم (اگر پیاده‌سازی قبلاً در سوپرکلاس وجود داشته باشد) یک یا روش دیگری از سوپرکلاس یا رابط را پیاده‌سازی یا لغو کنیم. اختیاری است و برای تشخیص آسانتر خطاها استفاده می شود. با این حاشیه‌نویسی، به کامپایلر نشان می‌دهید که می‌خواهید یک متد superclass/interface را لغو/پیاده‌سازی کنید، و این اطمینان حاصل می‌کند که در امضای متد اشتباه نکنید.

23. SOLID چیست؟ مثال بزن

SOLID مخفف پنج اصل طراحی اساسی برای OOP است که توسط رابرت مارتین ابداع شده است. س - اصل تک مسئولیت - اصل مسئولیت واحد که بیان می کند یک طبقه باید فقط یک هدف و یک هدف واحد داشته باشد. یعنی نباید کلاس هایی ایجاد کنید که همه کارها را انجام دهند. در این مورد، می توانید آنتی الگوی "شیء الهی" را بازتولید کنید. اگر یک شی Cat دارید ، باید حاوی روش‌هایی باشد که فقط با عملکرد داخلی آن تعامل داشته باشند، نه منطق تجاری که به این نمونه مرتبط نیست. به عنوان مثال، نوعی ذخیره اشیاء از این نوع در جایی. این عملکرد خارجی (نسبت به Cat ) باید به کلاس های دیگر منتقل شود، برخی از سرویس هایی که وظیفه آنها ارائه منطق تجاری برای اشیاء از این نوع است. O - اصل باز - بسته - اصل باز بودن / بسته بودن. این بدان معناست که نهادهای نرم افزار (کلاس ها، رابط ها) باید برای توسعه باز باشند، اما برای اصلاح بسته شوند. به عنوان مثال، ما به عملکردی مشابه عملکرد کلاس Cat موجود نیاز داشتیم ، اما کمی متفاوت است. به‌جای تغییر عملکرد کلاس Cat ، شکستن مکان‌هایی که قبلاً از آن استفاده می‌شود، از وراثت یا ترکیب استفاده می‌کنیم . در نتیجه، ما با عملکرد اصلاح شده کلاس Cat به هدف خود رسیدیم ، اما در عین حال آن را تغییر ندادیم یا چیزی را شکستیم. L - اصل جایگزینی لیسکوف - اصل جایگزینی باربارا لیسکوف. این اصل بیان می‌کند که تابعی که از نوع پایه استفاده می‌کند باید بتواند از زیرگروه‌های نوع پایه بدون اینکه بداند استفاده کند. به عنوان مثال، کلاس Cat ما باید با هر یک از فرزندانش، مثلاً Lion ، قابل تعویض باشد ، بدون اینکه اساساً رفتار را تغییر دهد. منطق کلی (رفتار) ثابت می ماند، اما جزئیات اجرای این یا آن عملکرد تغییر می کند. I - اصل جداسازی رابط - اصل جداسازی رابط. این اصل بیان می کند که بهتر است بسیاری از رابط های تخصصی (با تمرکز محدود) نسبت به یک رابط جهانی وجود داشته باشد. به عنوان مثال، یک کاربر یک رابط را پیاده سازی می کند که فقط به این روش نیاز دارد، اما این رابط دارای 9 روش دیگر است که هیچ ربطی به منطق روش مورد نظر ندارد. در این صورت کاربر باید ده روش رابط را پیاده سازی کند که 9 تای آن برای او غیر ضروری است! در عوض، بهتر است ده رابط مختلف بسازید که در صورت لزوم قابل پیاده سازی باشند. خوب، یا نه ده، بلکه چندین، که دارای روش هایی هستند که ارتباط نزدیکی با هدف مشترک رابط دارند. د - اصل وارونگی وابستگی- اصل وارونگی وابستگی. این اصل بیان می‌کند که ماژول‌های سطوح بالاتر نباید به ماژول‌های سطوح پایین‌تر وابسته باشند. این اصل همچنین به عنوان "انتزاع نباید به جزئیات بستگی داشته باشد، جزئیات باید به انتزاع بستگی داشته باشد." یعنی باید منطق خود را با ارجاع به اینترفیس ها بسازیم و تنها پس از آن اشیاء خاصی را به این قابلیت منتقل کنیم که کلاس های آن اینترفیس مورد نیاز را پیاده سازی می کنند. به عنوان مثال، اگر یک رابط Cat و برخی از پیاده‌سازی‌های آن، مثلاً Lion و HomeCat داشته باشیم ، منطق تعامل خود را به طور خاص با نوع رابط Cat ایجاد می‌کنیم و تنها پس از آن یک پیاده‌سازی خاص از Lion یا HomeCat را جایگزین می‌کنیم ، اما نه برعکس.

24. کلاس، شیء، رابط چیست؟

همانطور که به یاد داریم، جاوا یک زبان OOP است. یعنی برنامه های جاوا بر اساس تعامل بین اشیا ساخته می شوند. معلوم می شود که برنامه مانند یک لانه مورچه است که هر مورچه یک شی است. اشیاء برخی از داده های گروه بندی شده هستند که شامل روش های مختلف (توابع) برای تعامل با این داده های داخلی هستند. و کلاس ها دستورالعمل ها، قالب هایی برای ایجاد اشیا هستند. به این معنی که می‌توان اشیاء زیادی را طبق دستورالعمل یکسان ساخته و با مقادیر داده‌های متفاوت یا یکسان پر شده باشد. برای مثالی از زندگی، می‌توان گفت که یک کلاس نقاشی یک ساختمان است و یک شی، ساختمانی است که بر اساس این نقاشی ایجاد شده است. اینترفیس ها آنالوگ کلاس ها هستند با این تفاوت که با استفاده از آنها نمی توان اشیاء ایجاد کرد. هدف آنها افزودن یک عنصر انتزاعی به جاوا است. به طور دقیق تر، برای افزودن انعطاف پذیری در روابط بین کلاس ها و اشیاء. منظور ما از انعطاف پذیری چندشکلی و انتزاعی است که قبلاً توضیح داده شد، که به نوبه خود فرصت های زیادی را برای ساخت معماری داخلی برنامه باز می کند.

25. کلاس POJO چیست؟ مثالی از چنین کلاسی بزنید

POJO - Plain Old Java Object - یک شیء قدیمی جاوا: یک شی ساده از یک کلاس که از کلاس خاصی به ارث برده نشده است و هیچ رابط سرویسی فراتر از آنچه برای مدل کسب و کار مورد نیاز است پیاده سازی نمی کند. به عبارت دیگر ، یک کلاس POJO فقط یک کلاس بدون نیاز خاص است. تنها شرط عدم وجود زنگ ها و سوت های مختلف است که به یک چارچوب خاص گره خورده است. به عنوان یک قاعده، چنین کلاس هایی از کلاس های دیگر ارث نمی برند (به جز کلاس های POJO از همان بسته)، رابط ها را پیاده سازی نمی کنند - گاهی اوقات برای رابط های نشانگر از کتابخانه استاندارد مانند Serializable یا Cloneable استثنا ایجاد می شود - از حاشیه نویسی استفاده نکنید. و به کتابخانه های شخص ثالث وابسته نیستند. اما توجه دارم که POJO ها می توانند روش هایی با منطق تجاری و سازنده های هر نوع داشته باشند. اگر به حاشیه‌نویسی‌هایی اجازه دهید که تغییراتی در معنای کلاس ایجاد نمی‌کنند (بدون آن هدف شی و منطق عملکرد آن تغییر نمی‌کند)، POJO‌ها همچنین می‌توانند شامل موجودیت‌های نهاد JPA و اشیاء DTO باشند که از XML یا JSON جدا شده‌اند . قوانینی که برای آنها در حاشیه نویسی مشخص شده است. همچنین توصیه می‌شود برای کلاس‌های POJO ، برابر و هش‌کد را لغو کنید ، زیرا ممکن است به آن‌ها کمک کند نقش خود را بهتر انجام دهند. نمونه کلاس 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. یک کلاس می تواند شامل چه عناصری باشد؟

کلاس ممکن است شامل عناصر زیر باشد:

• فیلدهای کلاس؛
• فیلدهای کلاس ایستا؛
• بلوک اولیه
• بلوک اولیه سازی استاتیک؛
• سازنده ها (خالی همیشه به طور پیش فرض تعریف می شود).
• مواد و روش ها؛
• روش های استاتیک؛
• حاشیه نویسی های مختلف (که می توانند بالای خود کلاس یا اجزای آن قرار بگیرند).
• ژنریک ;
• ارث بری از کلاس‌های دیگر ( exts ) یا پیاده‌سازی از رابط‌ها ( ابزارها ).

27. وراثت در جاوا را توضیح دهید. مزایای استفاده از کلمه کلیدی super چیست؟

در بالا قبلاً در مورد وراثت و کلمه کلیدی فوق العاده در جاوا صحبت کردم. اجازه دهید به چند نکته مهم دیگر اشاره کنم:

1. می توان تنها یک کلاس را به ارث برد: در جاوا وراثت چندگانه وجود ندارد (اما با ظهور روش های پیش فرض در جاوا 8، این عبارت بسیار بحث برانگیز خواهد شد).
2. روش‌ها و فیلدهای خصوصی نیز ارثی هستند، فقط از طرف وارث به آنها دسترسی نخواهند داشت (اما اگر مثلاً یک فیلد خصوصی داشته باشیم و دریافت‌کننده‌ها و تنظیم‌کننده‌های عمومی یا محافظت‌شده برای آن وجود داشته باشد، می‌توان با این فیلد کار کرد. از طریق آنها).
3. کلاس های پایانی ارثی نیستند.
4. روش های نهایی نادیده گرفته نمی شوند (اما می توانند ارثی و بارگذاری شوند).
5. متدها و متغیرهای استاتیک به ارث نمی رسند (زیرا نه به اشیا، بلکه به کلاس ها مرتبط هستند).
6. هنگام ارث بردن از کلاس های انتزاعی، پیاده سازی روش های انتزاعی آنها مورد نیاز است یا کلاس فعلی نیز باید انتزاعی اعلام شود.
7. اگر سازنده های غیر پیش فرض در والد وجود داشته باشد، باید در کلاس فرزند بازنویسی شوند (اما @Override روی آنها نوشته نمی شود).
8. متدهای رد شده در نسل را می توان با یک اصلاح کننده دسترسی گسترش داد: private -> default -> protected -> public .
9. متدهای رد شده در decendent می توانند استثناهایی را که نوشته شده اند محدود کنند، به عنوان مثال: Exception -> IOException -> FileNotFoundException.

28. امضای متد چیست؟ نمونه هایی از امضاهای صحیح و نادرست را ذکر کنید

امضای یک روش نام روش به اضافه انواع پارامترهای ورودی است (و ترتیب پارامترها مهم است). امضای متد شامل مقدار بازگشتی یا استثناهایی که پرتاب می‌کند نمی‌شود. نمونه ای از امضای صحیح:

doSomething(int, double, double)

نمونه ای از امضای نادرست:

void doSomething(int firstArg, int secondArg) throws Exception

امضای متد، همراه با نوع بازگشتی و لیست استثناهایی که پرتاب می‌شوند، قرارداد روش نامیده می‌شود . برای امروز کافی است. بعدا میبینمت!