Level 14
the "classic" way would be a getAddressAttribute() method that is accessible via ->address.
The only difference/advantage of the new way that I see comes when defining getters and setters for an attribute in the same place.
Mar 5, 2024
7
Level 1
Advantages of defining accessor methods
Take a look at these two methods:
// Laravel's way of defining an Attribute
protected function address(): Attribute
{
return Attribute::make(
get: fn (mixed $value, array $attributes) => new Address(
$attributes['address_line_one'],
$attributes['address_line_two'],
),
);
}
// The classic way (like in other OO languages), that probably everyone knows
public function getAddress(): Address
{
return new Address(
$this->address_line_one,
$this->address_line_two,
);
}
Both are doing basically the same thing. The first one is accessable with $model->address, while the second one is callable through $model->getAddress().
I know Laravel's Attribute comes with caching if enabled. I currently see only the caching as an advantage and that this is accessable like an actual model attribute.
Any other advantages that I can't think of right now?
Or tu put it another way: Anything against a classic getAddress() method here?
Thanks for your ideas!
Level 1
@krisi_gjika Sorry, I didn't meant the classic Laravel's way, but the classic way in (probably all) other object oriented programming languages. I updated my post to make it more clear.
Level 104
@menglisch generally I prefer Accessors over getter methods for consistency.
Whenever you use an Accessor to transform an attribute from the raw database data (like the doc's example) you ensure that the $model->property will always return the transformed data. If instead you write a getter method; there is nothing to ensure you/other devs use the correct $model->getProperty() over the raw $model->property.
1 like
Level 1
@tykus Thanks! I haven't thought of that perspective yet. I'm still torn between those two perspective. On the one hand, I want consistency. Definetly a very important point. On the other hand, I want to make clear that the address is is not a database field and explicit display that it is a generated/calculated value.
Level 104
@menglisch I don't think that you're wrong to think like that. In the past, getters were much more common, but eventually I embraced the magic
Level 14
@menglisch you don't have to use one over the other. Use getters for not DB fields like a ->getFullNameAttribute() joining first and last names and attributes for DB fields ex. an encrypted field that need to be decrypted and encrypted on the fly when updating it.
I don't really like the new syntax, but that's a personal choice
Level 104
@krisi_gjika I think you are missing the point about traditional getter methods (i.e. for encapsulation, not Laravel's previous Accessor syntax)
1 like
Please or to participate in this conversation.