چند 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

کد سوال بالا

public static int fastExp(int base,int exponential){
if(exponential==0){
return 1;
} else if(exponential==1){
return base;
}
int R = fastExp(base,exponential/2);
if(exponential%2==0){
return R*R;
}
return R*base*R;

}

الگوریتم fast exponential

پیچیدگی زمانی:
O(lgn)

پیچیدگی زمانی الگوریتم معمولی :
O(n)

دسته بندی : Divide and conquer

@this_java

یک api برای اجاره منزل نوشته شده با فریمورک Spring:
استفاده از Jsr 303
Jsr 338(Jpa)
Jwt

@this_java

Websocket با vertx
مثال استفاده از eventbus

مثال استفاده از Spring data jpa