Категория: Common programming concepts

Според мен това е design принцип, много подобен на Inversion of Control, но в по-общ смисъл. Демек, IoC е по-конкретен само за OOP, SoC e по-общ…

Принцип при който чрез разделяне на функционалността на дадена програма по такъв начин, че отделните и компоненти (класове, пакети, библиотеки…) да са както максимално концентрирани само върху своите задачи и предназначения (single responsibility) и да имат максимално тясна специализация.

„In computer science, separation of concerns (SoC) is a design principle for separating a computer program into distinct sections such that each section addresses a separate concern.“

Въпросното „разделяне на задачи“ може да е на различен принцип. Това може да са задачи свързани само с визуалната част на дадената програма, както например HTML и CSS си разделят отговорностите, едното за структурата и семантиката, а другото – за чисто визуалната част на дадената страница. Затова в началото казахме, че „SoC e по-общ“.

Може да е чисто backend разделяне на програмата – един клас да отговаря за валидациите, друг за работа с базата данни…

Или още по-генерално как да се структурира програмата. MVC например е типичен пример за SoC – програмата е разделена на бизнес модел, презентационна част и т.н…

Цитатите са от известната книга „Design Patterns: Elements of Reusable Object-Oriented Software“

Object types and interfaces

A type is a name used to denote a particular interface. We speak of an object as having the type „Window“ if it accepts all requests for the operations defined in the interface named „Window.“ An object may have many types, and widely different objects can share a type. Part of an object’s interface may be characterized by one type, and other parts by other types. Two objects of the same type need only share parts of their interfaces. Interfaces can contain other interfaces as subsets. We say that a type is a subtype of another if its interface contains the interface of its supertype. Often we speak of a subtype inheriting the interface of its supertype.

Interfaces are fundamental in object-oriented systems. Objects are known only through their interfaces. There is no way to know anything about an object or to ask it to do anything without going through its interface. An object’s interface says nothing about its implementation – different objects are free to implement requests differently. That means two objects having completely different implementations can have identical interfaces.

Видиш ли интерфейсът на даден клас, виждаш какво той може да прави, видиш ли самият клас (имплементация), виждаш как го прави.

Dynamic binding

When a request is sent to an object (calling some of its methods), the particular operation that’s performed, depends on both the request and the receiving object. Different objects that support identical requests may have different implementations of the operations that fulfill these requests (или казано иначе, имплементират по различен начин различни интерфейси). The run-time association of a request to an object and one of its operations is known as dynamic binding.

Dynamic binding means that issuing a request (calling а object method) doesn’t commit you to a particular implementation until run-time. Consequently, you can write programs that expect an object with a particular interface, knowing that any object that has the correct interface will accept the request.

Polymorphism

Dynamic binding lets you substitute objects that have identical interfaces for other, at run-time. This substitutability is known as polymorphism, and it’s a key concept in object-oriented systems.

Kакво е т.н. „интерфейс“?
Какво даден клас може да прави чрез методите си?
Да де, но не само. Интерфейс MagareInterface задължава имплементиращите го класове да могат да ревът и да хвърлят къчове.
Но идеята е интерфейс MagareInterface да задължи дадените методи на имплементиращи даденият интерфейс, да имат зададеният от интерфейсът сигнъчър, демек, да се знае какво се иска като типове параметри, както и като тип върнат резултат.

Classes that aren’t abstract are called concrete classes.

Object’s class vs. Object’s type

It’s important to understand the difference between an object’s class and its type. An object’s class defines how the object is implemented. The class defines the object’s internal state and the implementation of its operations. In contrast, an object’s type only refers to its interface – the set of requests to which it can respond. An object can have many types, and objects of different classes can have the same type.

Демек, класът на даден обект представлява самата му дефиниция. Това е все едно конституцията и законите на една държава, според които тя функционира.

Типът на даденият обект задава неговият интерфейс, тоест как той (обектът) комуникира с останалият свят, тоест какви заявки може да приема и обслужва. Типът е така да се каже „външната политика“ на гореспоменатата държава.

