تحليل الأسئلة والأجوبة من المقابلات لمطور جافا. الجزء 6

مرحبا بالعالم! الاستمرار في التطوير مهم جدًا لأي مطور. بعد كل شيء، إذا توقفت، فهناك خطر أن تصبح غير مطالب بها وتطير بالكامل من السوق: عالم تكنولوجيا المعلومات يتطور باستمرار ويتحرك إلى الأمام، وتحتاج إلى التحرك معه. ولكن حتى في الوقت نفسه، من المستحيل التركيز فقط على التقنيات الجديدة والحديثة، حتى لا ننسى، إذا جاز التعبير، حول الكلاسيكيات (المواضيع الكلاسيكية). أريد اليوم أن أواصل تحليلي للأسئلة المتعلقة بالموضوعات "الكلاسيكية" لمطور Java. وألاحظ أن إجاباتي ليست هي المرجع النهائي - هكذا أرى الإجابات الصحيحة على هذه الأسئلة، وقد لا تتفق مع بعضها. سيكون هذا أمرًا طبيعيًا تمامًا، لذا لا تتردد في مشاركة رأيك في التعليقات. روابط لأجزاء من التحليل موجودة في نهاية المقال.

المكتبات والمعايير

52. ما هو السبات؟ ما هو الفرق بين JPA والإسبات؟

أعتقد أنه للإجابة على هذا السؤال، نحتاج أولاً إلى فهم ما هو JPA . JPA عبارة عن مواصفات تصف التعيين العلائقي للكائنات لكائنات Java البسيطة وتوفر واجهة برمجة تطبيقات لتخزين هذه الكائنات واسترجاعها ومعالجتها. وهذا هو، كما نتذكر، يتم تقديم قواعد البيانات العلائقية (DBs) في شكل العديد من الجداول المترابطة. و JPA هو معيار مقبول على نطاق واسع يصف كيفية تفاعل الكائنات مع قواعد البيانات العلائقية. كما ترون، JPA هو شيء مجرد وغير ملموس. إنها مثل الفكرة نفسها، النهج. وفي الوقت نفسه، تعد مكتبة Hibernate مكتبة محددة تنفذ نماذج JPA . أي أنه بمساعدة هذه المكتبة يمكنك العمل مع قاعدة بيانات علائقية من خلال كائنات تمثل بيانات من قاعدة البيانات (الكيان). كما يقولون، هذه المكتبة قريبة جدًا من مُثُل JPA وربما لهذا السبب أصبحت شائعة. وكما تفهم، فإن شعبية الاستخدام هي حجة جيدة لمزيد من التطوير والتحسينات. بالإضافة إلى ذلك، وراء الاستخدام المتكرر هناك مجتمع ضخم قام بالفعل بفرز جميع الأسئلة الممكنة والمستحيلة المتعلقة بهذه الأداة. فيما يلي مثال لكتاب يدرس بالتفصيل جميع الزوايا المظلمة لهذه التكنولوجيا. وهذا يعني أن السبات قد تمت دراسته قدر الإمكان، واتضح أنه موثوق به. في الواقع، ليس من قبيل الصدفة أنه حتى التنفيذ المثالي لـ JPA على الجانب الربيعي عادة ما يستخدم السبات تحت الغطاء.

53. ما هو المتتالية؟ كيف يتم استخدامه في السبات؟

