Added section "Getters and Setters" into library (#279)

* Added section "Getters and Setters" into library
* Fixed ambiguous or incorrect remarks
* Added route endpoint

Author: tabuna

public/img/ui/bone.svg

@@ -0,0 +1,28 @@
+@extends('layout')
+@section('title', 'Геттеры и сеттеры')
+@section('description', 'Разрушают инкапсуляцию, увеличивают связанность кода и приводят к процедурному стилю программирования.')
+@section('content')
+
+    <x-header align="align-items-center">
+        <x-slot name="sup">Объектно-ориентированное программирование</x-slot>
+        <x-slot name="title">Геттеры и сеттеры в объектах</x-slot>
+        <x-slot name="description">
+            Разрушают инкапсуляцию, увеличивают связанность кода и приводят к процедурному стилю программирования.
+        </x-slot>
+        <x-slot name="content">
+            <img src="/img/ui/bone.svg" class="img-fluid d-block mx-auto">
+        </x-slot>
+    </x-header>
+
+    @php
+        $sections = collect([
+            'basics',
+            'getters-and-setters',
+            'tell-dont-ask',
+        ])
+            ->map(fn ($file) => \Illuminate\Support\Str::of($file)->start('getters-and-setters/'))
+            ->map(fn ($file) => new \App\Library($file));
+    @endphp
+
+    @include('particles.library-section', ['sections' => $sections])
+@endsection

resources/views/library/getters-and-setters.blade.php

@@ -65,6 +65,7 @@
 Route::view('/library/collection', 'library.collection')->name('library.collection');
 Route::view('/library/solid', 'library.solid')->name('library.solid');
 Route::view('/library/actions', 'library.actions')->name('library.actions');
+Route::view('/library/getters-and-setters', 'library.getters-and-setters')->name('library.getters-and-setters');
 /*
 |--------------------------------------------------------------------------
 | Open Quiz

routes/web.php

@@ -0,0 +1,33 @@
+---
+title: "Основы"
+description: "В программировании существует разные подходы к организации кода."
+---
+
+В программировании существует множество разных подходов к организации кода. Например знакомый со школьной скамьи или
+университета процедурный стиль, когда программа описывается серией последовательных инструкций: «сделай 1, сделай 2,
+сделай 3».
+
+```php
+step1($data);
+step2($data);
+step3($data);
+```
+
+Этот стиль программирования прост в освоении и долгие годы был основным в программировании в C, Pascal и других языках.
+
+Однако в современном PHP и Laravel обычно применяется объектно-ориентированный подход. В котором мы создаём классы,
+инициируем их и используем методы, чтобы управлять поведением объектов. ООП основывается на идее, что данные и поведение
+должны быть объединены в единый «живой» объект. Например, представьте класс `App`:
+
+```php
+$app = new App();
+
+$app->start();
+```
+
+В этом случае мы не указываем пошагово, что необходимо делать, а поручаем объекту выполнить всю необходимую
+инициализацию и запуск (инкапсуляция). Такой подход позволяет скрыть детали реализации и предоставляет лишь интерфейс
+для взаимодействия с объектом.
+
+Но существует чертовски много кода и практик на ООП языках, который является процедурным по своей конструкции. Поэтому
+мы разберем несколько примеров.

storage/library/getters-and-setters/basics.md

@@ -0,0 +1,84 @@
+---
+title: "Глупые объекты рождают процедурные участки кода"
+description: "Объект как контейнер для данных."
+---
+
+Встречается практика, когда один объект используется исключительно как контейнер для данных – он
+не содержит бизнес-логики, а только хранит информацию. Рассмотрим пример:
+
+```php
+class User
+{
+    private string $name;
+    private string $email;
+
+    public function getName(): string
+    {
+        return $this->name;
+    }
+
+    public function setName(string $name): void
+    {
+        $this->name = $name;
+    }
+
+    public function getEmail(): string
+    {
+        return $this->email;
+    }
+
+    public function setEmail(string $email): void
+    {
+        $this->email = $email;
+    }
+}
+```
+
+> {note} Часто такой класс ошибочно называют "Data Transfer Object" (DTO), но это не так. DTO должен быть иммутабельным, а наличие сеттеров нарушает этот принцип.
+
+Здесь объект `User` используется только для хранения данных.
+Дальше эти данные обрабатываются в различных частях приложения. Например:
+
+```php
+// В одном участке кода создаем объект и заполняем его данными
+$user = new User();
+$user->setName('John Doe');
+$user->setEmail('john.doe@example.com');
+
+// В другом участке кода валидируем данные
+$validator = new Validator();
+$validator->validate($user);
+
+// В третьем участке кода отправляем письмо пользователю
+$notification = new WelcomeNotification();
+$notification->send($user->getEmail());
+```
+
+В этом примере мы видим, что объект `User` не обладает собственной логикой – за обработку данных отвечают внешние
+классы, такие как `Validator` и `Mailer`. По сути, вместо использования массива для хранения информации мы применяем
+объект, но бизнес-логика вынесена за его пределы. Это приближает архитектуру к процедурному стилю, где программа состоит
+из набора функций, выполняющих действия над данными.
+
+Аналогичная ситуация наблюдается и в `ORM`, которые не используют подход `Active Record`, например, в `Doctrine`:
+
+```php
+$entityManager = EntityManager::create($connection, $config);
+
+// Создаем объект пользователя
+$user = new User();
+$user->setName("John Doe");
+$user->setEmail("john.doe@example.com");
+
+// Сохраняем в БД
+$entityManager->persist($user);
+$entityManager->flush();
+```
+
+Это противоречит принципам объектно-ориентированного программирования, так как объекты должны быть ответственными за
+свои данные и поведение.
+
+В результате мы получаем систему, где логика распределена между «глупыми» объектами и процедурными участками кода. Это
+затрудняет понимание, тестирование и дальнейшее развитие приложения, так как в нем присутствует неявное разделение
+ответственности.
+
+

storage/library/getters-and-setters/getters-and-setters.md

@@ -0,0 +1,57 @@
+---
+title: "Tell, Don’t Ask"
+description: "Объекты должны выполнять действия, а не только отдавать свои данные"
+---
+
+<mark>Tell, Don’t Ask</mark> – это один из хорошо сформулированных принципов качественного объектно-ориентированного проектирования, который помогает создать чистую и легко поддерживаемую архитектуру. 
+
+> «Не спрашивай объект о данных, чтобы принять решение – скажи объекту, что делать.»
+
+На первый взгляд этот принцип может показаться противоречащим принципу единой ответственности (SRP), но в реальной разработке зачастую приходится делать выбор, какой из принципов важнее в конкретном контексте. Тем не менее, чем больше принципов удается соблюсти одновременно, тем лучше.
+
+Вместо того чтобы создавать «глупый» объект, мы можем инкапсулировать бизнес-логику прямо в объекте или в связанном сервисе. Например, если нам необходимо валидировать и отправить приветственное письмо, можно поручить это объекту или сервису, который знает, как с ним работать. Рассмотрим два варианта:
+
+Вместо того чтобы извлекать данные и проверять их во внешнем коде, объект сам выполняет необходимое действие.
+
+```php
+class User
+{
+    protected string $name;
+    protected string $email;
+
+    private function validate(): bool
+    {
+        $validator = Validator::make([
+            'name'  => $this->name,
+            'email' => $this->email,
+        ], [
+            'name'  => 'required',
+            'email' => 'required|email',
+        ]);
+
+        return $validator->passes()
+    }
+
+    public function register(): void
+    {
+        $this->validate();
+
+        // Сохранение пользователя в БД...
+
+        $this->notify(WelcomeNotification::class);
+    }
+}
+
+$user = new User(
+    name: "John Doe",
+    email: "john.doe@example.com"
+);
+
+$user->register();
+```
+
+Здесь объект сам выполняет проверку и отправляет уведомление, а не предоставляет данные для обработки извне.
+
+> {tip} К тому же принцип **Tell, Don’t Ask** хорошо сочетается с **Законом Деметры** (*Law of Demeter, LoD*), который также способствует созданию более устойчивых и независимых объектов.
+
+Можно узнать больше из работ [Мартина Фаулера](https://martinfowler.com/bliki/TellDontAsk.html), [Аллена Холуба](https://www.infoworld.com/article/2161183/why-getter-and-setter-methods-are-evil.html) и [Егора Бугаенко](https://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html).