Алексей Володин

Проблема в том, что это невалидный код, который вероятнее всего писал chatGPT.
Исправлять такой код помогают тут

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

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

А потом я случайно узнал, что эти какие-то непонятные методы, которые "являются поведением объектов класса" (как это обычно объясняют) на самом деле просто функции и есть. И оказалось, что можно не пропихивать массив через них, а наоборот - функции сложить в этот массив. Получилось, что класс это такой "массив" в котором есть не только переменные, но и функции. И эти функции могут видеть все эти переменные, даже если не написать global $var. И это было как раз тем, чего я очень желал и радости моей не было предела.
Кстати, узнал я это, когда забавы ради кодил 2D платформер на C# в Unity.

1. Хорошо помогает начать изучение с простых паттернов проектирования. Прежде всего это простые и понятные паттерны типа "стратегия", "команда", "итератор", "шаблонный метод", "посредник", "цепочка обязанностей". Изучив и поняв эти паттерны вы посмотрите на ООП по новому: не как просто структурированный код плюс данные в одном объекте, а именно как задумывалось его создателем - объект самостоятельная единица взаимодействующая с другими такими же посредством сообщений. Причём она является first class также как в функциональном программировании функция. К тому же на указанных паттернах строятся и остальные. Например, фабричный метод - это частный случай шаблонного метода. Так постепенно придет понимание куда и зачем применять различные паттерны.
2. Когда решаете какую-либо задачу, думайте о нескольких вариантах архитектуры для её решения. Далее старайтесь выбирать
вариант не на основе личных предпочтений или предыдущего опыта (не важно, положительного или отрицательного), а на основе анализа, какой из вариантов здесь реально потребуется с точки зрения дальнейшего развития проекта. Предыдущий опыт также надо учитывать, но все проекты разные, требования разные, и каждая ситуация может отличаться. Надо смотреть как могут изменяться или расшириться системные и функциональные требования (разумеется, для этого надо быть в контексте этих требований - т е знать их самих, манеру работы с проектом заказчика и т д) Во многих случаях, когда вы не сможете выбрать из-за недостатка информации, это логически подведёт вас задавать заказчику дополнительные вопросы. И через этот итеративный процесс приходит понимание, где и как применять паттерны.
3. Обратите внимание на паттерны ERP систем (для примера книга "Шаблоны корпоративных приложений" Мартин Фаулер) Особенное внимание надо уделить такому шаблону как инверсия зависимостей. Данный шаблон лично мне помог совершенно по другому взглянуть на ООП (во второй раз, уже после того как я стал применять другие паттерны ООП) Вот здесь https://blog.byndyu.ru/2009/12/blog-post.html очень понятно на мой взгляд описано (язык C# но всё тоже самое будет для любого ОО языка) Кроме того в этом блоге много всего по проектированию и рефакторингу.
4. Обратите внимание на книгу "Growing Object-Oriented Software, Guided by Tests" Стив Фриман Перевод на русский не гуглится, возможно его и нету. Но книга полезна тем, что в отличие от многих других книг по TDD в ней разбирается не только методика тестирования и написания тестов, но и принцип тест -> код -> рефакторинг. И разбирается на достаточно длинном примере. Из неё вы можете подчерпнуть привычку рефакторить, а не переписывать заново. Причём даже если у вас на проекте цикл другой - например тесты пишутся после функционала, всё равно образ мысли изменится и масштабный рефакторинг не будет вызывать непреодолимого желания выбросить и переписать с нуля.
5. По рефакторингу могу порекомендовать книгу "Работа с унаследованным кодом" Майкл Физерс. Кроме того об этом много статей в уже упомянутом блоге Александра Бындю. Грубо говоря я бы назвал ту подборку статей "как не переписывать и начать жить"
6. Ещё один блог где собрано большое количество полезных материалов по ООП, рефакторингу, проектированию, это блог Сергея Теплякова Вот ссылка на его подборку книг по теме: sergeyteplyakov.blogspot.com/2013/08/blog-post.html
7. Изучайте материалы постепенно. Не стоит сразу пытаться воткнуть только что полученные знания в первый попавшийся проект. Обсуждайте возможные решения с коллегами. Со временем они также станут поддерживать эту практику. Если есть возможность, попрактикуйте парное программирование. Причём не обязательно с более опытным коллегой. Иногда вопросы задаваемые наивным человеком заставляют задуматься гораздо крепче, чем ответы получаемые от мудрецов.

Докер на М1 все еще туп. Если у вас вопрос в *EMP стеке, используйте homebrew + laravel/valet и если нужен гуй - phpmon.

Идеально конечно попасть в большой проект с опытными коллегами.

Чистая архитектура полезная книга.

Мне помогла серия видео по запросу "модульный монолит".

ArchDays 2020 • Модульный монолит вместо микросервисов • Денис Цветцих (Epam)

Модульный PHP монолит как альтернатива микросервисной архитектуре - Юлия Николаева, iSpring

И самое главное серия статей Herberto Graça The Software Architecture Chronicles
https://habr.com/ru/post/427739/
https://herbertograca.com/2017/07/03/the-software-...

В голову заходит тяжело. Выше коллега писал про свой подход: постоянно пробовать то что узнал на практике и пересмотр решений.