„… and objects of different classes can have the same type.“ – много държави могат да имат обща външна политика най-общо казано, като например членство в едни и същи организации и т.н…

Разбира се, двете понятия за близко свързани помежду си.
Of course, there’s a close relationship between class and type. Because a class defines the operations an object can perform, it also defines the object’s type. When we say that an object is an instance of a class, we imply that the object supports the interface defined by the class.
Демек, понеже класът задава конституцията, то индиректно той задава и външната политика. И щом кажем, че обектът е от клас ЕдикойСи (демек има конституция ЕдикойСи), това по подразбиране значи, че той има и съответната външна политика.

Като пишеш един клас, винаги мислиш първо „какво трябва да може да прави“, и тогава, на тази база пишеш конкретната имплементация. Демек, класът задава конституцията но според това какъв трябва да е типът – външната политика. Явно това се има предвид с принципът „Program to an interface, not an implementation.“

Inheritance vs. Composition

The two most common techniques for reusing functionality in object-oriented systems are class inheritance and object composition. Subclassing is often referred to as white-box reuse. The term „white-box“ refers to visibility.
Демек, класът който наследяваш е напълно известен за теб, като негов наследник, затова явно се има предвид, че е „бяла кутия“. Наследяваш всичко, без разбира се private’s.

Object composition is an alternative to class inheritance. Here, new functionality is obtained by assembling or composing objects to get more complex functionality. This style of reuse is called black-box reuse, because no internal details of objects are visible. Objects appear only as „black boxes.“
За разлика наследяването, тук другите обекти биват „инджектнати“ като пропъртита. Които обекти могат и да не са ни известни като структура и т.н., дадени са ни да им използваме public пропъртитата и методите, демек знаем за тях само толкова, колкото трябва да знаем. Те за нас са като „черна кутия“.

Inheritance and composition each have their advantages and disadvantages. Class inheritance is defined statically at compile-time and is straightforward to use, since it’s supported directly by the programming language. Class inheritance also makes it easier to modify the implementation being reused.
Демек, така може по-лесно да се променя функционалността на наследяваният клас. Как? Чрез overriding.

But class inheritance has some disadvantages too. First, you can’t change the implementations inherited from parent classes at run-time, because inheritance is defined at compile-time. But you can in compile time.
Second, and generally worse, parent classes often define at least part of their subclasses physical representation. Because inheritance exposes a subclass to details of its parent’s implementation, it’s often said that „inheritance breaks encapsulation“. The implementation of a subclass becomes so bound up with the implementation of its parent class that any change in the parent’s implementation will force the subclass to change.
Демек, ако прекаляваме с наследяването, може да достигнем до огромна и тежка „пирамида“ от класове, губейки капсулираност и гъвкавост.
Your classes and class hierarchies will remain small and will be less likely to grow into unmanageable monsters.

Object composition is defined dynamically at run-time through objects acquiring references to other objects. Composition requires objects to respect each others’ interfaces, which in turn requires carefully designed interfaces that don’t stop you from using one object with many others. But there is a payoff. Because objects are accessed solely through their interfaces, we don’t break encapsulation. Any object can be replaced at run-time by another as long as it has the same type. Moreover, because an object’s implementation will be written in terms of object interfaces, there are substantially fewer implementation dependencies.

Демек, трудността тук е да използваме инджектнатите обекти правилно, според интерфейсите им, тоест и самите интерфейси трябва да са добре направени. Предимството на composition е, че не се нарушава капсулацията, всеки обект е само за себе си, и най-вече – взаимозаменяемостта им на база че са от общ тип (имат общ интерфейс). Демек, не „разширяваш“ даден клас чрез наследяване, а подаваш готов обект от даденият клас, на друг обект.

That leads us to our second principle of object-oriented design: Favor object composition over class inheritance.

Delegation

