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

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

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

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

21. چه عناصری از زبان امکان وراثت را فراهم می کند؟

وراثت مکانیزمی است که به شما امکان می دهد کلاس هایی را بر اساس کلاس دیگری ایجاد کنید. جاوا کلمه کلیدی extensions را برای این کار دارد. به عنوان مثال، فرض کنید ما یک کلاس Cat داریم و می خواهیم یک کلاس Lion child ایجاد کنیم. در کد، چیزی شبیه به این خواهد بود:

public class Lion extends Cat

و این بدان معنی است که کلاس Lion تمام متدها و متغیرهای کلاس Cat را به جز متغیرهای استاتیک به ارث می برد. یکی دیگر از عناصر زبان که مسئول وراثت است super است . مرجعی مشابه این است . کلمه کلیدی this به شیئی اشاره دارد که در آن ارجاع داده شده است. کلمه کلیدی 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 بخواهیم به متغیر سن شی والد مراجعه کنیم، باید از طریق super این کار را انجام دهیم :

super.name

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

چند شکلی توانایی یک شی با یک امضا برای به خود گرفتن اشکال مختلف (پیاده سازی های زیاد) است. ما با اطمینان می‌توانیم بگوییم که کلیدواژه‌های جاوا که پیاده‌سازی و گسترش می‌دهند ، مسئول چندشکلی هستند. وقتی یک رابط داریم، پیاده‌سازی به ما امکان می‌دهد یک پیاده‌سازی ممکن را ارائه کنیم، اما این نباید تنها پیاده‌سازی باشد، درست است؟ بیایید نحوه استفاده از ابزارها را دوباره بررسی کنیم :

public class Cat implements Animal

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

23. SOLID چیست؟ مثال هایی ارائه کنید

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

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

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

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

POJO (ابجکت جاوا قدیمی ساده) یک شی کلاس ساده است که از کلاس خاصی ارث نمی برد و هیچ رابط سرویسی فراتر از آنچه برای مدل کسب و کار مورد نیاز است پیاده سازی نمی کند. به عبارت دیگر، کلاس POJO فقط یک کلاس بدون نیاز خاص است. تنها شرط عدم وجود زنگ ها و سوت های مختلف است که به یک چارچوب خاص گره خورده است. به عنوان یک قاعده، این کلاس‌ها کلاس‌های دیگر را به ارث نمی‌برند (به جز کلاس‌های POJO در همان بسته)، رابط‌ها را پیاده‌سازی نمی‌کنند (گاهی برای رابط‌های نشانگر از کتابخانه استاندارد مانند Serializable یا Cloneable استثنا ایجاد می‌شود )، از حاشیه‌نویسی استفاده نمی‌کنند. ، و به کتابخانه های شخص ثالث وابسته نیست. بیایید توجه داشته باشیم که یک POJO می‌تواند متدهایی شامل منطق تجاری و سازنده‌هایی از هر نوع داشته باشد. اگر به حاشیه‌نویسی‌هایی اجازه دهیم که معنای کلاس را تغییر نمی‌دهند (یعنی حاشیه‌نویسی‌هایی که عدم وجود آنها هدف یا منطق شی را تغییر نمی‌دهد)، POJOs همچنین می‌تواند شامل موجودیت‌های 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 ) یا پیاده سازی رابط ها ( Implements ).

27. در مورد وراثت در جاوا به ما بگویید. ویژگی های کلمه کلیدی super چیست؟

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

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

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

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

doSomething(int, double, double)

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

void doSomething(int firstArg, int secondArg) throws Exception

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