Ben L

refactoring.guru - один из наиболее качественных, если говорить о паттернах GoF.
Ещё книга из серии Head First по паттернам достаточно легко читается.

Но где применять в реальных задачах - это, в основном, только на практике.

Уже обсуждалось это здесь и не раз, DTO только для передачи данных и точка. Всё остальное происходит вне DTO

Такое, конечно, можно сделать через статическое свойство со списком экземпляров класса, но зачем нужен такой изврат? В каких реальных целях его применять?

class A
{
    private static array $instances = [];
    public readonly int $value;
  
    public function __construct(?int $value = null)
    {
        if ($value !== null) {
            $this->value = $value;
            static::$instances[] = $this;
        }
    }

    public function summ(): int
    {
        return array_reduce(
            static::$instances,
            fn($acc, $cur) => $acc + $cur->value,
            0
        );
    }
}

new A(2);
new A(3);
$summ = (new A())->summ();
print $summ; // 5

Легко

А если бы, допустим, в у нас был отдельный интерфейс IMove, то мы смогли бы реализовать его в каком угодно модуле/компоненте, например в условном File, ведь мы можем переместить файл. Так же и с ISleep, мало ли что может уснуть, начиная от операционной системы или потока выполнения, заканчивая персонажем в тамагочи.

Неверно. IMove (точнее будет назвать Movable) имеет смысл в контексте какой-то предметной области. И перемещение файла, перемещение спрайта, перемещение трехмерного объекта, перемещение руки робота - все это разные перемещения. Соответственно и интерфейсы будут разные (расположенные в разных модулях, даже если будут называться одинаково), например:

filesystem.Movable
graphics.2d.Movable
graphics.3d.Movable
servo.Movable

Поэтому ответ - нет, не нужно придумывать что-то общее у разнородных предметов и явлений. Только если это что-то общее позволяет вам как-то лучше моделировать предметную область.

Вообще главный принцип тут такой: интерфейс должен иметь смысл, описывать некоторую единицу функциональности именно с точки зрения предметной области. Скажем, если в вашей предметной области операция move имеет смысл без операций eat и sleep - её можно выделить в отдельный интерфейс (а можно и не выделять, это зависит от других факторов). Если же операции eat и sleep всегда должны ходить парой и каждый потребитель этого интерфейса нуждается в обеих операциях - они должны быть в одном интерфейсе.

Главная идея принципа инверсии зависимостей "детали зависят от абстракций, но не абстракции от деталей".
В приведенном вами примере класс Main зависит от всего: от интерфейса INumberOperation и от обоих классов NumberOperation1, NumberOperation2. То есть тут принцип инверсии зависимостей вообще не работает. Никак.

Проявляется же он в следующем примере. Пусть у меня есть некая абстрактная логика "прочитай число, выполни над ним операцию, запиши результат". Эта абстрактная логика (потому она и абстрактная) ничего не должна знать ни откуда она читает число, ни какую операцию над ним выполняет, ни куда и как записывает результат. Таким образом, у нас есть модуль, состоящий из

interface NumberInput {
  int read();
}
interface NumberProcessor {
  int process(int a);
}
interface NumberOutput {
  void write(int a);
}
class Processor {
  private final NumberInput input;  
  private final NumberProcessor processor;
  private final NumberOutput output;

  public Processor(NumberInput input, NumberProcessor processor, NumberOutput output) {
    this.input = input;
    this.processor = processor;
    this.output = output;
  }

  void process() {
    output.write(processor.process(input.read()));
  }
}

Все. Модуль получился очень абстрактным и ни от кого никак не зависящим.
Затем мы можем сделать реализации этих интерфейсов - они будут зависеть от нашего модуля логики (так как ссылаются на интерфейсы). И это полностью соответствует принципу инверсии зависимостей - детали зависят от абстракций.

И наконец функция main, которая будет собирать все это в единое целое. Она самое конкретное что есть в нашей программе, так как она имеет дело с конкретными классами, экземпляры которых она создает. Поэтому она зависит от всех модулей - от модуля абстрактной логики и от модулей с реализациями интерфейсов. И тут принцип инверсии зависимостей тоже соблюдается - деталь (в какой именно конфигурации запускается программа) зависит от абстракции (абстрактная логики и конкретные реализации интерфейсов из которых выбирается именно та, которая будет использована)

Этот принцип очень хорошо объяснен в книге Р.Мартина "Чистая архитектура", по крайней мере у меня все встало на свои места именно после прочтения этой книги.

Способ 1: как вы и хотите, переиспользование функции. Пишем функцию, которая возвращает функцию less
https://play.golang.org/p/x_zDfZfwm_Q

func main() {
	arr := []byte{4, 3, 2, 1, 6, 3, 77, 8, 3}
	sort.Slice(arr, bytesAsc(arr))
	fmt.Println(arr)
}

func bytesAsc(arr []byte) func(i, j int) bool {
	return func(i, j int) bool {
		return arr[i] < arr[j]
	}
}

Способ 2: создаем алиас типа, у которого прописаны нужные методы.
https://play.golang.org/p/ZNkOt_jSUbr

func main() {
	arr := []byte{4, 3, 2, 1, 6, 3, 77, 8, 3}
	sort.Sort(BytesAsc(arr))
	fmt.Println(arr)
}

type BytesAsc []byte

func (a BytesAsc) Len() int           { return len(a) }
func (a BytesAsc) Swap(i, j int)      { a[i], a[j] = a[j], a[i] }
func (a BytesAsc) Less(i, j int) bool { return a[i] < a[j] }

Если нужна именно функция - можно вот так

func SortBytes(arr []byte) {
    sort.Slice(arr, func(i, j int) bool {
        return arr[i] < arr[j]
    })
}
// потом использовать вот так
arr := []byte{4, 3, 2, 1, 6, 3, 77, 8,3}
sortBytes(arr)
fmt.Println(arr)

Но я бы использовал тот вариант, который у вас )

sort.Slice(arr, func(i, j int) bool {
  return arr[i] < arr[j]
})
fmt.Println(arr)

В общем случае -- стоит.

Но это больше всего зависит от вашего конкретного случая. Сколько кода является общим для всех страниц? Сколько уникально для каждого типа страниц? Сколько уникально для каждой страницы? Какова модель поведения пользователя? Он посетит все страницы сайта или только страницы одного типа? Пользователи заходят на сайт только раз, или постоянно возвращаются? С каких устройств и с какой скоростью интернета к вам приходят? Как построен процесс деплоя? Какие тарифы у вашего хостинга? Как часто и что вы изменяете в исходном коде? Как будете инвалидировать кэш? И ещё очень много вопросов, которые нужно учитывать.

Можно всё сгрести в один огромный бандл. Тогда первичная загрузка будет дольше, особенно ощутимо на медленном интернете. Но навигации по страницам будут быстрее, а нагрузка на сервер меньше. Но при изменении, скажем цвета одной кнопки, пользователю придётся заново качать весь бандл. И наоборот. Можно уйти и в другую сторону: дробить всё на как можно меньшие кусочки. (Например вынести весь код для какой-то модалки отдельно) и загружать каждый чанк только в момент когда он понадобится. Так первичная загрузка будет намного быстрее, но реакция на действия пользователя будет медленнее.

В общем случае -- дробить код сайта на куски и отдавать их частями -- стоит. Но вмеру. А как именно делить -- зависит от вашего случая.