Това е принцип, който използва composition, на практика постига същият ефект като inheritance но го прави не като наследява даден клас и използва неговите методи и пропъртита с this или self, а получава готов обект като параметър и използва неговите такива.

Relating Run-Time and Compile-Time Structures

An object-oriented program is a run-time structure, that often bears little resemblance to its code structure. The code structure is frozen at compile-time; it consists of classes in fixed inheritance relationships. A program’s run-time structure consists of rapidly changing networks of communicating objects. In fact, the two structures are largely independent. Trying to understand one from the other is like trying to understand the dynamism of living ecosystems from the static taxonomy of plants and animals, and vice versa.
Демек, структурата от класове е все едно енциклопедията с растения и животни, но самата програма е вече съвкупност от динамични обекти, които комуникират помежду си, зависят един от друг…, и това е все едно една жива екосистема, една гора например.

A design that doesn’t take change into account risks major redesign in the future.

Първо, важно е да споменем две понятия и да разбере разликата между тях –
Design Principle и Design Pattern.

Design Principle е така да се каже по-общото. Това са общи, добри практики, които е добре да се спазват, независимо от езика за програмиране и не предлагат конкретни начини на приложение. Това са чисто абстракни принципи.

Един пример за design principles са например SOLID принципите.

Design patterns са вече по-конкретни решения на различни проблеми от ООП, но спазвайки design principles. Например, искаме от даден клас да имаме само един обект – използваме Singleton design pattern, ето това е една design pattern.

Design patterns са отново независими от езикът за програмиране както design principles, но са по-скоро практическото приложение на design principles.

Също, когато прилагаме или създаваме design pattern, трябва винаги да внимаваме да не нарушаваме design principle. По принцип един клас винаги се пише така, че да има една „основна отговорност“, заради която бива писан, и отделно – различни, така да се каже „помощни“ функционалности, като например логери, емайл, спелчекъри…
За такива е идеята – да бъдат отделени като отделни класове и да бъдат инджектвани.

Литература:

https://www.tutorialsteacher.com/articles/difference-between-design-principle-and-design-pattern

Dependency Injection (DI)

Когато можем да инджектваме даден обект в друг обект.

Така се реализира design принципът Inversion of Control, демек – на практика реализиране на Single Responsibility SOLID принципът.

Types of Dependency Injection

1. Constructor Injection – през конструктора, демек инджектваният обект се подава oще на конструктора на основният клас и се сетва като пропръти още при инстанциране на основният обект.
2. Property (Setter) Injection – идеята е подобна на горната, пак инджектваният обект да бъде сетнат на клас пропърти, но не през конструктора, а през сетър.
3. Method Injection – тук имаме ситуация, подобна на Property (Setter) Injection но с разликата, че основният клас имплементира интерфейс, който го задължава (него, основният) да има метод, който да играе ролята на сетър, и по този начин задължава основният клас да приеме даден обект.
   Например клас Car имплементира интерфейс EngineMountable, в който има метод engine() и по този начин класът Car e длъжен да има инджектнат обект за двигател.
   Добър въпрос би бил, ако Car наследява например абсклас, не може ли в него да е изнесен абстрактен сетер/сетери, които да играят същата роля, тоест вместо интерфейс да имаме абсклас.
   Не съм съвсем наясно с идеята на този тип injection, признавам си. Може би идеята е да се зададе някакъв централизиран начин за инджектване на обекти, ако имаме абсклас, или вероятно ако е интерфейс, да задължи имплементиращите обекти да имат такива „entry points“ за инджектване на обекти…

Inversion of Control (IoC)

Inversion of Control (IoC) е desing principle, която използва DI, при който идеята е части от цялостната функционалност на даден клас, да се „разхвърля“ или разпредели по други класове, с цел да се спази SOLID Single Responsibility Principle и основният клас да бъде олекотен, и след това когато ни трябват тези „разхвърляни“ функционалности, обекти на тези класове да бъдат инджектвани в основният клас.

