acwartz

Все эти страшные слова - они на самом деле всегда про одно и то же - про связность. Когда ты хардкодишь внутри класса вызов какого-то конкретного сервиса - ты намертво к нему привязываешься. И чтобы поменять сервис на другой, ты будешь вынужден поменять код класса. Окей, поменял. И тут же в другом месте, где этот же класс использовался, что-то сломалось! И что теперь? Делать два класса, которые различаются одной строчкой? Нет конечно. А как тогда использовать один и тот же класс для обработки разных входящих данных (или одних и тех же данных, но разными способами)? Сделать его поведение изменяемым. То есть сделать изменяемыми те инструменты, которыми он пользуется - т.е. его зависимости.

Поэтому все зависимости обычно передаются через конструктор (и поэтому и называются инъекция зависимостей.)

Таким образом мы можем менять поведение класса, не меняя его код

Но тут надо понимать, что всё это работает только при правильном применении ООП. А точнее просто при применении ООП. Потому что 98% "ООП" кода, который пишется на РНР - это голимая процедурщина, даже если она обёрнута в классы и методы. Если у тебя метод класса представляет из себя стену кода, которую ты тупо перенёс из файла, инклюдившегося в любимое похапешное спагетти - то это не ООП. Это та же процедурщина, вид сбоку. И смысл использования dependency injection ты с ним не почуствуешь. Будешь конечно применять, но в качестве карго культа - потому что тебе это на тостере написали.
А вот когда твой код начнет становиться действительно объектным - тогда стразу станет понятнее.

Похожим на сервис локатор является сервис- или DI-контейнер. Используемый вручную, он является тем же самым сервис локатором. Поэтому вручную его никогда не надо вызывать - что и запрещается в симфоневских конроллерах - а только для автоматического создания классов. В МВЦ у тебя ведь очень многие объекты создаются автоматом - сущности, контроллеры. И вот для того, чтобы при автоматическом создании экземпляра класса у тебя были на руках все требуемые сервисы - и нужен контейнер.

Соотвтственно, ответ на вопрос "что использовать?" очень простой:
- при ручном создании экземпляра объекта, все зависимости передавать в него через конструктор, а не получать "из воздуха" в коде.
- при автоматическом создании экземпляра объекта, использовать dependency injection container

В этим смысле очень полезно освоить Симфони - строгий фрейворк, в котором нет сервис локатора и в котором запрещено пользоваться контейнером напрямую.

Да, такие программы конечно есть. Самая популярная - Google Chrome.
Жмешь там F12 → perfomance и анализируешь нагруженные места. Там же можно и процессор "замедлить".

В сети куча гайдов как этим пользоваться.
https://developers.google.com/web/tools/chrome-dev...

Примерно так:

import java.util.List;
import java.util.Random;
import java.util.function.Function;

class RandomFunctor {

    private final List<Function<Integer, String>> functionList = List.of(
            integer -> {
                return "this is from first " + integer; //TODO :: implement me!
            },
            integer -> {
                return "this is from second " + integer; //TODO :: implement me!
            },
            integer -> {
                return "this is from third " + integer; //TODO :: implement me!
            });


    public String getRandomString(Integer input) {
        var rand = new Random();
        var function = functionList.get(rand.nextInt(functionMap.size()));
        return function.apply(input);
    }
}

Устанавливаете расширение greasemonkey/tempermonkey или любой другой, позволяющий инжектить (запускать по условию) ваш скрипт на страницу, для отладки вы вообще можете в консоли браузера скрипт вставлять без расширений.

Затем скрипт ищет на странице поля ввода и кнопки примерно так $('#inputbox_id') и получаете/устанавливаете его содержимое .value или .text (для textbox), на кнопку нажимаете .click(), т.е. вся возня со скриптом у вас должна быть вокруг того чтобы не делать эти действия сразу друг за другом (это могут проверять для защиты от автоматизации в общем случае) а с интервалом и контроль над различными ошибками (например код формы изменился).

