یک کتاب عالی برای فهمیدن 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

مقایسه ی Type wrapper ها و primitive type ها از نظر Performance

public static void main(String[] args) {
int repeats = 40000000;
long time;

time = System.currentTimeMillis();
long counterA = 0L;
for (int i = 0; i < repeats; i++) {
counterA = counterA + 4L;
}
System.out.println(counterA + " A: " + (System.currentTimeMillis() - time) + " ms");

time = System.currentTimeMillis();
Long counterB = 0L;
for (int i = 0; i < repeats; i++) {
counterB = counterB + 4L;
}
System.out.println(counterB + " B: " + (System.currentTimeMillis() - time) + " ms");
}
خروجی :


160000000 A: 0 ms
160000000 B: 284 ms


نتایج ممکن است با توجه به پردازنده, نسخه ی جاوا و... شما متفاوت باشد

دلیل نتایج فوق واضح است :
Type wrapper ها باید در heap
ذخیره شوند

و ساخت اشیا در heap هزینه ی بیشتری نسبت به stack دارد

بیاید کد بالا را بار دیگر , و اینبار به جای استفاده از autoboxing , از valueOf استفاده کنیم:
public static void main(String[] args) {
int repeats = 40000000;
long time;

time = System.currentTimeMillis();
long counterA = 0L;
for (int i = 0; i < repeats; i++) {
counterA = counterA + 4L;
}
System.out.println(counterA + " A: " + (System.currentTimeMillis() - time) + " ms");

time = System.currentTimeMillis();
Long counterB = Long.valueOf(0L);
for (int i = 0; i < repeats; i++) {
counterB = counterB + 4L;
}
System.out.println(counterB + " B: " + (System.currentTimeMillis() - time) + " ms");
}

خروجی :

160000000 A: 0 ms
160000000 B: 237 ms



دلیل این امر چیست؟

تعریف type wrapper به صورت بالا از نظر بایت کد تفاوت چندانی با تعریف به صورت زیر ندارد:
Long l = new Long(0L);


این کد همیشه یک شی جدید از Long با مقدار 0 ایجاد میکند . اما جاوا بصورت پیشفرض تعدادی از مقادیر پر استفاده را از اول اجرای برنامه ذخیره میکند تا تفاوت سرعت فاحشی میان primitive type و type wrapper بوجود نیاید :

@IntrinsicCandidate
public static Long valueOf(long l) {
final int offset = 128;
if (l >= -128 && l <= 127) { // will cache
return LongCache.cache[(int)l + offset];
}
return new Long(l);
}

با مشاهده ی متد valueOf (این متد را تحت عنوان static factory method میشناسیم)میتوان دید مقادیر -128 تا 127 کش شده اند .
و خارج از این محدوده , تفاوتی میان
Long l = 128L;
و
Long l = Long.valueOf(128L);
وجود ندارد.(البته لازم به ذکر است احتمالا اگر در برنامه ی شما یک عدد زیاد استفاده شود ان عدد نیز کش میشود)


البته استفاده از سازنده ی Long از نسخه ی 9 به بعد منسوخ شده و توسط جاوا پیشنهاد شده صرفا متد valueOf برای استفاده از Type wrapper ها به کار برده شود.

Java Roadmap