передаю отдельный "привет" питонщикам с ихним бл$дь self через слово)
:) Так и питонщики сами тихо офигевают, когда видят чей-то код, загаженный классами там, где реально нет никаких классов. Прочитай тут статью "Перестаньте писать классы", например.
Все так. Классы нужно/можно использовать только там, где есть реально динамическое число объектов одного рода, имеющих свои данные. Если это разделение функционала, то это банальный отдельный модуль (без всяких классов).
Так в том и смысл, чтобы минимизировать связанность. Тестировать нужно отдельно сам модуль.
А про текст ниже -- не понял вопрос. У нас тут никаких объектов нет, есть использование функционала из внешнего модуля. Импортируем модуль, вызываем file_worker.save_all(_данные_нашего_компонента), где ошибку получаем через res/err = file_worker.save_all, либо try cach, в зависимости от языка и реализации.
Да, но с каждым проектом набираешь же опыт и становишься более эффективным, не теряя время на размышление/проектирование странных, ненужных и неуместных вещей, которые не привносят ничего полезного. Либо наоборот, заранее понимая, куда нужно подстилать соломку.
Я могу сравнивать только время и усилия, которые были затрачены, не думаю что это показатель чего-либо.
Почему не показатель? Вполне себе показатель. Не все могут реально сравнивать подходы. Делают лишь "потому что так надо". Или не умеют по-другому. Или язык "заставляет".
А ты (как заказчик и разработчик в одном лице) можешь оценить и время разработки, и ментальную нагрузку на проектирование, написание и сопровождение кода.
споры про класс собаки и то как именно работать с её лаем и очень хорошо видно что даже те кто пользуется ООП (или так думает) не имеют консенсуса.
Именно. :)
Если я хочу вывести на экран "bark", то я это делаю, мне не нужен класс или метод для этого.
Эх, а мог бы создать бригаду строителей, приставил бы к ним наблюдателя. Они бы построили абстрактную фабрику по производству различных прототипов собачек, которые умеют разное. Лаять, прыгать, кусать, писать код. Написал бы адаптер для собачек, чтобы они умели лаять на экран.
В общем, вот это вот все делать... Лишь бы не работать. :)
Это уже модульная архитектура. Функционал сгруппирован по отдельным модулям. Не нужен никакой "один объект" какого-то там класса.
Второй повод применения ООП
Да, я бы чуть упростил формулировку до "при написании UI интерфейсов". Вот там все по полной программе раскрывается.
Третий способ (который так и не понял)
... Если это "записи" без поведения, вопросов нет.
Для работы с данными вообще лучше функциональный подход. На входе "запись" и на выходе "запись". И ряд функций, работающих с этими данными, которые можно группировать как угодно в конвейеры.
Если данные с поведением, не представляю как это сделать не усложнив все неимоверно. Если кто-то умеет, можете описать.
А часто -- никак, просто потому, что это не имеет никакого смысла. :) Начинаются фантазии на тему -- это комната добавляет в себя собаку, или собака добавляется сама в комнату. И потом никогда не разберешься "кто нам ком стоял", и почему хвост виляет собакой.
По факту мы имеем замаскированное под ООП обычное процедурное программирование с модулями
Ха. :) То же самое как раз выше написал. :)
А вот что реально дает другой экспириенс, так это частичное использование функционального подхода (как же приятно читается потом что-то типа res -> func1 func2 func3, если у нас есть объект (в виде данных) и серия операций над этим объектом).
Да нет, все ты правильно понимаешь. :) Когда ты пишешь для себя, сам же и поддерживаешь, то лучше замечаешь все плюсы и минусы подходов. И тебе сложнее голову задурить, если ты сам попробовал и так, и сяк, и можешь сравнивать.
Просто часто ООП используется как способ упаковки обычного процедурного кода в дикую лапшу, где ненужные абстракция на абстракции и абстракцией погоняет. А в нейтральных случаях это просто имитация модульного разделения функционала. :)
К счастью, не все языки заставляют такое упаковывать в классы. :) Для подавляющего числа случаев тут логичнее выделять функционал в МОДУЛЬ, а не чесать левое ухо правой рукой (статические классы / синглтоны).
А вот если по смыслу у нас есть реальные объекты (множественное число), тогда и классы использовать.
О да! :) После Х лет на Питоне возвращался к Си, чтобы прошивку написать для esp8266. Ох как я плевался первые дни, снова "перекладывая байтики/строки". Такое ощущение траты времени... Как будто пришлось тонны текста набирать на экране телефона одним пальцем.
Ха. А я думал тут будет про то, как надо плавно менять подход к обучению и тренировкам с возрастом, где 25 -- это примерный ориентир, после которого старые схемы работают не эффективно. Andrew Huberman очень интересно рассказывает про нейропластичность, alertness, фокусировку и все остальное. Можно искать его подкасты по наличию слова SKILLS, насколько я помню. Хотя там большинство очень полезных.
С чего ему садиться? :) Там наоборот глаза работают, фокусное расстояние всегда меняется. А при мониторе/книжке/телефоне -- наоборот, фиксируется на одной дистанции.
Подтверждаю. Для нормальной работы с текстами необходимо два момента.
1) Достаточное разрешение. Это когда виртуальную книжку можно вертеть в руках и читать. Не, ну есть какие-то супер-профессиональные VR устройства для такого, но вот в Quest 2 разрешения не достаточно. Решительно ничего нельзя там разобрать. Не хватает "виртуальных DPI".
2) Четкость пикселей не только по центру, но и по краям экрана. Т.е. нужен именно такой тип линз, не дающий искажений по краям. Иначе нужно постоянно двигать головой, "наводясь" на текст.
Помню, пока картинке еще очень ярко и сочно выглядит "I Expect You To Die". А если взять не только VR игры, а игры на UE 4.xx/5 и UEVR Injector и мощный комп, то выбор становится несравнимо бОльшим.
Плюсую. Это все отмазки, мол, контроллеры вам больше не нужны. Есть куча сценариев, где только контроллер даст возможность получить нормальный интерфейс работы. Там есть тактильный отклик нажатия, возможность удерживать/отпускать. И это все при расслабленных руках, а не "кастуя" в воздухе перед камерой. :) А еще и можно фидбек осуществлять через контроллер той же вибрацией.
А для меня Q2 с родными лямками был вообще ужасом. Вроде бы, даже меньше, чем через полчаса мне дико надавливало (даже при минимально возможном натяжении ремешка), аж от боли в районе лица/висков пульсировало. :)
BOBOVR M2 -- это не просто дополнение, это просто необходимый элемент. А шея, кстати, и не устает. Ну или я подзабыл уже. Давно уже не использовал его так длительно.
Серая пленка? А насколько темная? У меня в зале зеленая, а в спальне синяя. Для интереса планшет поднес под полоток, посмотрел на качество изображения. На удивление, даже неплохо отражает. Но что-то мне кажется, что оно будет все ну очень смазанное.
Ха... Вопрос отменяется. Проверил YouTube. Кто-то даже эту пленку как экран использует, а кто-то тоже на потолок направил. Может оно и будет интересно. Но "проверять я это, конечно же, не буду" (с) :)
Так лечь на спину да смотреть. Не просмотр а мечта )))
Ну это вполне обычный use case. Я так youtube иногда смотрю в Quest 2, чтобы шею расслабить. Вчера зачем-то смотрел про кодинг на ассемблере под ARM (ну оно само попалось). :) Но картинка не идеальная в квесте. Если близко приблизить, сделать большим экран, то края смазываются. А если отдалить, то не хватает виртуальных DPI, теряются детали.
:) Так и питонщики сами тихо офигевают, когда видят чей-то код, загаженный классами там, где реально нет никаких классов. Прочитай тут статью "Перестаньте писать классы", например.
Все так. Классы нужно/можно использовать только там, где есть реально динамическое число объектов одного рода, имеющих свои данные. Если это разделение функционала, то это банальный отдельный модуль (без всяких классов).
Так в том и смысл, чтобы минимизировать связанность. Тестировать нужно отдельно сам модуль.
А про текст ниже -- не понял вопрос. У нас тут никаких объектов нет, есть использование функционала из внешнего модуля. Импортируем модуль, вызываем file_worker.save_all(_данные_нашего_компонента), где ошибку получаем через res/err = file_worker.save_all, либо try cach, в зависимости от языка и реализации.
Да, но с каждым проектом набираешь же опыт и становишься более эффективным, не теряя время на размышление/проектирование странных, ненужных и неуместных вещей, которые не привносят ничего полезного. Либо наоборот, заранее понимая, куда нужно подстилать соломку.
Почему не показатель? Вполне себе показатель. Не все могут реально сравнивать подходы. Делают лишь "потому что так надо". Или не умеют по-другому. Или язык "заставляет".
А ты (как заказчик и разработчик в одном лице) можешь оценить и время разработки, и ментальную нагрузку на проектирование, написание и сопровождение кода.
Именно. :)
Эх, а мог бы создать бригаду строителей, приставил бы к ним наблюдателя. Они бы построили абстрактную фабрику по производству различных прототипов собачек, которые умеют разное. Лаять, прыгать, кусать, писать код. Написал бы адаптер для собачек, чтобы они умели лаять на экран.
В общем, вот это вот все делать... Лишь бы не работать. :)
Это уже модульная архитектура. Функционал сгруппирован по отдельным модулям. Не нужен никакой "один объект" какого-то там класса.
Да, я бы чуть упростил формулировку до "при написании UI интерфейсов". Вот там все по полной программе раскрывается.
Для работы с данными вообще лучше функциональный подход. На входе "запись" и на выходе "запись". И ряд функций, работающих с этими данными, которые можно группировать как угодно в конвейеры.
А часто -- никак, просто потому, что это не имеет никакого смысла. :) Начинаются фантазии на тему -- это комната добавляет в себя собаку, или собака добавляется сама в комнату. И потом никогда не разберешься "кто нам ком стоял", и почему хвост виляет собакой.
Ха. :) То же самое как раз выше написал. :)
А вот что реально дает другой экспириенс, так это частичное использование функционального подхода (как же приятно читается потом что-то типа res -> func1 func2 func3, если у нас есть объект (в виде данных) и серия операций над этим объектом).
Или closure (~LISP). Прогонять данные через цепочку функций для мозга тоже намного логичней. https://habr.com/ru/articles/761326/comments/#comment_25970952
Да нет, все ты правильно понимаешь. :) Когда ты пишешь для себя, сам же и поддерживаешь, то лучше замечаешь все плюсы и минусы подходов. И тебе сложнее голову задурить, если ты сам попробовал и так, и сяк, и можешь сравнивать.
Просто часто ООП используется как способ упаковки обычного процедурного кода в дикую лапшу, где ненужные абстракция на абстракции и абстракцией погоняет. А в нейтральных случаях это просто имитация модульного разделения функционала. :)
К счастью, не все языки заставляют такое упаковывать в классы. :) Для подавляющего числа случаев тут логичнее выделять функционал в МОДУЛЬ, а не чесать левое ухо правой рукой (статические классы / синглтоны).
А вот если по смыслу у нас есть реальные объекты (множественное число), тогда и классы использовать.
О да! :) После Х лет на Питоне возвращался к Си, чтобы прошивку написать для esp8266. Ох как я плевался первые дни, снова "перекладывая байтики/строки". Такое ощущение траты времени... Как будто пришлось тонны текста набирать на экране телефона одним пальцем.
Вот, кстати, NIM как раз хорош тем, что можно записать и так и так:
len(L)
L.len()
и даже:
len L
Выбираешь тот вариант, который лучше с точки зрения читаемости кода именно в данном контексте.
Ха. А я думал тут будет про то, как надо плавно менять подход к обучению и тренировкам с возрастом, где 25 -- это примерный ориентир, после которого старые схемы работают не эффективно. Andrew Huberman очень интересно рассказывает про нейропластичность, alertness, фокусировку и все остальное. Можно искать его подкасты по наличию слова SKILLS, насколько я помню. Хотя там большинство очень полезных.
С чего ему садиться? :) Там наоборот глаза работают, фокусное расстояние всегда меняется. А при мониторе/книжке/телефоне -- наоборот, фиксируется на одной дистанции.
Подтверждаю. Для нормальной работы с текстами необходимо два момента.
1) Достаточное разрешение. Это когда виртуальную книжку можно вертеть в руках и читать. Не, ну есть какие-то супер-профессиональные VR устройства для такого, но вот в Quest 2 разрешения не достаточно. Решительно ничего нельзя там разобрать. Не хватает "виртуальных DPI".
2) Четкость пикселей не только по центру, но и по краям экрана. Т.е. нужен именно такой тип линз, не дающий искажений по краям. Иначе нужно постоянно двигать головой, "наводясь" на текст.
Помню, пока картинке еще очень ярко и сочно выглядит "I Expect You To Die". А если взять не только VR игры, а игры на UE 4.xx/5 и UEVR Injector и мощный комп, то выбор становится несравнимо бОльшим.
Плюсую. Это все отмазки, мол, контроллеры вам больше не нужны. Есть куча сценариев, где только контроллер даст возможность получить нормальный интерфейс работы. Там есть тактильный отклик нажатия, возможность удерживать/отпускать. И это все при расслабленных руках, а не "кастуя" в воздухе перед камерой. :) А еще и можно фидбек осуществлять через контроллер той же вибрацией.
А для меня Q2 с родными лямками был вообще ужасом. Вроде бы, даже меньше, чем через полчаса мне дико надавливало (даже при минимально возможном натяжении ремешка), аж от боли в районе лица/висков пульсировало. :)
BOBOVR M2 -- это не просто дополнение, это просто необходимый элемент. А шея, кстати, и не устает. Ну или я подзабыл уже. Давно уже не использовал его так длительно.
Серая пленка? А насколько темная? У меня в зале зеленая, а в спальне синяя. Для интереса планшет поднес под полоток, посмотрел на качество изображения. На удивление, даже неплохо отражает. Но что-то мне кажется, что оно будет все ну очень смазанное.
Ха... Вопрос отменяется. Проверил YouTube. Кто-то даже эту пленку как экран использует, а кто-то тоже на потолок направил. Может оно и будет интересно. Но "проверять я это, конечно же, не буду" (с) :)
Ну это вполне обычный use case. Я так youtube иногда смотрю в Quest 2, чтобы шею расслабить. Вчера зачем-то смотрел про кодинг на ассемблере под ARM (ну оно само попалось). :) Но картинка не идеальная в квесте. Если близко приблизить, сделать большим экран, то края смазываются. А если отдалить, то не хватает виртуальных DPI, теряются детали.