Mac OS 10.10
sudo sysctl -w net.inet.ip.ttl=65
вносит правку, но реально ttl не меняется, до обновления все работало. Интерфейсы перезапускать пробовал.
Перезагружаешь систему слетает на 64, раньше мне казалось, что на мак sysctl на все время меняет ttl, во всяком случае на android и debian точно перманентно, а если в /proc писать то до перезагрузки.

#update

Нашел решение, sysctl действительно до перезагрузки работает, чтобы добиться постоянного значения:
1. Создаем файл /etc/sysctl.conf
2. В него добавляем строку
net.inet.ip.ttl=65

Ничего страшного, допишите еще один case и метод, и все будет нормально. Да, это нарушает принцип, но все так делают, просто хрен кто признается. Не пытайтесь здесь вкрячить какого-нибудь монстра, сложный код - это потенциальные ошибки, если возможно написать просто, так и нужно сделать.
Принципы - они принципы, а не законы, надо следовать не букве, а смыслу. Принцип открытости и закрытости оберегает нас от ошибок и дополнительных затрат на тестирование кода, который вроде бы и так уже работает и хорошо себя зарекомендовал. Т.е. если бы у вас был один метод и вы там внутри как-то хитро разруливали работу с разными типами и при добавлении нового типа изменяли бы его - это было бы ужасно. В текущей реализации, вам нужно будет добавить новый метод (это не изменит поведение класса до вмешательства), и добавить новый путь при использовании нового типа - да, вмешательство, но оно минимально. Если умудритесь накосячить здесь, то вас уже никакие принципы не спасут.
Если же у нас, что-то гораздо более сложное, либо класс физически недоступен для изменений, или он уже вовсю используется, а новый тип нужен только для конкретной реализации, то, пожалуйста, есть наследование. Наследуете класс, в потомке добавляете метод и заменяете метод, выполняющий перенаправление (не забывайте, что есть вызов parent). Это будет полностью соответствовать принципу.
Но я бы больше уделил внимание тому, почему мы ориентируемся для выбора метода на внутреннее свойство, точно ли это должны быть методы, а не отдельные классы. И вполне может быть получится так, что все эти танцы с бубнами не нужны.

public function edit(): bool
{
    $possible = [
        'hide' => 'hideSubject',
        'fast-edit' => 'fastEdit'
    ];
    if(array_key_exists($this->type, $possible)) {
        return $this->$possible[$this->type]();
    }
    return false;
}

Но при всей лаконичности этого решения у него есть очень серьезный недостаток.
Совершив опечатку, вы узнаете о ней только тогда, когда выпадет конкретный кейс - никакие инструменты ее не помогут заметить.
И поиск в IDE по коду, где вызываются конкретные методы, это место - не покажет.
Так что использование его внутри одного класса еще может быть оправдано. А вот как диспетчер публичных методов - it smells a lot.

Вариант 1 - Деструктуризация:

// Возврат нескольких значений:
function some() {
    return [23, 42];
}

// Получение
[$a, $b] = some();

\var_dump($a, $b);

Вариант 2 - Деструктуризация с ключами:

// Возврат нескольких значений:
function some() {
    return ['a' => 23, 'b' => 42];
}

// Получение
['a' => $a, 'b' => $b] = some();

\var_dump($a, $b);

Вариант 3 - Генераторы с ключами:

function some() {
    yield 'a' => 23;
    yield 'b' => 42;
}

foreach (some() as $key => $value) {
  echo $key . ':' . $value; // a:23 b:42
}

Вариант 4 - Генераторы без ключей:

function some() {
    yield 23;
    yield 42;
}

foreach (some() as $value) {
  echo $value; // 23 42
}

Вариант 5 - Генераторы с возвратом:

function some() {
    yield 23;
    return 42;
}

$value = some();
echo $value->current(); // 23
$value->next();
echo $value->getReturn(); // 42

Вариант 6 - DTO:

class DataTransferObject
{
    private $a;
    private $b;

    public function __construct($a, $b)
    {
        $this->a = $a;
        $this->b = $b;
    }

    public function getA()
    {
        return $this->a;
    }

    public function getB()
    {
        return $this->b;
    }
}

function some() {
    return new DataTransferObject(23, 42);
}

$value = some();
echo $value->getA(); // 23
echo $value->getB(); // 42

И ещё куча всяких вариантов, но мне влом придумывать уже)

Почти регулярка) Но это заработает также

(function(){
$('span').each(function(){
if($(this).attr('class') && $(this).attr('style') $(this).remove() 
})
})(jQuery)

Неблагодарите.

И допустим ли с семантической точки зрения вариант размещать одни скрипты в head а другие внизу страницы?

Всё хорошо в меру.
Если вы считаете, что готовы подольше подождать загрузки сайта, но сразу увидеть красивые чекбоксы - добавьте этот скрипт в head.
Ну а всю "тяжелую" логику, которая не нужна "здесь и сейчас" вынесите вниз.
Это нормально.
И это все преимущества. Никакой магии )

Есть еще одна "бэд прэктис": поставить символ @ перед переменной, в этом случае
echo @$user;
ошибку не вызовет.

"Базы данных. Учебник для вузов" - А. Д. Хомоненко, В. М. Цыганков, М. Г. Мальцев
Читаем раздел про проектирование баз данных, там немного. Если после прочтения всё равно не понимаете, что делать, то Вам не дано.

Зачем ставить тяжеловесную CMS, тот же Wp, для статики на 3-5 страницах? Логичнее обратить внимание либо на плоские html фреймворки, либо на легковесные cms. Вот Anchor достаточно интересная штука, до этого не встречал.