По какому принципу объединяются и разделяются методы в интерфейсах?

Методы в интерфейсах объединяются и разделяются по принципу связанности поведения (cohesion) и принципу явной контрактности.

• Связанность поведения: Методы, представляющие собой единый набор операций с сущностью или выполняющие схожее по смыслу действие, объединяются в один интерфейс. Это способствует улучшению читаемости кода, облегчает понимание назначения интерфейса и повышает его переиспользуемость.
• Явная контрактность: Интерфейс описывает явный контракт, который должны выполнять реализующие его классы. Каждый метод в интерфейсе является частью этого контракта. Методы разделяются между разными интерфейсами, если они представляют различные аспекты поведения или если их реализация может варьироваться независимо. Например, интерфейс Readable может содержать методы для чтения данных, а Writable — для записи. Класс может реализовать один или оба этих интерфейса в зависимости от своих возможностей.

Этот подход способствует принципам SOLID, в частности:

• Принцип единственной ответственности (Single Responsibility Principle): Интерфейс имеет одну причину для изменения — изменение набора поведения, которое он описывает.
• Принцип разделения интерфейсов (Interface Segregation Principle): Клиенты не должны зависеть от интерфейсов, которыми они не пользуются. Разбиение больших интерфейсов на более мелкие и сфокусированные позволяет классам реализовывать только те интерфейсы, которые им действительно нужны.

Пример:

Предположим, у нас есть сущность, которая может быть сохранена и загружена. Вместо одного интерфейса Persistable с двумя методами save() и load(), лучше создать два отдельных:

<?php
// Интерфейс для сущностей, которые можно сохранять
interface Savable
{
    public function save(): void;
}

<?php
// Интерфейс для сущностей, которые можно загружать
interface Loadable
{
    public function load(): void;
}

Класс, который может и сохраняться, и загружаться, реализует оба интерфейса:

<?php
// Класс, реализующий оба интерфейса
class DataObject implements Savable, Loadable
{
    public function save(): void
    {
        // Логика сохранения
    }

    public function load(): void
    {
        // Логика загрузки
    }
}

Класс, который только сохраняется, реализует только Savable:

<?php
// Класс, реализующий только интерфейс Savable
class TempData implements Savable
{
    public function save(): void
    {
        // Логика сохранения временных данных
    }
}

Это позволяет более гибко проектировать классы и их зависимости.