Иногда просто установить значение полей ввода не достаточно, нужно симулировать нажатия клавиатуры, в этом случае либо формируете события браузера с помощью keyboardEvent либо просто подсмотрите, какие методы вызываются на эти события и вызывайте их самостоятельно.

Чтобы узнать какие css селекторы у нужных вам полей, в браузере достаточно нажать правую кнопку мыши (иногда с shift) и выбрать inspect element, в открывшемся инструменте разработчика можно правой кнопкой мыши выбирать нужные элементы страницы и в контекстном меню выбирать copy/css selector или что вам угодно.

Управлять своим скриптом со стороны лучше по http/websocket на ваш сервер (вам придется поднимать https версию если вебсайт ее тоже использует)

Ну, если прям как по учебнику, тогда вам нужно описать интерфейс, от которого будет зависеть класс TableSelection (один класс не должен напрямую зависеть от другого, так как это сложнее поддерживать).
Например так:

interface Cell {
    addClass(cssClass: string) : void
    removeClass(cssClass: string) : void
}

class TableSelection {
...

Ну, а далее вы просто указываете что свойство group это массив чего-угодно что соответствует интерфейсу Cell

interface Cell {
    addClass(cssClass: string) : void
    removeClass(cssClass: string) : void
}

class TableSelection {
  static selectedClass: string = 'selected'
  group: Cell[]

  constructor() {
    this.group = []
  }

  select($cell: Cell) {
    this.clear()
    this.group.push($cell)
    $cell.addClass(TableSelection.selectedClass)
  }

  clear() {
    this.group.forEach(($selectedCell) => $selectedCell.removeClass(TableSelection.selectedClass))
    this.group = []
  }
}

Пример готового кода

Есть несколько простых советов:
1. искать исключительно текстовую информацию (видео только для визуального ознакомления с внешним видом или техникой какого-либо действия).
2. искать на тематическим ресурсах, например researchgate
3. использовать "научную" постановку запроса, т.е. не "как выучить питон", а "python official documentation specification"
4. не использовать русский язык (только для контекстных запросов)
5. не использовать русские поисковики (только для контекстных запросов)
6. не использовать русский ip (только для контекстных запросов)
7. сначала изучить общие вопросы, а затем уже частные (т.е. не "как повернуть игрока к цели unity 2d", а "unity3d official documentation").

Вы на одну проверку наличия следующего элемента, выполняете четыре перехода к следующим элементам.

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

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

Видимо потому что powershell использует .Net, а это вещь довольно тяжелая и тянуть ее в систему восстановления смысла нет.

Дело не в Angular, а в том что такое интерфейс. Я расскажу со стороны моей практики.

Интерфейс это контракт взаимодействия между техническими сущностями (классы, объекты, функции, и так далее). Если мы создаем 10 объектов, которые соблюдают (реализуют) интерфейс, значит их можно подменять друг другом (только не нужно нарушать LSP, это принцип SOLID).

Так вот, отсюда есть мощные бонусы:

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

Выходит что сущности не завязываются друг на друга, и их можно разрабатывать независимо друг от друга, а в разработке чем меньше связей между классами/объектами, тем лучше. Если потом понадобится изменить код, поменять класс, будет значительно меньше проблем. Меньше, потому что если есть цепочка зависимостей, то нельзя изменить что-то одно, потому что другое сломается, и придется менять всю цепочку. Убирая прямые зависимости изменение кода становится проще.

Второе, это стабильность, лично для меня. Я работаю на TypeScript, и там можно описать интерфейс, сигнатуру функции, и ожидать на входе любые данные, которые его реализуют, и вообще пофигу откуда они, но пока они реализуют интерфейс, всё будет работать стабильно.

Третье, это понимание с чем ты работаешь. Когда есть интерфейс, ты всегда понимаешь что можно использовать у объекта, что там есть, и какого это типа. Просто очень удобно.

Ну и самое главное, лично для меня, это то, что мы инженеры, т.е. мы должны проектировать систему, а потом реализовывать, и интерфейс это один из наших "чертежей".

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

Поэтому Ангуляр собственно не причем, это просто фреймворк, а принципы проектирования там те же самые, как и в любом другом приложении.