پاسخ صحیح گزینه ی سه

فرض کنید داشته باشیم
byte b =50;
byte c = 100;
byte a =40;

int d= a*b/c;
واضح است که محدوده ی محاسبات از محدوده ی بایت فراتر می‌رود راه حل جاوا برای جلوگیری از این مسئله این است که به هنگام محاسبات ریاضی داده هایbyte,short, character به صورت خودکار به int ارتقا داده میشوند بنابراین a*b بصورت integer محاسبه میگردد و نه byte. بنابراین نتیجه ی عبارت ۲۰۰۰ است و عملیات۵۰×۴۰ با توجه به اینکه هردو از نوع byteهستند به درستی انجام می‌پذیرد.

علی رغم مزایای ارتقای خودکار نوع در هنگام محاسبات ریاضی ، میتواند منجر به چنین خطاهای گیج کننده ای در زمان کامپایل شود.

در مثال بالا ۵۰×۲ به int تبدیل میشود بنابراین بدون casting نمی‌تواند درون byte قرار گیرد

@this_java

تفاوت کلید واژه ی super و extends در generics چیست؟

راس C2 از درخت فوق را مد نظر بگیرید

فرض کنید میخواهیم لیستی داشته باشیم که فقط بتواند مقادیری از نوع راس C2 فرزندان آن (کلاس هایی که از C2 مشتق شده اند به آن فلش وارد کرده اند برای مثال منظور از مقادیری از نوع C2 خود C2 و D1 و E2 و... میباشد)

در این صورت از extends استفاده میکنیم:

List<? extends C2> list;

بدین شکل میتوانیم مقادیری از نوع c2 و زیر کلاس های آن را در این لیست ذخیره کنیم

حال فرض کنید میخواهیم مقادیری از نوع C2 و سوپر کلاس های آنرا ذخیره کنیم(مانند B3 و B2 و A4 و...)

در این صورت از super استفاده میکنیم:

List<? super C2> list;

درواقع هر کلاسی که میخواهیم به این لیست اضافه کنیم یا باید از جنس C2 باشد یا از جنس پدران C2

کاربرد این دو کجاست؟

برای مثال متد copy از کلاس Collections را بررسی میکنیم:

public class Collections { 
  public static <T> void copy(List<? super T> dest, List<? extends T> src) {
      for (int i = 0; i < src.size(); i++) 
        dest.set(i, src.get(i)); 
  } 
}

@this_java

پر واضح است که لیست مبدا میتواند T و همچنین زیر کلاس های آنرا داشته باشد (لیست مبدا نوعی از ان باشد) اما لیست مقصد فقط میتواند نوع T و سوپر کلاس های آنرا داشته باشد (لیست مقصد میتواند از نوع T یا سوپر کلاس آن باشد)

چراکه بر طبق قواعد شی گرایی جاوا یک کلاس میتواند در متغیری از همان نوع و یا نوع کلاس پدر نگهداری شود(اگر لیست مقصد هم extends داشت باید عملیات کست انجام میشد تا داده های مبدا بتوانند به پدران خود تبدیل شوند)

@this_java

@this_java

این پروژه ی جاوا اف ایکسی است و از دیتابیسmysql و تکنولوژی hibernate استفاده شده است

جنریک ها در جاوا

آموزش کامل جنریک در جاوا

@this_java

There are only two hard things in Computer Science: cache invalidation and naming things.
– Phil Karlton


Java code conventions can be found here:
https://www.oracle.com/technetwork/java/codeconventions-150003.pdf
https://google.github.io/styleguide/javaguide.html

یک کتاب عالی برای فهمیدن Best Practice ها در جاوا

برشی از کتاب Clean code عمو باب

مقایسه ی زمان اجرای محاسبه ی جمله ی n ام دنباله ی فیبوناچی به روش بازگشتی با غیر بازگشتی

خروجی کد فوق چیست؟
👍به معنای 42
👎به معنای 0

کسایی که میگن صفر دلیلش رو پیوی بگن ببینم رو چه حسابی صفر بدست اوردن😄