Taка се постига и high cohesion вътре в класа както и low coupling между отделните класове.

Dependency Inversion Principle (DIP)

Dependency Inversion Principle (DIP) е SOLID принцип, нещо като продължение или разширение на IoC, в смисъл такъв, че повелява основният клас, в който ще инджектваме обектите на класовете, които сме „разхвърляли“, да може да приема като входни параметри не обекти от конкретен клас, а от различни класове, които обаче екстендват или имплементират даден абсклас или интерфейс.
Демек, „дай ми нещо, с което да отвинтя тази гайка, а не конкретен гаечен ключ“…

Идеята и на двата принципа е да се постигне максимално т.н. „loose coupling“ и максимална кохезия вътре в класа. Припомнете си статията „Cohesion and Coupling“.
Но работата е е там, че само с прилагане на IoC не става, демек само IoC не стига за да се постигне това.

Тоест, основният клас сякаш казва предварително: „не искам конкретна функционалност и обект от конкретен клас, давайте ми обекти, които по принцип ще ми свършат работата“, демек имплементиращи даден интерфейс.

Taка постигаме „high-level modules should not depend on low-level modules“.

Защо?
Защото в случая, high-level модулът при нас е основният клас, а low-level са тези, които му инджектваме, които вършат някаква по-конкретна и специфична работа, тоест са по-ниско в нивото на абстракция.
И основният става по-малко зависим от инджектваните, защото може да приема по-широк диапазон от обекти, а не конкретно само от един клас.

Пример: ти си основният клас и искаш да си викнеш (инджектнеш) майстор да ти смени водомера.
Кога си по-малко зависим (бидейки high-level module) от майстора (който е low-level module)? Ако трябва да можеш да викаш само един конкретен майстор или когато можеш да извикаш всеки майстор, стига да имплементира VodoprovodchikInterface?

Общото между тях?

Общото между IoC и DIP е целта – да се намали зависимостта между отделните класове. Например, да не се създава обект от един клас вътре в друг клас, защото така твърдо свързваме двата класа и единият вече не може без другият, конкретно „другият“, то е ясно, че все някакъв обкет трябва да му инджектнеш, освен ако не си му задал default стойност null.

Демек, когато инджектваме обект, да не очакваме параметърът през който го инджектваме да е от конкретен клас, а да е по-общо – от конкретен интерфейс. Така казваме, че инджектваме не конкретна функционалност, а който по принцип прави това, което ни трябва. Без задължително да е обект от този конкретен клас.

Your code gets decoupled so you can easily exchange implementations of an interface with alternative implementations.

Разликата между тях?

Разликата е, че DIP e по-скоро продължение, надстройка на IoC. Демек, IoC повелчва функционалността на един клас да се „разхвърля“ на под-класове, а DIP повелява това разхвърляне да стане така, че „разхвърляният“ клас да може да приема не конкретни функционалноти, а функционалности по принцип.

Литература:

https://www.tutorialsteacher.com/ioc/introduction

https://www.tutorialsteacher.com/ioc/dependency-inversion-principle

https://www.tutorialsteacher.com/ioc/dependency-injection

Един добър пример за loose coupling е например, ако хвърля топка към някого за да я хване. Интересува ме той да я хване, не ми трябва да знам на колко години е, какво е закусвал тази сутрин и т.н… Щом просто свършим работата, колкото и по-малко да знаем един за друг, ето това е loose coupling.

Един пример за tight coupling и даже по-скоро за rigid and fragile код:

class CustomerRepository
{
    private Database $database;     

    public function __construct(Database $database)
    {
        $this->database = $database;
    }

    public function Add(string $tableName, string $customerName) : void
    {
        $this->database->AddRow('John Doe', $customerName);
    }
}

class Database
{
    public function AddRow(string $table, string $value) : void 
    {
        //...
    } 
}

