Это когда на чтение забытого кода уходит не 10 часов а 10 минут. Хороший уровень абстракции при правильном разделении на слои абстракции. Допустим, использовать в качестве "транспорта" не массив и не список переменных, а объект. Использовать геттеры и сеттеры в нем для записи и чтения нужной информации. Я передал объект из одной подсистемы в другую при этом что одной, что другой подсистеме глубоко начхать что из себя представляет реализация этого класса. Потому что он реализован от интерфейса, через который идет согласование. Это ООП или нет? Я считаю что да. Простенькое, конечно, но уже ООП.

Чуть посложнее это внедрение зависимостей (через полиморфизм). Опять же лучше всего плясать от интерфейса.

Может быть я не прав, но я считаю основной инструмент ООП это не наследование нифига ниразу а полиморфизм. На нем строится большинство паттернов. Задача создать в коде микро API, но более низкого уровня. Эти API и есть интерфейсы по сути-то. Они нас подталкивают к полиморфизму а дальше идет то самое внедрение зависимостей и т.д. паттерны и прочее. Всё. Вот оно ООП, вся его суть, мощь и прелесть.

Нет никаких жестких стандартов, он один: хорошая читаемость и легкая расширяемость.

Некоторые думают, что ООП это попытка разделить на сущности AKA реальный мир. Полная глупость, и близко ничего такого нет. Фишка в инверсии потока вызовов и изоляция вышестоящей архитектуры от деталей реализации подчиненной.

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

Там вообще все было через задницу, не только этот момент. Это можно было еще исправить. Весь код был таким. Как ты говоришь - легко поддерживаемым. Вот только уволиться ему все же пришлось.

А то, что на чтение забытого кода уходит время, так причем тут вообще методология? Любой код можно забыть. И уж тем более плохо, когда не знаешь, да еще забудешь. Я же не просто так спросил. В чем проще разобраться, в иерархии 149 классов, или в 20-30? Когда первый раз видишь код. Или когда забыл.

А когда с этим работаешь ежедневно с утра до вечера, как можно забыть вообще?

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

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

Судя по вопросу дела с архитектурой обстоят неочень... Или нет?

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

Да, есть. И что? Есть у меня такие классы, которым триста лет в обед, и которые вообще изменять не нужно. Но их мало, это такие классы, которые нужны постоянно и везде.

А то, что ты называешь плохой архитектурой, я не понял. Обоснуй. Просто я часто слышу это определение, но оно обычно сводится к банальному "не как у всех".

Если у меня есть минимальный набор общих классов (ядро), а остальное не зависит друг от друга, это плохая архитектура? Общие, я имею ввиду такие как роутер, класс для СУБД, постраничка, шаблонизатор и так далее. Именно такие, которые вообще не относятся к функциналу, а помогают ему. То, что chee назвал инфраструктурой. Только у меня этого минимум. Реально то, без чего никак.

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

Если я работаю с несколькими платежными системами к примеру, и у меня нет для них общего абстрактного класса (ну не юзаю я для этого полиморфизм), это значит плохая архитектура?

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

По сути та же абстракция, только нет лишнего слоя. Все просто и прозрачно, не как слоеный пирог.

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

И еще, мне нравится, как сказал Гаррет.

Я получаю от работы удовольствие и деньги. А ходить строем и делать "как все"... Ну не моё.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

А ни кто не ставит вопрос о количестве подключаемых файлов. Это походу у тебя такой фитиш. Если бы мы дрочили на количество файлов, то делали бы минификаторы или пихали несколько классов в один файл.

Вернемся опять же к вопросу: зачем 150 файлов? А ни кто не решает задачу так, что было как можно больше файлов, просто есть множество классов, каждый из них несет свою функциональность в пределах описаных интерфейсов.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Вот это для меня загадка. Какая цель преследуется этим в инфраструктуре, когда можно обойтись малым количеством. Ведь это и прозрачнее и ремонтопригоднее и вообще. Есть же какая то цель. Вот тут мы и расходимся. Для тебя не важна ресурсоемкость, ты не работаешь на хайлоад проекте, иначе бы так не рассуждал. Для тебя не важна прозрачность, иначе в формировании страницы не было бы задействовано одновременно такой кучи инфраструктурных классов. Так что для тебя важно?