خب دوستان خروجی کد میشه صفر همانطور که خیلیاتون این رو زدید
ولی چرا؟
اگر کتاب دایتل رو خونده باشید ..در یک بخش گفته شده که هیچوقت در سازنده ی یک کلاس متدی فراخوانی نکنید که قابل override شدن باشه
به چه دلیل ؟

میدونیم که اولین خط از سازنده ی کلاس فرزند سازنده ی کلاس پدر فراخوانی میشه
اگر بنا بر این باشه که سازنده ی کلاس پدر متدی فراخوانی کنه که در کلاس فرزند بازنویسی شده
و حالا اون متد مقادیری داشته باشه که در سازنده ی کلاس فرزند مقدار دهی بشن
قبل از مقدار دهی شدن اونها
سازنده ی کلاس پدر فراخوانی میشه
و اون هم متد رو فراخوانی می‌کنه
پس مقادیر پیشفرض هنوز ست نشدن
و این مشکل ساز میشه

Prefer self-explanatory code instead of comments

Don't comments bad code - rewrite it.

- Brian W. Kernighan, The Elements of Programming Style.


• Comments are not substitute for bad code.

• Explain it through code.

• Java is a programming language and should express itself.

• The more self-explanatory the code is, the less you need to comment it.

• Treat the comment as a danger signal.

• Comment why not what!


Rules for commenting:

Primary rule : Comments are for things that can not be expressed in code.

Redundancy rule: Comments which repeat the meaning of code must be deleted.

Single truth rule : If the comment says what the code could say, then the code must change to make the comment redundant.



https://blog.faradars.org/weird-programming-principles/


@this_java

چند software design principleمعروف :

Code must be KISS,DRY and YAGNI.

KISS: Keep it simple stupid.

به قول یکی از بزرگان : زبان های برنامه نویسی برای فهم انسان هستند .کامپیوتر ها فقط صفر و یک میفهمند

تا جای ممکن کد را ساده بنویسید...حتی اگر به قیمت کاهش پرفورمنس و افزایش خط کد های برنامه تمام شود (این جمله به معنای در نظر نگرفتن پرفورمنس نیست).

DRY: Don't repeat yourself

یک کد را به دلیل تنبلی در جاهای مختلف کپی و تکرار نکنید..به جای آن یک تابع ایجاد کنید و کد را فقط یکباربنویسید و آنرا در جاهای مورد نیاز فراخوانی کنید

YAGNI: You aren't gonna need it

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

منبع : Clean code

@thia_java

Integer i = 128;
Integer b = 128;
Boolean b2= (i==b);

چرامقدار b2 در کد بالا false میباشد؟

همانند مکانیزم String pool. جاوا برای اعداد نیز مکانیزمی به نام Integer pool دارد و اعداد در بازه ی -۱۲۸ تا ۱۲۷ را کش میکند و اگر دوتا Integer به یکی از مقادیر در این بازه اشاره کنند درواقع هردو به یک خانه در حافظه اشاره میکنند .
به این دلیل خانه های حافظه ی آنها یکسان است
اما اگر به مقداری خارج از محدوده ی بالا اشاره کنند .. دیگر خانه های آنها یکسان نخواهد بود درنتیجه b2==false خواهد بود.


پس :
Integer i = 127;
Integer b = 127;
Boolean b2= (i==b);

در کد فوق b2 ترو خواهد بود

توجه کنید که اگر داشته باشیم :

Integer i = new Integer(128);
Integer b = 128;
Boolean b2= (i==b);

بی۲ فالس خواهد بود زیرا با new کردن ما مکانیزم کش را نادیده می‌گیریم.



این نکته قابل ذکر است که در primitive type ها این داستان های کشینگ را نداریم و در برابری بین دو int صرفا مقدار آن دو مقایسه میشود پس :

Integer i = 128;
Integer b = 128;
Boolean b2= (i==b.intValue());

در کد فوق b2 نیز true خواهد بود (با اینکه i و b به یک مکان در حافظه اشاره نمی‌کنند اما چون آنباکس میشوند صرفا مقدار آنها چک میشود)
@this_java

https://vrgl.ir/lhFAQ

استاتیک فکتوری متد در جاوا

@this_java

Don’t make any instance or class variable public without good reason. Often, instance
variables don’t need to be explicitly set or gotten—often that happens as a side effect of
method calls.

-Java code conventions