Показаният код е реално напълно редовен, но проблемът може да се види в перспектива, защото ако променим нещо в AddRow() методът на класа Database, това би счупило използването му в CustomerRepository->Add().
Каквото и да било, поредноста на аргументите, типовете на съответните им параметри…

Демек, хвърлям ти топката но дали ще я хванеш…
За да съм сигурен, че ще я хванеш, ще те задължа да имаш съответният метод, със съответният signature.

Добър пример за това как да превърнем горният пример от tight coupled в loose coupled, би бил например да задължим с интерфейс методът AddRow на класа Database да спазва зададен signature.

class CustomerRepository
{
    private IDatabase $database;     

    public function __construct(IDatabase $database)
    {
        $this->database = $database;
    }

    public function Add(string $tableName, string $customerName) : void
    {
        $this->database->AddRow('John Doe', $customerName);
    }
}

interface IDatabase
{
    public function AddRow(string $table, string $value) : void;
}

class Database implements IDatabase
{
    public function AddRow(string $table, string $value) : void 
    {
        //...
    }
}

Можем да си направим извод, че loose coupling не значи непременно по-голяма либералност, а както се вижда в случая – даже обратното. По-скоро стандартизация, защото така премахваме опасността от различни разновидности (по signature например) на методът AddRow()

Демек, от Add() на CustomerRepository викаме директно AddRow() на Database, но той е длъжен да спазва сигнъчъра на интерфейса IDatabase. Като с цел взаимозаменяемост, той може да има различни имплементации.

Друг пример за това как можем да опростяваме нещата и да ги направим по-гъвкави и взаимозаменяеми.
Например имаме близки като функционалност неща, и за отделните от тях правим отделни, независими класове и съответно, викаме когато който ни трябва.
Вместо това можем пак да имаме отделни класове, но имплементиращи общ интерфейс.

class DiscOperations
{
    public function doDiscWrite(string $data) : bool
    {
        //...
    }
}

class DVDOperations
{
    public function doDVDWrite(string $data) : bool
    {
        //...
    }
}

if (WRITE2DISC) {
    (new DiscOperations)->doDiscWrite($someData);
} else {
    (new DVDOperations)->doDVDWrite($someData);
}

Не би ли по-унифицирано ако например…

interface StorageOperations
{
    public function write(string $data) : bool;
}

class DiscOperations implements StorageOperations
{
    public function write(string $data) : bool
    {
        //...
    } 
} 

class DVDOperations implements StorageOperations
{
    public function write(string $data) : bool
    {
        //...
    }
}

$operator = WRITE2DISC ? new DiscOperations : new DVDOperations;

$operator->write($someData);

Защо? Защото най-малкото можем да си напишем много подобни Оператори, който ще са лесно заменими.

Association – чисто семантична връзка от например тип HAS-A, например доктор има пациенти и т.н… Програмно може например да се реализира като един клас Доктор има едно или повече пропъртита – обекти от клас Пациент.

Dependency – тук имаме директна зависимост между различни елементи, които не могат да съществуват един без друг. Например наследяване на класове, имплементиране на интерфейси… Този тип отношение може да се раздели на две: specification и generalization.

Aggregation – тук имаме отношение на отделни елементи, които в случая са част от дадена цялостна система, но също така могат и да съществуват свободно и извън нея (системата). Добър пример – птица и ято. Ятото се състои от птици, но отделните птици са си птици и без ятото. Или държави, участващи в дадена международна организация като например Европейски Съюз. Всяка може да съществъва сама по себе си.

Има и разновидност на aggregation наречена Acquaintance – Acquaintance is a weaker relationship than aggregation and suggests much looser coupling between objects.

Composition – отношение parent – child, като например Orders – OrderItems. Децата не могат да съществуват и нямат смисъл без родителя. Изчезне ли едното, изчезва(т) и дугото(другите). Добър пример – стаи и сграда. Ако разрушим сградата, няма как да имаме нейните стаи.