كما قلت سابقًا، في السبات، يتم الاتصال من خلال كائنات بيانات تسمى الكيانات . تمثل هذه الكيانات بعض الجداول المحددة في قاعدة البيانات، وكما تتذكر، في فئات Java يمكن أن تحتوي على مراجع لفئات أخرى. وتنعكس هذه العلاقات في قاعدة البيانات. في قاعدة البيانات، كقاعدة عامة، تكون إما مفاتيح خارجية (لـ OneToOne، OneToMany، ManyToOne) أو جداول وسيطة (لـ ManyToMany). يمكنك قراءة المزيد عن العلاقة بين الكيانات في هذه المقالة . عندما يكون لدى كيانك روابط إلى كيانات أخرى ذات صلة، يتم وضع التعليقات التوضيحية فوق هذه الروابط للإشارة إلى نوع الاتصال: @OneToOne، @OneToMany، @ManyToOne، @ManyToMane، والتي يمكنك من خلال معلماتها تحديد قيمة الخاصية - cascade - نوع التتالي لهذا الاتصال. لدى JPA طرق محددة للتفاعل مع الكيانات (الاستمرار، الحفظ، الدمج...) . تُستخدم الأنواع المتتالية بدقة لإظهار كيفية تصرف البيانات المرتبطة عند استخدام هذه الأساليب في الكيان المستهدف. إذًا، ما هي الاستراتيجيات المتتالية (أنواع المتتالية)؟ يتضمن معيار JPA استخدام ستة أنواع من التتالي:

• PERSIST - ستتم عمليات الحفظ بشكل متتالي (لطرق الحفظ () والمستمر () ). أي أنه إذا قمنا بحفظ كيان مرتبط بكيانات أخرى، فسيتم حفظها أيضًا في قاعدة البيانات (إذا لم تكن موجودة بالفعل)

• MERGE - ستحدث عمليات التحديث بشكل متتالي (لطريقة الدمج () )

