Автор у вас проблемы не с ООП, а с требованиями к коду. Если код должен что то безопасно сделать, то вы в своём коде должны эту безопасность обеспечить.
У вас требование безопасности есть, а в коде выполнения этого требования нет.
Если мы должны атомарно обновить значение при выполнении какого условия, то код который выполняет это обновление должен выполнять его атомарно, то есть проверить что условие выполнилось и только в этом случае проводить обновление значения.
В SQL для этого делается блокировка записи через SELECT FOR UPDATE, или можно делать апдейт на конкретное значение, с проверкой того что текущее значение не изменилось:
UPDATE balance SET amount=150 WHERE amount=200 and user_id=123
Как то так надо выполнчть изменение данных. Если это переменнная в памяти, или байты в файле, то изменение значения надо выполнять с аналогичными проверками. Условие выполняется ? Да - тогда обновляем. А что бы ни какой другой поток переменную не поменял используем блокировки, вы это прекрасно знаете.
ООП это метод. Вы его применяйте с учетом всех требований и программа будет работать как надо.
А если ваш код не обеспечивает атомарности, то пеняйте сами на себя, а не на ООП.
ООП это только способ установить границы того как можно изменять данные, ООП это подсказка программисту какие операции над данными можно выполнить. ООП не говорит нам как эти операции должны быть выполнены.
Вообще поэтому объекты и нельзя использоаать как DTO, именно поэтому мы должны сказать объекту: уменьши баланс на 50, если текущий баланс 200. И объект сам разберется как ему это сделать атомарно с транзакционной целостностью.
Говорить объекту: установи баланс 150, это значит брать на себя ответственность за то что баланс должен быть 150. Когда вы так используете объект, то это не ООП, это процедурное императвное программирование.
Восемь месяцев ищу работу (общий стаж 20+ лет, из них в разработке 15), за это время выходил на испытательный срок 4 раза. Первые два раза с очень низкой зп в шарашкины конторы, за место не держался. Потом была была интересная фирма, с организационным уровнем шарашкиной конторы, даром что 400 сотрудников и филиалы в каждой стране СНГ, отдел разработки всего 10 человек. С директором разошлись в оценке продуктивности моей работы, уволился.
И последнее место это что то с чем то, вышел на испытательный и через 3 дня меня уволили, по причине того что со мной сложно общаться, при этом ни споров ни каких то конфликтов не было (или были и я не заметил?), была пара созвонов с аналитиком по часу, то есть вот как ?
Моё мнение такое что "адеватным" работодателям сотрудники не нужны. И на рынке сотрудников ищут только шарашкины конторы у которых процессы не поставлены и они в этом не видят проблемы. Принятие решений и оценка результатов у них соответствующая.
Мы с ними друг другу не подходим. Поэтому я сижу на фрилансе, на хлеб с маслом мне хватает, но я скучаю по колбасе 😁 и по фирмам с отлаженными процессами постановки и приёмки задач.
Спасибо за то что разложили по полочкам. Теперь у меня,есть выбор: формулироватьь попроще или по сложней. Побольше контекста держать в голове или поольше контекста изложить на бумаге
Автор ругает всех. Ни похвалил ни разу ни кого. Где решения, автор ?
Решение по статье размазано, но вывод то надо было оформить.
На деле получилось, что статья это подводка к книжке 😁
Очень не хватает резюме из все сказанного
1 Любите свой организм, это ваш главный инструмент для решения все задач. Дайте себе отдохнуть, дайте себе подумать
2 Не ленитесь погрузиться в проблему и подумать о побочных последствиях возможных решений, играйте в долгую, если вы владелец бизнеса, поощряйте своих сотрудников играть в долгую, если ваш бизнес вам дорог.
Проблема то современного мира в том, что управление бизнесом отданно в руки посторонних людей, которые ни чем не рискуют, если угробят бизнес. Ни кто не хочет париться, ни владельцы, ни директора. А если они не хотят париться, то почему это парит автора?
Автор, вы не умеете в ООП. ООП создает границы, ООП принуждает для обработки данных использовать ограниченный набор методов, а не все что взбредет в голову. ООП задает направление для мысли.
Автору могу посоветоват смотреть старые видео Егора Бугаенко и почитать побольше статей с разбором SOLID.
Почему SOLID ? Потому что SOLID это про уменьшение сложности отдельных частей программы, про то как расширять программу, так чтобы не создавать багов в старом функционале.
Еще хорошая книжка "Совершенны код". Главная мысль книжки в том, что код должен быть максимально примитивным, требовать минимального погружения в контекст. И классы с ограниченым набором методов этл именно то что позволяет писать программы с минимальным контекстом.
Применение наследования по 10 поколений это не тру ООП, тру ООП это использование композиции классов, это зависимости от интрфейсов и максимальное использование абстрактных классов.
ООП это не один класс на все случаи жизни, ООП это как микросервисы, сотни мелких классов, заточенных вы решение ровно одной задачи. В их гранулярности и композиции вся сила ООП.
ООП это задать правила системы, создать объект и пойти пить чай 😁 ООП это декларативное програмирование. И сама большая проблема ООП, это как писать в тру ООП стиле так , чтобы тебя не уволили. Потому что прелести этих сотен интерфейсов и фабрик мало кто оценит.
ООП это всегда оабота на будущее, которого не видят люди не способные видеть дальше собственного носа.
Когда я написал статью с аналогичным смыслом мне влепили 50 минусов.
Про fixup слышу первый раз, думаю эта фишка не давно появилась. Идея красивая, все камиты с почеркушками слепляем в один камит вместе с камитом где мы эти почеркушки стерли. И всё шито крыто 👍
Спросите меня как написать статью и получить десятки минусов - я вас научу. Мои статьи стабильно огребают -20 .. -50.
Промежуточных вариантов не бывает. Или слабый интерес отщепенцов с 0..+4 или всеобщее осуждение до -50 😁
Дело то в том что Хабр это тоталитарное сообщество, ты или думаешь как все или тебя здесь не любят. Что понятно,все программисты фанатики, по другому быть и не могло 😁
Поэтому стстему Кармы надо убирать и заменить на систему лайков и дизлайков как на Ютубе.
Мне в целом не понятно зачем эта карма нужна ? Люди всё равно имеют фильтры на статьи +10 (или сколько там по умолчанию). Ну будет кто то постить статьи с минусами и ? В чем ущерб для кого ?
Очень жаль, что слизней убрали. Я один раз всего воспользовался такой возможностью, но для меня это был единственный способ.
За супер полезные лично мне статьи голосую добавлением в фэйворится, то есть в закладки.
Проблема со слизнями была в том, что чтоьбы проголосовать, надо залогиниться, а я хабр читаю по ВК, статьи открываются во внутренем браузере, что бы в хроме открыть, надо перейти по какой то ссылке, потом только появляется возможность открыть во внешнем браузере (если читаешь с телефона).
С десктопа я хабре не читаю уже года три как.
Так что слизни классная тема была, но особенности приложения ВК для смартфонов создавали большие трудности для использования этойфичи.
Объект обёртка создаётся над массивом, конструктор принимает не json-строку, а уже распашеный массив.
Дать json и сказать распарки кусочек - так не получиться.
С symfony serialiser не сравнивал, не в курсе. Но думаю у серилайзера назначение другое, не думаю, что сериалайзер выдаст элемент без приведения типа и выдаст реальный тип элемента, и позволит проверить итоговое значение является подставленным значением по умолчанию или исходное значение такое и было.
Мой пакет предназначен для анализа исходного значения, не только для конвертации в заданный тип.
Мой пакет не является заменой чему либо, у него своя судьба :) своё предназначение, зачем его качают 300 раз в месяц для меня загадка. Из 500 скачиваний в месяц 200 установок это хвосты от установки другого моего пакета, для работы с XML. И тут тоже для меня загадка зачем качать пакет для работы с XML, когда есть более популярные аналоги.
На счёт скорости работы спорно, у меня каждый шаг обработки создаётся новый экземпляр в который передаётся каждый раз новый массив, он прямо копируется, что бы не было возможности "повредить" исходный. В вашем подходе не надо массив копировать, вы просто бегаете по индексам.
Звёздочка (*) это классно, if() - есть, тоже хорошо, у вас получается свой Domain-specific language написан. Если у вас такой богатый функционал, то почему нет статьи ? Пишите, почитаем.
Проблема с вашим DSL только в том, что нет поддержки от IDE, то есть ноль защиты от опечаток и нет статического анализа, но если строчка входит на экран без переносов, то и не беда.
Я как раз и хотел уйти от сплошных длинных строчек, мне надо было побить строчку на части.
Писать ifEmpty руками это точно не мой способ, всегда стремлюсь к максимальной автоматизации.
И вы упускаете возможность перебрать все элементы массива, вот этот 0 он же означает, что там может быть 0 .. 100500 элементов, вашим способом придётся строчку клеить, писать лишний foreach , у меня можно перебирая вложенные элементы смотреть на индекс элемента (имя элемента) и от этого применять разные обработки через switch{case:} совсем другой подход к работе с массивами.
$data = (new AdvancedArrayFactory())->makeAdvancedArray($response);
$members = $data
->pull("response")
->pull("GeoObjectCollection")
->pull("featureMember");
foreach($members->arrays() as $index => $dataset)
{
foreach($dataset->arrays() as $name => $object)
switch($name)
{
case 'GeoObject':
/* обработчик для GeoObject */
if($object->has('metaDataProperty')){
$metaDataProperty = $object->get('metaDataProperty')->asIs()
/* что то делаем с $metaDataProperty */
}
break;
case 'SpatialObject':
/* обработчик для SpatialObject */
break;
}
}
что мы тут сделали ? перебрали все элементы-массивы внутри "featureMember", для каждого "объекта" обработали его свойства соответствующим обработчиком.
Если каких то элементов нет, то ни чего не сломается, код просто проедет мимо, будет работать дальше.
Для такого использования написана моя библиотека, не для того что бы какие то конкретные элементы получить. Получить элемент и поработать с его внутренностями - вот так надо :)
Вполне может быть так, что способ обработки элемента зависит от его типа. У PHP сплошь и рядом надо проверять, что вернулся не false :) Разработчики API тоже могут такие приколы у себя реализовать.
Библиотека была написана для одного сценария использования, потом просто была расширена всем подряд, что бы решать вообще все задачи.
Такой подход реализован в Typed, и в принципе это стандартный способ записи, только вопросики ни кто не пишет, и так понятно, что элемента может не быть.
Но у моей библиотеки другое назначение, я не просто получаю значение, я его ещё и анализирую, было не было, и если было, то какого типа. Редкий сценарий использования, но как то с моим универсальным подходом получилось так. У Typed более практичный подход.
По этой выгрузке, заказчик проверил, ему подошло, были бы замечания - были бы доработки. Можно строить вложенность по иерархии муниципалитетов, одну табличку на другую поменять, и всех дел.
Индексы у домов, дома не образуют между собой иерархии, они просто нижний слой в адресных объектах, поэтому ни какой вложенности, "многоуровневости" по индексам не возможно получить. Мне в выборке для населённого пункта надо было хотя бы какой то получить, можете доработать выборку своим алгоритмом, брать не min(), брать max(), написать case любой сложности или обойтись if, дело ваше.
Приведённое решение не единственно верное, а только пример для ваших собственных решений.
Если вам для импорта БД из XML файлов не нужен PHP, если вы легко пишите хранимки, то пожалуйста поделитесь своими наработками. Для того статьи и пишутся. что бы обмениваться опытом.
допустим. смотрим следующий кейс - добавление доска на 1 гиабайт, добавить меньше интерфес панели не позволяет :)
/dev/vdb1 988M 24K 921M 1% /mnt/experimental
1 гигабайт это 1024 мегабайта, тут сайз 988, 1024-988=36 мегабайт, я не ошибся ? где они ? Я думаю их линукс захомячил на свои служебные нужды. Но много конечно, помниться когда то весь объём HDD был 20 мегабайт :) году так в 1985-ом.
У меня не такое лаконичное решение, мое решение более ООП, в силу мои религиозных убеждений. Статичные методы для меня это прямо крайний случай, процедуры (в php это function) - за гранью добра и зла.
Автор у вас проблемы не с ООП, а с требованиями к коду. Если код должен что то безопасно сделать, то вы в своём коде должны эту безопасность обеспечить.
У вас требование безопасности есть, а в коде выполнения этого требования нет.
Если мы должны атомарно обновить значение при выполнении какого условия, то код который выполняет это обновление должен выполнять его атомарно, то есть проверить что условие выполнилось и только в этом случае проводить обновление значения.
В SQL для этого делается блокировка записи через SELECT FOR UPDATE, или можно делать апдейт на конкретное значение, с проверкой того что текущее значение не изменилось:
UPDATE balance SET amount=150 WHERE amount=200 and user_id=123
Как то так надо выполнчть изменение данных. Если это переменнная в памяти, или байты в файле, то изменение значения надо выполнять с аналогичными проверками. Условие выполняется ? Да - тогда обновляем. А что бы ни какой другой поток переменную не поменял используем блокировки, вы это прекрасно знаете.
ООП это метод. Вы его применяйте с учетом всех требований и программа будет работать как надо.
А если ваш код не обеспечивает атомарности, то пеняйте сами на себя, а не на ООП.
ООП это только способ установить границы того как можно изменять данные, ООП это подсказка программисту какие операции над данными можно выполнить. ООП не говорит нам как эти операции должны быть выполнены.
Вообще поэтому объекты и нельзя использоаать как DTO, именно поэтому мы должны сказать объекту: уменьши баланс на 50, если текущий баланс 200. И объект сам разберется как ему это сделать атомарно с транзакционной целостностью.
Говорить объекту: установи баланс 150, это значит брать на себя ответственность за то что баланс должен быть 150. Когда вы так используете объект, то это не ООП, это процедурное императвное программирование.
я пишу на том на что есть спрос. могу писать на чём угодно, коммерческий опыт: C, C#, Python, Go, Delphi, SQL, JS.
И сайтики я клепать не умею, я умею клепать учётный системы, что я умею можно у меня в профиле посмотреть и по статьям догадаться :)
Восемь месяцев ищу работу (общий стаж 20+ лет, из них в разработке 15), за это время выходил на испытательный срок 4 раза. Первые два раза с очень низкой зп в шарашкины конторы, за место не держался. Потом была была интересная фирма, с организационным уровнем шарашкиной конторы, даром что 400 сотрудников и филиалы в каждой стране СНГ, отдел разработки всего 10 человек. С директором разошлись в оценке продуктивности моей работы, уволился.
И последнее место это что то с чем то, вышел на испытательный и через 3 дня меня уволили, по причине того что со мной сложно общаться, при этом ни споров ни каких то конфликтов не было (или были и я не заметил?), была пара созвонов с аналитиком по часу, то есть вот как ?
Моё мнение такое что "адеватным" работодателям сотрудники не нужны. И на рынке сотрудников ищут только шарашкины конторы у которых процессы не поставлены и они в этом не видят проблемы. Принятие решений и оценка результатов у них соответствующая.
Мы с ними друг другу не подходим. Поэтому я сижу на фрилансе, на хлеб с маслом мне хватает, но я скучаю по колбасе 😁 и по фирмам с отлаженными процессами постановки и приёмки задач.
Спасибо за то что разложили по полочкам. Теперь у меня,есть выбор: формулироватьь попроще или по сложней. Побольше контекста держать в голове или поольше контекста изложить на бумаге
Автор ругает всех. Ни похвалил ни разу ни кого. Где решения, автор ?
Решение по статье размазано, но вывод то надо было оформить.
На деле получилось, что статья это подводка к книжке 😁
Очень не хватает резюме из все сказанного
1 Любите свой организм, это ваш главный инструмент для решения все задач. Дайте себе отдохнуть, дайте себе подумать
2 Не ленитесь погрузиться в проблему и подумать о побочных последствиях возможных решений, играйте в долгую, если вы владелец бизнеса, поощряйте своих сотрудников играть в долгую, если ваш бизнес вам дорог.
Проблема то современного мира в том, что управление бизнесом отданно в руки посторонних людей, которые ни чем не рискуют, если угробят бизнес. Ни кто не хочет париться, ни владельцы, ни директора. А если они не хотят париться, то почему это парит автора?
Спасибо за добрые слова. Назойливость не вызывает ни чего кроме отвращения. Ни какого привлечения этой назойливостью не добиться.
Автор, вы не умеете в ООП. ООП создает границы, ООП принуждает для обработки данных использовать ограниченный набор методов, а не все что взбредет в голову. ООП задает направление для мысли.
Автору могу посоветоват смотреть старые видео Егора Бугаенко и почитать побольше статей с разбором SOLID.
Почему SOLID ? Потому что SOLID это про уменьшение сложности отдельных частей программы, про то как расширять программу, так чтобы не создавать багов в старом функционале.
Еще хорошая книжка "Совершенны код". Главная мысль книжки в том, что код должен быть максимально примитивным, требовать минимального погружения в контекст. И классы с ограниченым набором методов этл именно то что позволяет писать программы с минимальным контекстом.
Применение наследования по 10 поколений это не тру ООП, тру ООП это использование композиции классов, это зависимости от интрфейсов и максимальное использование абстрактных классов.
ООП это не один класс на все случаи жизни, ООП это как микросервисы, сотни мелких классов, заточенных вы решение ровно одной задачи. В их гранулярности и композиции вся сила ООП.
ООП это задать правила системы, создать объект и пойти пить чай 😁 ООП это декларативное програмирование. И сама большая проблема ООП, это как писать в тру ООП стиле так , чтобы тебя не уволили. Потому что прелести этих сотен интерфейсов и фабрик мало кто оценит.
ООП это всегда оабота на будущее, которого не видят люди не способные видеть дальше собственного носа.
Когда я написал статью с аналогичным смыслом мне влепили 50 минусов.
Про fixup слышу первый раз, думаю эта фишка не давно появилась. Идея красивая, все камиты с почеркушками слепляем в один камит вместе с камитом где мы эти почеркушки стерли. И всё шито крыто 👍
Спросите меня как написать статью и получить десятки минусов - я вас научу. Мои статьи стабильно огребают -20 .. -50.
Промежуточных вариантов не бывает. Или слабый интерес отщепенцов с 0..+4 или всеобщее осуждение до -50 😁
Дело то в том что Хабр это тоталитарное сообщество, ты или думаешь как все или тебя здесь не любят. Что понятно,все программисты фанатики, по другому быть и не могло 😁
Поэтому стстему Кармы надо убирать и заменить на систему лайков и дизлайков как на Ютубе.
Мне в целом не понятно зачем эта карма нужна ? Люди всё равно имеют фильтры на статьи +10 (или сколько там по умолчанию). Ну будет кто то постить статьи с минусами и ? В чем ущерб для кого ?
Очень жаль, что слизней убрали. Я один раз всего воспользовался такой возможностью, но для меня это был единственный способ.
За супер полезные лично мне статьи голосую добавлением в фэйворится, то есть в закладки.
Проблема со слизнями была в том, что чтоьбы проголосовать, надо залогиниться, а я хабр читаю по ВК, статьи открываются во внутренем браузере, что бы в хроме открыть, надо перейти по какой то ссылке, потом только появляется возможность открыть во внешнем браузере (если читаешь с телефона).
С десктопа я хабре не читаю уже года три как.
Так что слизни классная тема была, но особенности приложения ВК для смартфонов создавали большие трудности для использования этойфичи.
Жаль что убрали.
Объект обёртка создаётся над массивом, конструктор принимает не json-строку, а уже распашеный массив.
Дать json и сказать распарки кусочек - так не получиться.
С symfony serialiser не сравнивал, не в курсе. Но думаю у серилайзера назначение другое, не думаю, что сериалайзер выдаст элемент без приведения типа и выдаст реальный тип элемента, и позволит проверить итоговое значение является подставленным значением по умолчанию или исходное значение такое и было.
Мой пакет предназначен для анализа исходного значения, не только для конвертации в заданный тип.
Мой пакет не является заменой чему либо, у него своя судьба :) своё предназначение, зачем его качают 300 раз в месяц для меня загадка. Из 500 скачиваний в месяц 200 установок это хвосты от установки другого моего пакета, для работы с XML. И тут тоже для меня загадка зачем качать пакет для работы с XML, когда есть более популярные аналоги.
На счёт скорости работы спорно, у меня каждый шаг обработки создаётся новый экземпляр в который передаётся каждый раз новый массив, он прямо копируется, что бы не было возможности "повредить" исходный. В вашем подходе не надо массив копировать, вы просто бегаете по индексам.
Звёздочка (*) это классно, if() - есть, тоже хорошо, у вас получается свой Domain-specific language написан. Если у вас такой богатый функционал, то почему нет статьи ? Пишите, почитаем.
Проблема с вашим DSL только в том, что нет поддержки от IDE, то есть ноль защиты от опечаток и нет статического анализа, но если строчка входит на экран без переносов, то и не беда.
Я как раз и хотел уйти от сплошных длинных строчек, мне надо было побить строчку на части.
Писать
ifEmptyруками это точно не мой способ, всегда стремлюсь к максимальной автоматизации.И вы упускаете возможность перебрать все элементы массива, вот этот
0он же означает, что там может быть 0 .. 100500 элементов, вашим способом придётся строчку клеить, писать лишнийforeach, у меня можно перебирая вложенные элементы смотреть на индекс элемента (имя элемента) и от этого применять разные обработки черезswitch{case:}совсем другой подход к работе с массивами.что мы тут сделали ? перебрали все элементы-массивы внутри "featureMember", для каждого "объекта" обработали его свойства соответствующим обработчиком.
Если каких то элементов нет, то ни чего не сломается, код просто проедет мимо, будет работать дальше.
Для такого использования написана моя библиотека, не для того что бы какие то конкретные элементы получить. Получить элемент и поработать с его внутренностями - вот так надо :)
Вполне может быть так, что способ обработки элемента зависит от его типа. У PHP сплошь и рядом надо проверять, что вернулся не false :) Разработчики API тоже могут такие приколы у себя реализовать.
Библиотека была написана для одного сценария использования, потом просто была расширена всем подряд, что бы решать вообще все задачи.
Такой подход реализован в Typed, и в принципе это стандартный способ записи, только вопросики ни кто не пишет, и так понятно, что элемента может не быть.
Но у моей библиотеки другое назначение, я не просто получаю значение, я его ещё и анализирую, было не было, и если было, то какого типа. Редкий сценарий использования, но как то с моим универсальным подходом получилось так. У Typed более практичный подход.
По этой выгрузке, заказчик проверил, ему подошло, были бы замечания - были бы доработки. Можно строить вложенность по иерархии муниципалитетов, одну табличку на другую поменять, и всех дел.
Индексы у домов, дома не образуют между собой иерархии, они просто нижний слой в адресных объектах, поэтому ни какой вложенности, "многоуровневости" по индексам не возможно получить. Мне в выборке для населённого пункта надо было хотя бы какой то получить, можете доработать выборку своим алгоритмом, брать не min(), брать max(), написать case любой сложности или обойтись if, дело ваше.
Приведённое решение не единственно верное, а только пример для ваших собственных решений.
Если вам для импорта БД из XML файлов не нужен PHP, если вы легко пишите хранимки, то пожалуйста поделитесь своими наработками. Для того статьи и пишутся. что бы обмениваться опытом.
допустим. смотрим следующий кейс - добавление доска на 1 гиабайт, добавить меньше интерфес панели не позволяет :)
1 гигабайт это 1024 мегабайта, тут сайз 988, 1024-988=36 мегабайт, я не ошибся ? где они ? Я думаю их линукс захомячил на свои служебные нужды. Но много конечно, помниться когда то весь объём HDD был 20 мегабайт :) году так в 1985-ом.
при маунте метка бы точно так же обрезалась бы, думаю всё равно бы маунт прицепился.
вы если хотите это обсудить то пишите мне в ВК в личку
Подравляю вы изобрели еще один велосипед. Первый такой велосипед изобрел я сам, пятььлет назад.
Я решал аналогичную проблему, написал для этого пару классов, потом код оформил в пакет.
composer require sbwerewolf/language-specific
И статью на Хабр написал.
https://habr.com/ru/articles/522348/
У меня не такое лаконичное решение, мое решение более ООП, в силу мои религиозных убеждений. Статичные методы для меня это прямо крайний случай, процедуры (в php это function) - за гранью добра и зла.
Спасибо за ваш труд. Сколько лет шло на создание курса ?