Друга важна концепция е т.н. Multiplicity – концепция, която допълва семантичните зависимости между отделните обекти в дадената система, с количествени характеристики. Това означава, че можем допълнително да опишем и количествените ограничения върху дадените семантични отношения.

Литература:

https://www.uml-diagrams.org/

https://www.guru99.com/uml-relationships-with-example.html

http://10minbasics.com/uml-essentials-in-10-minutes/

Има се предвид, че клоужърите и ламбдите имайки свой скоуп на променливите, могат да извършват т.н. „data hiding“, тоест да „скриват“ и капсулират информацията от околният свят в себе си.

Aко погледнем следният пример, ще видим че даденият клоужър bloa() може да има свои, частни променливи, които не са достъпни отвън.

<?php
$patapan = function(string $s): string {
    return strtoupper($s);
};

$bloa = function($a) use ($patapan): string {
    $prom1 = 'Super!';
    return $patapan($a);
};

$strings = ["apple", "orange", "banana", "coconut"];
$upprs = array_map($bloa, $strings);

var_dump($upprs);  // Dumps the uppercased array
var_dump($prom1);  // Undefined variable $prom1 in…
echo $patapan('Good question');  // GOOD QUESTION

Какво излиза на практика? Че closures и lambdas си приличат с обектите, по това, че предлагат свой скоуп и правят data hiding. Moже би затова се казва, че са „the poor man objects“.

There are four common ways of implementing the lazy load design pattern:

1. Lazy initialization (synonym for Lazy instantiation)
2. Virtual proxy
3. Ghost
4. Value holder

1. Lazy initialization

Чак когато инстанция на даден обект ни потрябва, тогава го инстанцираме.

2. Virtual proxy

Virtual Proxy is an object with the same interface as the real object. The first time one of its methods are called it loads the real object and then delegates.

Създаваме 2 обекта, от 2 отделни класа, имплементиращи 1 общ интерфейс.
Когато извикаме някой метод от ПЪРВИЯ обект, той създава обект от ВТОРИЯ клас, присвоява го на пропърти от ПЪРВИЯТ, и ОТ ТУК НАТАТЪК каквото искаме да достъпим от ВТОРИЯ, викаме („минаваме“) през ПЪРВИЯ.

A virtual proxy object shares an interface with the „real“ object. The first time a property of the virtual proxy is accessed, the real object gets initialized. From that point on, accessing properties of the virtual object returns the corresponding property of the real object.

Явно идеята е ако оригиналният обект е ресурсоемък или времеемък, но трябва да го инициализираме по една или друга причина, да не го инициализираме него, а някакъв друг, виртуален, който има същият интерфейс, и чак когато ни трябва оригиналът, тогава във виртуалният създаваме оригиналният, и с делегиране го използваме (delegation).

3. Ghost

A „ghost“ is the object that is to be loaded in a partial state. It may only contain the object’s identifier, but it loads its own data the first time one of its properties is accessed. For example, consider that a user is about to request content via an online form. At the time of creation all we know is that content will be accessed but what action or content is unknown.

A ghost is the real object without any data. The first time you call a method the ghost loads the full data into its fields.

Или с други думи, създаваме обект но съвсем опростен с идеята в последвие да добавяме към него повече данни. Добър пример би бил, ако първо създадем някакъв „полупразен“ обект, в който ще съхраняваме и обработваме информация от събмитната HTML форма, но го „пълним“ след събмитване.

$userData = array(
    "UID" = > uniqid(),
    "requestTime" => microtime(true),
    "dataType" => "",
    "request" => ""
);

if (isset($ _POST['data']) && $userData) {
    // …
}

4. Value holder

Basically, а value holder is a generic object that handles the lazy loading behavior and appears in place of the object’s data fields. When the user needs to access it, they simply ask the value holder for its value by calling the GetValue method. At that time (and only then), the value gets loaded from a database or from a service (this is not always needed).