У меня вообще такое впечатление, что вы пишите код раз и до скончания времен. Расширяемость, абстракции... Да он через несколько лет один фиг устареет. И все равно придется все переделывть. Мы живем в обществе потребителей. Всем хочется 6-й айфон, даже если еще не успел покорябаться пятый. Все настолько бренно, что о таких вещах, как буквы в редакторе и говорить не стоит.

Ты же сам меня упрекал в том, что я использую старые технологии. А по сути получается наоборот. Ты сейчас конечно применил DI, это новая фишка. Но стоит ли оно того, чтобы так расшиперить код, что нужно 150 классов для элементарного "Привет, мир"? Все равно не так долго ждать того, что придется все выкинуть и забыть.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

А кто вообще говорит про hello world? Я могу тебе расписать зачем там 150 файлов и что они делают, в моей системе.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Да я видел. От того и не понимаю - зачем. Не что они делают. А зачем они это делают. Когда можно все сделать на много проще.

Анекдот вспоминается времен перестройки. Два новых русских в Америке. Один хвастается галстуком - во какой за 1000 баксов купил! А второй - да ты лох. В соседнем магазине точно такие же по 2000 продаются!

Хотя расскажи, если не лень. Может я действительно чего не догоняю.


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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

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

Вот тебе лайв пример:

Процедурка, немного строчек, все как ты любишь

function export($sql)
{
    $data = getData($sql);
    $content = prepareContent($data);
    
    download($content);
}

export("SELECT * FROM users");

ООП вариант, различий в логике практически нет,

class Export
{
    public $dataProvider;
    public $contentDriver;
    public $output;
    
    public function download($sql)
    {
        $data = $this->dataProvider->getData($sql);
        $this->contentDriver->setData($data);
        
        $this->output->put($this->contentDriver);
    }
}

$export = new Export;
$export->dataProvider = new DataProvider;
$export->contentDriver = new ContentProvider;
$export->output = new Output;
$export->download("SELECT * FROM users");

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

Функция export, ПЕРЕПИСЫВАЕТСЯ на половину, логика УСЛОЖНЯЕТСЯ, добавляются ДВЕ НОВЫХ функции, которые не могут наследовать функционал от предыдущей фунции prepareContent, а могут лишь только вызвать ее полностью.

function export($sql)
{
    $data = getData($sql);
    if (count($data) > 100000) {
        $content = prepareCsvContent($data);
    } else {
        $content = prepareXmlContent($data);
    }
    
    download($content);
}

Возможно ты подумаешь, что можно и так

function prepareContent($data)
{
    if (count($data) > 100000) {
        $content = prepareCsvContent($data);
    } else {
        $content = prepareXmlContent($data);
    }
    
    return $content;
}

function export($sql)
{
    $data = getData($sql);
    $content = prepareContent($data);
    
    download($content);
}

Но это приводит к тем же результатам, ты вносишь ЗНАЧИТЕЛЬНЫЕ ИЗМЕНЕНИЯ в существующую функциональность, просто по ветке вызова это будет немного дальше.




В ООП вариант будет лишь ОДНО НЕЗНАЧИТЕЛЬНОЕ ИЗМЕНЕНИЕ (в передаче зависимостей) и ТРИ НОВЫХ класса, два из которых при необходимости могут НАСЛЕДОВАТЬ функциональность устаревшей версии функционала

class ContentProviderManager
{

    public function setData($data)
    {
        if (count($data) > 100000) {
            $this->contentProvider = new ContentProviderCsv;
        } else {
            $this->contentProvider = new ContentProviderXml;
        }
        
        $this->contentProvider->setData($data);
    }

    public function __toString()
    {
        return $this->contentProvider->__toString();
    }

}

$export = new Export;
$export->dataProvider = new DataProvider;
$export->contentDriver = new ContentProviderManager;
$export->output = new Output;
$export->download("SELECT * FROM users");

Если ты считаешь, что существенно изменять существующий код это в разы лучше чем создавать новый, то у меня нет больше аргументов.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации