توی لاراول اینطوری میشه برای Validation Ruleها تست نوشت:

$this->assertFalse(
    (new Age())->passes('age', -6)
);

متد ()passes یه attribute و یه value می‌گیره.
#laravel

می‌فرماید که ما کلاسی داریم که با پول سر و کار داره:

class Converter
{
    public function __construct(float $amount, string $currency) { ... }
}

اما ممکنه که مقادیر غیر مجاز برای این دو پارامتر داده بشه، مثلاً برای amount عددی منفی بیاد یا اینکه برای currency مقدار "ABC" بیاد که واحد پول هیچ کشوری نیست! برای اینکه ولیدیشن رو داخل constructor انجام ندیم، اینهارو به عنوان تایپ مستقلی در میاریم:

class Converter
{
    public function __construct(Amount $amount, Currency $currency) { ... }
}

خیلی خوب شد، اما مثلاً خروجی ما می‌تونه Amount باشه درحالیکه به Currency هم نیاز داریم؛ به یه عبارت دیگه، این دو مقدار به هم ارتباط دارند و نمی‌خواییم جداشون کنیم، از طرفی توی بخش‌های دیگۀ سیستم ممکنه به هرکدومشون به تنهایی نیاز پیدا کنیم، پس هر دو رو داخل تایپ جدیدی به اسم Money می‌ذاریم:

class Converter
{
    public function __construct(Money $money) { ... }
}

و خود Money هم اینطوری ساخته میشه:
class Money
{
public function __construct(Amount $amount, Currency $currency) { ... }
}

مقاله‌ای از مارتین فولر دربارۀ Value Objectها:
https://martinfowler.com/bliki/ValueObject.html

I can do it this way:

http://localhost

And if I want it to be fancy I can do it this way:

http://127.0.0.1

And if I want it to be even fancier:
http://[::1] 😵‍💫😂
#HusseinNasr

امشب فکر می‌کردم که قدیم‌ها هرچی فحش داشتیم، الآن یا تبدیل به شغل شده، یا گرایش! خدا عاقبت مارو به خیر کنه. 🤔

وقتی می‌خوایید بگید «سراپا گوشم»، می‌گید:
I'm all ears!
یا «همه تن چشم‌ام»:
I'm all eyes!
#english

وقتی کسی پروفایلم رو چک می‌کنه... 😔😂
#fun

می‌فرماید که Value Objectها ویژگی‌هایی دارن، از جمله این دو ویژگی:
1. اینکه immutable هستند، قرار نیست تغییرشون بدیم.
2. اینکه یکتا نیستند. بر خلاف entity که برای ذخیره‌سازی و... نیاز داریم identifiable باشه، اینها نیاز نیست که identifiable باشند.

یکی از دلایلی که نویسنده برای این آورده که value objectها بايد immutable باشند.

به اتفاق غیر منتظره‌ای که با تغییردادن پراپرتی acc1 (که یک value object ــه) افتاده توجه کنید.

توی Javanoscript می‎شه این‌طوری آبجکت‌هارو clone کرد. اگه به جای این کار (بهش می‌گیم spread) می‌اومدیم obj1 رو به obj2 اساین می‌کردیم، تغییر obj1 روی obj2 هم اعمال می‌شد چون بهش reference داشت.

Inside an immutable object:

public withPassword (string plainTextPassword): User

Inside a mutable object:
public setPassword (string plainTextPassword): void

جواب درست: false

چرا؟ چون جناب Javanoscript آبجکت‌هارو بر اساس اون value که دارن مقایسه نمی‌کنه، به جای اون به reference دقت می‌کنه؛ برای همین هیچ‌وقت دو آبجکت جدا مساوی نیستند، حتی اگه value یکسان داشته باشند.

به این مثال هم توجه کنید:
const obj1 = { age: 24 }
const obj2 = obj1
console.log(obj1 == obj2) // true

const obj3 = { ...obj1 }
console.log(obj3 == obj1) // false

توی لاراول یه کلاس به اسم Builder داریم که کار ساختن کوئری‌های دیتابیس رو انجام می‌ده.

متد select این کلاس رو ببینیم:

public function select($columns = ['*'])
{
    // 13 lines removed
    return $this;
}

این متد داره this$ رو برمی‌گردونه، و از اینجا حدس می‌زنیم: آها، این یه immutable object ـــه! اما پیاده‌سازی متدهای این کلاس از جمله خود select یه چیز دیگه به ما می‌گن؛ مثلاً روی این کلاس یه پراپرتی به اسم columns داریم که متد select تغییرش می‌ده!

چیزی که باعث گیجی ما شده، اینه که خروجی متدها شبیه immutableهاست (پست ریپلای‌شده رو ببینید)، ولی ساختار آبجکت و رفتار این متد به mutableها شباهت داره! چیزی که باعث گیجی ما شده، اینه که این کلاس می‌خواسته یه راه سرراست در اختیار ما بذاره که هر بار instance این آبجکت رو صدا نزنیم و به صورت زنجیره‌وار از متدها استفاده کنیم.

همیشه آبجکت‌های immutable را ترجیح دهید؛ یعنی آن‌هایی که بعد از ساخته‌‎شدن نمی‌توانند تغییر کنند. اگر واقعاً در شرایطی نیاز داشتید که چیزی را تغییر دهید، ابتدا یک کپی بسازید و بعد تغییرات را روی کپی اعمال کنید.
#ObjectDesignStyleGuide

🧐 A template for methods

[scope] function methodName(type name, ...): void | [return-type]
{
[preconditions checks]
[failure scenarios]
[happy path]
[postcondition checks]
[return void|specific-return-type]
}

#ObjectDesignStyleGuide

به متد شمارۀ یک می‌گیم command method که قراره کاری انجام بده، که اینجا تغییردادن پراپرتیه.
به متد شمارۀ دو می‌گیم query method که برای برگردوندن اطلاعات ازش استفاده کردیم؛ واضحه که return type مشخصی باید داشته باشه، و لازمه که side effect (عوارض جانبی) نداشته باشه.

بشنویم از مارتین فولر که راجع به جداسازی Query/Command methodها افاضه فرموده:
https://martinfowler.com/bliki/CommandQuerySeparation.html

چند تست برای متد زیر لازم داریم تا Code Coverage صد در صد داشته باشیم؟ و چند تست نیاز داریم تا تمام حالت‌های ممکن را پوشش دهیم؟

public function pay($amount): bool
{
    if ($amount <= 0) {
        throw new SomeException('Are you serious?');
    }

    return PaymentService::pay($amount);
}

👍 2 - 2
❤️ 1 - 2
🤩 2 - 3
😁 3 - 3