Най просто, идеята е когато имаме нужда от дадено пропърти на даден обект, и това е свързано с ресурсоемка или времеемка операция (извличане от БД например), това извличане да стане чак тогава, през даден гетър например, в който например може да има допълнителна логика, която да запази тази информация в статично пропърти, за да не се извлича всеки път.

public function getValue($parameter) {
    if (self::$value == null) {
        self::$value = valueRetrieval($parameter);
    }
    return self::$value;
}

Литература:

https://en.wikipedia.org/wiki/Lazy_loading

https://en.wikipedia.org/wiki/Lazy_initialization#PHP

https://www.geeksforgeeks.org/lazy-loading-design-pattern/

Има случаи, в които е по-добре да използваме обекти вместо примитивни типове. Нека погледнем следният пример:

Имаме клас User в който подаваме дадено пропърти, например $url като стринг и също, преди да го сетнем, правим някаква примерна валидация.

class User
{
    private string $url;

    public function setUserUrl(string $url) : void
    {
        if (false === filter_var($url, FILTER_VALIDATE_URL)) {
            throw new SomeValidationException('Wrong url bla bla bla...');
        }
        $this->url = $url;
    }

    public function getUserUrl() : string
    {
        return $this->url;
    }

    // ...
}

На пръв поглед всичко е доста просто.

Но първото, което не е ОК, е че валидацията на URL-a e в класа User. Не нарушаваме ли Sigle Responsibility SOLID принципът?

Също, ако трябва да подадем URL и на друг клас, там също трябва да я има тази валидация – повтаряне на код.

Да не говорим, че ако подаваме така, по отделно, може да имаме „експлозия от входни параметри“ ако се наложи да подаваме и други стойности.

Няма ли да е по-елегантно и гъвкаво ако създадем нов клас Url и там да изнесем валидирането и евентуално друга логика, свързана с Url-и. И където ни трябва, просто да инджектваме обект от класа Url?
T.н. „Replace Data Value with Object “ техника за рефакториране.

class User
{
    private string $url;

    public function setUserUrl(Url $url) : void
    {
        $this->url = $url;
    }

    public function getUserUrl() : string
    {
        return $this->url->getUrlAddress();
    }

    // ...
}

class Url
{
    private string $url;

    public function __construct(string $url)
    {
        if (false === filter_var($url, FILTER_VALIDATE_URL)) {
            throw new SomeValidationException('Wrong url bla bla bla...');
        }
        $this->url = $url;
    }

    public function getUrlAddress() : string
    {
        return $this->url;
    }

    // ...
}

Вижда се, че Primitive Obsession трябва да се избягва, когато не просто използваме примитивни типове за някаква стойност, но трябва и да имаме някаква логика, на която тези примитивни стойности да се подчиняват.

Добър пример би бил ако например искаме да имаме пропърти $age за даден User, но също и трябва да я използваме тази възраст само за живи хора, а не и за например исторически личности, за които възрастта може да е стотици години.
Тогава не може просто да подаваме произволен, положителен integer.

Литература:

https://dzone.com/articles/code-quality-fighting-primitive-obsession-code-sme-1

Какво да крием?
Пропъртита на класа (данните на обекта).

Как да ги скрием?
Като ги зададем с видимост private или protected и ги достъпваме през сетъри и гетъри.

Защо да ги крием?
За да предотвратим възможността от това да бъдат директно и безконтролно достъпвани. Затова са и гореспоменатите сетъри и гетъри – за да зададем допълнителна логика за достъпване на въпросните пропъртита (данни на класа).

Литература:

Object encapsulation and object abstraction

Build seven good object-oriented habits in PHP

Най-просто – когато имаме допълнителни (така да се каже „сервизни“), класове, които не са част от самият бизнес модел, но са необходими (като Logger, Auth…), вместо да ги инджектваме в съответният съществен клас (напр. News) и така да го натоварваме, и него, и другите съществените (бизнес модела) с още код, правим допълнителни Aspect класове като напр. AspectLogger, който ще прави логването като Logger, и допълнително AspectConfigurator, където задаваме кой „аспект клас“ къде да бъде викан.