• REMOVE - تحدث عمليات الإزالة بشكل متتالي ( طريقة الإزالة ( )

• الكل - يحتوي على ثلاث عمليات متتالية في وقت واحد - الاستمرار - الدمج - الإزالة

لدى JPA مفهوم الكيان المستمر - كيان مرتبط ببياناته في قاعدة البيانات، والذي يتم التحكم فيه من خلال الجلسة الحالية (الاتصال) . إذا قمت بتغييره، ولكن لم تقم بحفظ التغييرات في قاعدة البيانات، فستظل بياناته في قاعدة البيانات تتغير.

• DETACH - لن تتم إدارة الكيانات ذات الصلة من خلال الجلسة ( طريقة detach() ). أي أنه عندما يتغيرون، لن يكون هناك تغيير تلقائي في بياناتهم في قاعدة البيانات - يتم نقلهم من حالة الثبات إلى حالة منفصلة (كيان لا تتم إدارته بواسطة JPA)

• تحديث - في كل مرة يتم فيها تحديث كيان ببيانات من قاعدة البيانات ( تحديث () - تحديث الكائنات المنفصلة)، يتم تحديث الكيانات ذات الصلة بنفس الطريقة. على سبيل المثال، قمت بطريقة ما بتغيير البيانات المأخوذة من قاعدة البيانات وتريد إرجاع قيمها الأصلية. في هذه الحالة، ستكون هذه العملية مفيدة لك.

يدعم Hibernate جميع هذه العمليات المتتالية القياسية، ولكنه يقدم أيضًا ثلاث عمليات خاصة به:

• النسخ المتماثل - يُستخدم عندما يكون لدينا أكثر من مصدر بيانات واحد ونريد مزامنة البيانات (طريقة السبات - النسخ المتماثل). يجب أن يكون لدى جميع الكيانات معرفات (معرف) حتى لا تكون هناك مشاكل في إنشائها (حتى لا يكون لدى نفس الكيان معرفات مختلفة لقواعد بيانات مختلفة)

• SAVE_UPDATE - حفظ/حذف متتالي (لطريقة السبات - saveOrUpdate )

• LOCK هي العملية العكسية لـ DETACHED : فهي تنقل الكيان المنفصل مرة أخرى إلى حالة الثبات ، أي. سيتم تعقب الكيان مرة أخرى خلال الجلسة الحالية

إذا لم يتم تحديد النوع المتتالي، فلن يكون لأي عملية على الكيان أي تأثير على الكيانات الأخرى المرتبطة به.

54. هل يمكن لفئة الكيان أن تكون مجردة؟

في مواصفات JPA في الفقرة 2.1 فئة الكيان يوجد سطر: " يمكن أن تكون كل من الفئات المجردة والملموسة كيانات ." لذا فإن الإجابة هي نعم، يمكن أن تكون الفئة المجردة كيانًا ويمكن التعليق عليها باستخدام @Entity.

55. ما هو مدير الكيان؟ ما هو المسؤول عنه؟

أولاً، أود أن أشير إلى أن EntityManager هو أحد المكونات الرئيسية لـ JPA ، والذي يُستخدم لتفاعل الكيانات مع قاعدة البيانات. بشكل عام، يستدعي طرق التفاعل بين الكيان وقاعدة البيانات (استمرار، دمج، إزالة، فصل)... لكنني أود أيضًا أن أشير إلى أن هذا المكون، كقاعدة عامة، ليس مكونًا للتطبيق بأكمله: في أغلب الأحيان إنه خفيف الوزن وغالبًا ما تتم إزالته ويتم إنشاء واحد جديد باستخدام EntityManagerFactory . إذا رسمنا توازيًا مع JDBC ، حيث سيكون EntityManagerFactory نظيرًا لـ DataSource ، فإن EntityManager بدوره سيكون نظيرًا لـ Connection . لقد ذكرت سابقًا كيانًا ثابتًا ، ككيان يتم التحكم فيه عن طريق الاتصال الحالي. لذلك: تتم إدارة هذا الكيان بدقة بواسطة EntityManager ، الذي يرتبط ارتباطًا وثيقًا بالاتصال الحالي و TransactionManager ، المسؤول عن فتح/إغلاق المعاملات. علاوة على ذلك، يمكنك في الشكل أدناه رؤية دورة حياة الكيان: يقوم EntityManager بإدارة الكيان عندما يكون في المرحلة المُدارة (في هذا الوقت يكون مستمرًا، لأنه يحتوي على اتصال مع EntityManager). أي أنها لم تعد جديدة ولم تتم إزالتها بعد. يمكننا القول أنه عندما يكون الكيان جديدًا أو محذوفًا، فهو منفصل أيضًا، لأنه ولا تتم إدارته بواسطة EntityManager. هناك استراتيجيات مختلفة لـ EntityManager. وهذا يعني أنه يمكن أن يكون هناك EntityManager واحد للتطبيق بأكمله، أو يمكن إنشاء مدير جديد في كل مرة، لكل اتصال. إذا كنت تستخدم Spring، فسيتم التحكم في إنشاء/حذف EntityManager تلقائيًا ضمن الغطاء (ولكن هذا لا يعني أنه لا يمكنك تخصيصه ^^). تجدر الإشارة إلى أن واحدًا أو أكثر من مديري الكيانات يشكلون سياق الثبات . سياق الاستمرار هو بيئة تتم فيها مزامنة مثيلات الكيانات مع كيانات مماثلة في قاعدة البيانات (كما قلت، هذا يعمل فقط مع الكيانات المستمرة). إذا تعمقت في JPA (وهو ما أوصي به بشدة)، فسوف تصادف هذه المفاهيم في كثير من الأحيان.

56. ما هي فئة التأكيد؟ لماذا استخدامه؟

لم أسمع عن مثل هذا الفصل في JPA ، لذا سأفترض أن هذا يشير إلى فئة JUnit الخاصة بالمكتبة، والتي تُستخدم لاختبار وحدة التعليمات البرمجية. يتم استخدام فئة هذه المكتبة، Assert ، للتحقق من نتائج تنفيذ التعليمات البرمجية ( التأكيد هو بيان بأن لديك حالة/بيانات معينة في مكان معين). على سبيل المثال، أنت تختبر طريقة من شأنها إنشاء قطة. تقوم بتشغيل طريقة وتحصل على بعض النتائج:

Cat resultOfTest = createCat();

ولكن عليك التأكد من أنه تم إنشاؤه بشكل صحيح، أليس كذلك؟ لذلك، قمت مسبقًا بإنشاء قطة معينة - متوقعة - يدويًا باستخدام المعلمات التي تتوقعها تمامًا من القطة التي تم الحصول عليها من طريقة createCat() . بعد ذلك، يمكنك استخدام فئة التأكيد للتحقق من النتائج:

Assert.assertEquals(resultOfTest, expectedCat);

إذا كانت القطط مختلفة، فسيتم طرح استثناء AssertionError ، والذي يخبرنا أن النتائج المتوقعة لا تتقارب. تحتوي فئة التأكيد على العديد من الطرق المختلفة التي تغطي العديد من مهام التحقق من النتائج المتوقعة. وهنا بعض منها:

• AssurerTrue(<boolean>) - يجب أن تكون القيمة المتوقعة المستلمة كوسيطة صحيحة

• تأكيدFalse(<boolean>) - يجب أن تكون القيمة المتوقعة المستلمة كوسيطة خاطئة

• AssurerNotEquals(<object1>, <object2>) - يجب أن تكون الكائنات التي يتم تلقيها كوسيطات مختلفة عند مقارنتها باستخدام يساوي ( خطأ )

• AssurerThrows(<ClassNameOfException>.class, <exceptionObject>) - من المتوقع أن تكون الوسيطة الثانية استثناءً للفئة المحددة بواسطة الوسيطة الأولى (أي، كقاعدة عامة، بدلاً من الوسيطة الثانية، يتم استدعاء الأسلوب الذي يجب أن يكون رمي استثناء من النوع المطلوب)

خيط

57. تمييز السلسلة في جافا

String هي فئة قياسية في Java، مسؤولة عن تخزين ومعالجة قيم السلسلة (تسلسلات الأحرف)، وهي فئة غير قابلة للتغيير ( كتبت عن غير قابل للتغيير سابقًا )، أي. لا يمكن تغيير بيانات كائنات هذه الفئة بعد الإنشاء. أود أن أشير على الفور إلى أن فئتي StringBuilder و StringBuffer هما فئتان متطابقتان تقريبًا مع الاختلاف الوحيد وهو أن أحدهما مخصص للاستخدام في بيئة متعددة الخيوط (StringBuffer). هذه الفئات مشابهة للسلسلة ، ولكن بخلافها فهي قابلة للتغيير . أي أن الكائنات، بمجرد إنشائها، تسمح بتعديل السلسلة التي تمثلها دون إنشاء كائن جديد. في الواقع، تختلف الأساليب عن أساليب السلسلة القياسية وتهدف إلى تلبية احتياجات تغيير السلسلة (ليس من قبيل الصدفة أن يطلق عليها منشئ). اقرأ المزيد عن String و StringBuffer و StringBuilder في هذه المقالة .

58. ما هي الطرق المختلفة لإنشاء كائن سلسلة؟ أين يتم إنشاؤه؟

الطريقة الأكثر شيوعًا لإنشاء سلسلة هي ببساطة تحديد القيمة التي نحتاجها بين قوسين مزدوجين:

String str = "Hello World!";

يمكنك أيضًا القيام بذلك مباشرةً عبر new :

String str = new String("Hello World!");

يمكنك إنشاء سلسلة تبدأ من مجموعة من الأحرف:

char[] charArr = {'H','e','l','l','o',' ', 'W','o','r','l','d','!'};
String str = new String(charArr);

نتيجة لتشغيل طريقة toString على بعض الكائنات:

String str = someObject.toString();

مثل نتيجة أي طريقة أخرى، تقوم بإرجاع تمثيل سلسلة. على سبيل المثال:

BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
String str =  reader.readLine();

كما تفهم، يمكن أن تكون هناك طرق عديدة جدًا لإنشاء سلسلة. عندما يتم إنشاء كائن سلسلة ، يتم تخزينه في تجمع السلاسل ، والذي سنتحدث عنه بمزيد من التفصيل في أحد الأسئلة أدناه.

59. كيفية مقارنة سلسلتين في جافا وكيفية فرزهما؟

لمقارنة القيم في Java، يتم استخدام علامة يساوي المزدوجة == . إذا أردنا مقارنة بعض القيم البسيطة مثل int فسنستخدمها. لكن هذه الطريقة غير قابلة للتطبيق لمقارنة الكائنات الكاملة. في هذه الحالة، سيكون الأمر مجرد مقارنة بين المراجع - سواء كانت تشير إلى نفس الكائن أم لا. أي أنه عند مقارنة كائنين لهما نفس قيم الحقول الداخلية تمامًا، فإن المقارنة من خلال == ستعطي النتيجة خطأ : على الرغم من تطابق حقول الكائنات، فإن الكائنات نفسها تشغل خلايا ذاكرة مختلفة. والكائنات من فئة السلسلة ، على الرغم من بساطتها الخادعة، لا تزال كائنات. والمقارنة عبر == لا تنطبق عليهم أيضًا (حتى على الرغم من وجود تجمع سلسلة). هنا يتم تشغيل الطريقة القياسية لفئة الكائن - يساوي ، والتي يجب تجاوزها في الفئة حتى تعمل بشكل صحيح (وإلا، فستتم المقارنة افتراضيًا باستخدام == ). تم تجاوزه في فئة String ، لذلك نأخذه ونستخدمه:

String firstStr = "Hello World!";
String secondStr = "Hello World!";
boolean isEquals = firstStr.equals(secondStr);

تحدثنا عن مقارنات المطابقة، والآن دعونا نلقي نظرة على فرز المقارنات. ففي نهاية المطاف، لفرز شيء ما، نحتاج إلى معرفة المبدأ الذي يجب فرزه به. للقيام بذلك، يمكنك استخدام مجموعة مرتبة قياسية - TreeSet . يمكنك قراءة المزيد عن المجموعات المتنوعة في Java في هذه المقالة . تعمل هذه القائمة بناءً على خوارزمية الشجرة ذات اللون الأحمر والأسود وتقوم بفرز المجموعة وفقًا لمبدأ الفرز المحدد. كما قلت سابقًا، عليك أن تفهم كيفية فرز الكائنات من نوع معين. يتم استخدام المقارنات لتعيين طريقة المقارنة للفرز . عادةً ما يلزم تنفيذها للفئات التي تريد فرزها، ولكن في حالة السلسلة، يتم تنفيذها بالفعل. لذلك، نقوم ببساطة بإضافة الصفوف التي نحتاجها إلى TreeSet ، وسوف يقوم بفرزها:

TreeSet<String> sortedSet = new TreeSet<>();
sortedSet.add("B");
sortedSet.add("C");
sortedSet.add("A");
sortedSet.forEach(System.out::println);

إخراج وحدة التحكم:

60. إعطاء خوارزمية لتحويل سلسلة إلى حرف. اكتب الكود المناسب

كما قلت سابقًا، تحتوي كائنات فئة String على الكثير من الأساليب المفيدة المختلفة. واحد من هؤلاء هو toCharArray . تقوم هذه الطريقة بتحويل سلسلة إلى مصفوفة أحرف:

String str = "Hello world";
char[] charArr = str.toCharArray();

بعد ذلك، لدينا مجموعة من الأحرف التي يمكننا استدعاؤها حسب الفهرس:

char firstChar = charArr[0]; // H

61. كيفية تحويل سلسلة إلى مجموعة بايت والعودة؟ اكتب الكود المناسب

على غرار الأسلوب toCharArray ، تحتوي فئة String على أسلوب getBytes الذي يُرجع مصفوفة بايت من السلسلة:

String str = "Hello world";
byte[] byteArr = str.getBytes();
byte firstChar = byteArr[6]; // 119

لقد وصل جزء التحليل اليوم إلى نهايته المنطقية. شكرًا لكم على اهتمامكم!