Ето един супер прост пример – на този клас искаме да му добавим например проверка дали даденият, логнат потребител има право да го използва.

Стандартният начин е да имаме клас Auth например, и да инджектнем един негов обект, и например в началото на всеки метод да викаме метод на Auth който да проверява.

<?php
class MyServices
{
    public function doAdminStuff1() {
        //some stuff only the admin should do
        echo "Calling doAdminStuff1";
    }

    public function doAdminStuff2() {
        //some stuff only the admin should do
        echo "Calling doAdminStuff2";
     }
}

Няма ли това да усложни нещата? Ами утре ако трябва и друга функционалност да се използва вътре в MyServices? Пак инджектвай, пак усложнявай методите на MyServices…? И то с какво? С нещо, което няма пряка връзка с MyServices.

Или да изнесем например Auth функционалността извън MyServices? ОК, но това ще значи навсякъде, където се викат методи на MyServices, да използваме Auth и другите (Logger…).

Няма ли да е по-елегантно да изведем някъде настрана логиката кога, къде и какво да се вика за проверки, логове и т.н., без да занимаваме съществените за бизнес модела класове?

AOP is a PECL extension that enables you to use Aspect Oriented Programming in PHP. Като гледам, тук най-просто се дефинират нещо като евент хендлъри, където се задава за кой клас, кой метод, и кога да се извика какво.

<?php
aop_add_before('MyServices->doAdminStuff1()', 'theNameOfTheAuthCheckMetod');

In computing, aspect-oriented software development (AOSD) is a software development technology that seeks new modularizations of software systems in order to isolate secondary or supporting functions from the main program’s business logic.
It does so by adding additional behavior to existing code (an advice) without modifying the code itself, instead separately specifying which code is modified via a „pointcut“ specification.

Core concerns – неща, директно свързани с бизнес модела.

Cross-cutting concern – така да се каже „помощни неща“ като например логване на грешки, аутентикация… Именно това е целта и идеята на Aspect Orienter Programming – да капсулира тези cross cutting concerns в т.н. „aspects“ и да направи използването им възможно, с цел да се олекоти core concern. Aspect-oriented programming aims to encapsulate cross-cutting concerns into aspects to retain modularity.

For instance, if writing an application for handling medical records, the indexing of such records is a core concern, while logging a history of changes to the record database or user database, or an authentication system, would be cross-cutting concerns since they interact with more parts of the program.

Aspects – част от целият софтуер, който може да се използва на различни места, но не е директно свързан с „program’s primary function“.
Но ако гледаме по-философски на нещата, дори и самата бизнес логика (the core concern) може да се разглежда като aspect, and by weaving them together (a process also called composition), one finally produces a whole out of the separate aspects.

Литература

https://en.wikipedia.org/wiki/Aspect-oriented_programming

https://aop-php.github.io/

https://en.wikipedia.org/wiki/Aspect-oriented_software_development

Cohesion is the indication of the relationship within a class.

Coupling is the indication of the relationships between classes.

Кохезията трябва да е максимално висока, защото тя характеризира колко един клас прави само това, което трябва да прави, т.е. до колко отговаря на Single Responsibility Principle. Ниската кохезия означава, че класът се опитва да е „швейцарско ножче“, или т.н. „God class“.

Coupling-ът между класовете трябва да е минимална, защото тя характеризира до колко те за зависими и до колко промяна в единият може да счупи останлите.

За да има low coupling между класовете, една добра идея е да се правят така, че да се разбира лесно какво правят поотделно, без да се знае много или даже нищо за цялата система.

Трябва да бягаме от това да се опитваме да правим т.н. „God class“ или „Swiss army knife“…

Литература:

https://ducmanhphan.github.io/2019-03-23-Coupling-and-Cohension-in-OOP/

https://stackoverflow.com/questions/3085285/difference-between-cohesion-and-coupling