Возможно, он просто не успел. В Котлине это сразу было или потом добавили?
Логически правильно тогда либо не позволять создавать объекты такого типа никак кроме как десериализацией (и допустим вручную, но с заполнением всех полей). Либо десериализация возращает тип, который знает, что все поля заполнены. Хотя наверное, так все вообще сложно будет.
Если инициализировать в конструкторе есть гарантия, что в уже созданном объекте не будет null, иначе состояние, когда есть объект и там null — допустимо (в процессе десериализации)
Потому, что вы рассматриваете это как основной кейз
О! Начались песни про то, что мы превратили компьютер, выполняющий миллиарды операций в секунду, в пишущую машинку, не способную стабильно выводить на экран пару символов в секунду
И рынок выбирает именно это — электрон с кучей прослоек, на не какой-нибудь редактор написанный на ассемблере.
Я уже давно давно не работал над проектами (кроме личных) где нужен только один человек. Вы живете в каком-то другом мире — у вас все программирует один человек, он уходит в отпуск точно зная, что нет багов, ведет параллельно документацию описывающую код и не ошибается и быстродействие — единственный критерий эффективности.
А вот Java printf — с этих позиций, похоже, вообще не оценивали.
Если не оценивали за столько лет, может быть нет задач, где это является узким местом?
Невозможно написать быстрый код «оптимизируя узкое место уйдя от SOLID». Это так не работает. То есть да, можно легко перейти от скорости в 0.1% от оптимальной к 1% от оптимальной. А вот уже даже 30%-40% получить, если у вас код в стиле фабрик-фабрик-фабрик сделан — не так-то просто.
А по моему как раз наоборот, если есть SOLID то изменить начинку куска кода не меняя интерфейс проще.
Когда функциональность не меняется а внутренняя структура меняется. Выделение методов, выделение интерфейса, добавление параметра в метод (обработка этого параметра уже не рефакторинг). Перемещение метода из класса в класс и т.д. Вообще можно поискать с примерами.
то в подобном подходе больших проблем не будет
То есть отделение UI от остального нужно только если есть две команды? А я читал что бывают еще проблемы с повторным использованием, например, того же кода с другим UI и автоматизированным тестированием. Даже если пишет один человек.
С моей точки зрения вы правы, SOLID имеет свою цену. Так же как и любое другое повышение уровня абстракции. Переход на языки высокого уровня, СУБД, библиотеки тоже имеют свою цену.
Если бы вы использовали вместо sprintf на C специально написанный для вашего случая код на ассемблере, вероятно, это заняло бы еще меньше ресурсов.
Кстати, думаю, что если на каких-то задачах sprintf является узким местом, там бы код оптимизировали возможно уйдя от SOLID.
Для упрощения кода есть альтернатива переписыванию — рефакторинг. Постепенные маленькие, часто автоматизированные эквивалентные преобразования кода.
Но вот нужно ли нам стремиться любой ценой код, в
котором аккумурированы все эти знания?
Любой ценой не надо.
Нужен ли нам код, позволяющей программе работать, «когда файл находится на дискете, а юзер ее выдернул посреди всего» — в программу для телефона?
Не знаю. Он эта логика так же работает при вытаскивании SD-карты?
И полезна ли работоспособность программы в старых версиях Windows 95 в 2019м году?
Наверное нет, но вопрос, нет ли таких же штучек относящихся в бизнес логике? Вот вы взяли написали многостраничный текст который описывает кусочек кода. Допустим вы указали там все нюансы бизнес логики; допустим, вы абсолютно идеально вносите изменения (не забывая обновить документ и не совершая при этом ошибок) и потом решили его переписать. Так как все люди и людям свойственно ошибаться — вы же можете совершить ошибку при переписывании, а это может привести к разным последствиям зависящим от ошибки.
Кстати, посмотрите на эту статью с более взвешенным подходом к переписыванию с нуля.
Посмотрите примеры — переписывание с нуля, как правило, означает переосмысление задачи и часто вообще новый сегмент рынка — часто без выкидывание старой версии. То есть новый продукт для других людей.
Код, отвечающий за сетевые соединения, вдруг выбрасывает из ниоткуда собственные диалоговые окна; это должно обрабатываться в коде UI.
SRP?
Такие проблемы могут быть исправлены по одной: аккуратным рефакторингом и изменением интерфейсов. Это может сделать один программист работая аккуратно и внедряя свои изменения целиком, никому не мешая. Здесь — тоже про «одного человека». И это — не случайно.
Да он подчеркивает сравнительно небольшую трудоемкость рефакторинга — постепенных изменений структуры без изменения функционала.
Если мы рассматриваем программную абстракцию от аппаратной
Я не очень понял грамматически фразу мы "рассматриваем от" или "программная абстракция от"?
Разговор про абстракции начался с того, зачем они нужны. Вкратце — без них не получится написать кода, но абстракции более высокого уровня нужны чтобы писать его меньше, легче понимать и делать меньше ошибок. ООП позволяет создавать более высокоуровневые абстракции по сравнению с процедурным программированием без ООП.
Ну тогда назовите правильное, на ваш взгляд, определение абстракции в парадигме ООП (ведь мы никуда не уходили из рамок дискуссии, или уже ушли?) и приведите пример из низкоуровневого языка программирования, где существует абстракция.
Пожалуйста ассемблер Mov AX, 5
5 — это число, что есть абстракция, может обозначать и 5 баранов и 5 программистов и уровень какого-то сигнала
Там где вы, например, не учитываете тот или иной регистр используемый в текущей программе.
Регистр это тоже абстракция — ваш код может исполняться внутри ВМ и вообще ассемблер транслируется в микрокод.
А кто-то писал про ее необходимость в такой именно реализации?
Никто не писал. Никакой необходимости нет, просто в одном языке есть возможность сделать высокоуровневую абстракцию а в другом языке только низкоуровневую. Соотвественно в одном языке это можно выделить в отдельный кусок, переиспользовать его и понять один раз, в другом придется писать и читать понимать несколько копий одного и того же. Как у того народа где "камень у воды" и "камень в лесу" — это разные понятия.
Для начала перечитайте приведенное вами определение языка, в котором ни слова про «другой» язык не было.
Вполне возможно я не совсем точно выразился, но мы вроде достигли понимания того, что я имел ввиду.
В указанном мной варианте есть словосочетание «способность увеличения». Пожалуйста, будьте внимательнее! Из курса школьной физики F=am -> a=F/m, F = const, так как «для неизменного тягового организма». Можете предложить свой вариант, с точки зрения физики.
Я не так хорошо разбираюсь в кобылах, я просто сказал, что в исходной поговорке не содержится этого утверждения. Может скорость кобылы чем-то ограничена сверху и она не может конвертировать облегчение в ускорение. )
сим откланиваюсь, ибо дальнейшую дискуссию, в ключе постоянного расширения ее рамок в одностороннем порядке, и при невнимательности к аргументации оппонента, считаю нецелесообразной.
Потому, что на вопрос "из чего может состоять паттерн?" среди можно ответить "паттерн" — т.е. он как бы определен через самого себя.
Возможно, он просто не успел. В Котлине это сразу было или потом добавили?
Логически правильно тогда либо не позволять создавать объекты такого типа никак кроме как десериализацией (и допустим вручную, но с заполнением всех полей). Либо десериализация возращает тип, который знает, что все поля заполнены. Хотя наверное, так все вообще сложно будет.
Он и относится к типу, просто это тип анонимный. То, что тип реализован атрибутом, это уже детали реализации.
Если инициализировать в конструкторе есть гарантия, что в уже созданном объекте не будет null, иначе состояние, когда есть объект и там null — допустимо (в процессе десериализации)
А как вы определили, что он "абсолютно не читаем", а не просто "непривычен"?
Так я и не говорю, что всегда и везде. Ничего не стоит использовать всегда и везде.
Даже если это так,
это только один из пяти миров.
Это зависит от того, насколько эти места критичны
Потому, что вы рассматриваете это как основной кейз
И рынок выбирает именно это — электрон с кучей прослоек, на не какой-нибудь редактор написанный на ассемблере.
Кто сказал что нельзя? Любые принцыпы можно нарушать, если знаешь зачем.
Я уже давно давно не работал над проектами (кроме личных) где нужен только один человек. Вы живете в каком-то другом мире — у вас все программирует один человек, он уходит в отпуск точно зная, что нет багов, ведет параллельно документацию описывающую код и не ошибается и быстродействие — единственный критерий эффективности.
У меня другие задачи.
je suis hindou.
Если не оценивали за столько лет, может быть нет задач, где это является узким местом?
А по моему как раз наоборот, если есть SOLID то изменить начинку куска кода не меняя интерфейс проще.
Когда функциональность не меняется а внутренняя структура меняется. Выделение методов, выделение интерфейса, добавление параметра в метод (обработка этого параметра уже не рефакторинг). Перемещение метода из класса в класс и т.д. Вообще можно поискать с примерами.
То есть отделение UI от остального нужно только если есть две команды? А я читал что бывают еще проблемы с повторным использованием, например, того же кода с другим UI и автоматизированным тестированием. Даже если пишет один человек.
С моей точки зрения вы правы, SOLID имеет свою цену. Так же как и любое другое повышение уровня абстракции. Переход на языки высокого уровня, СУБД, библиотеки тоже имеют свою цену.
Если бы вы использовали вместо sprintf на C специально написанный для вашего случая код на ассемблере, вероятно, это заняло бы еще меньше ресурсов.
Кстати, думаю, что если на каких-то задачах sprintf является узким местом, там бы код оптимизировали возможно уйдя от SOLID.
Для упрощения кода есть альтернатива переписыванию — рефакторинг. Постепенные маленькие, часто автоматизированные эквивалентные преобразования кода.
Любой ценой не надо.
Не знаю. Он эта логика так же работает при вытаскивании SD-карты?
Наверное нет, но вопрос, нет ли таких же штучек относящихся в бизнес логике? Вот вы взяли написали многостраничный текст который описывает кусочек кода. Допустим вы указали там все нюансы бизнес логики; допустим, вы абсолютно идеально вносите изменения (не забывая обновить документ и не совершая при этом ошибок) и потом решили его переписать. Так как все люди и людям свойственно ошибаться — вы же можете совершить ошибку при переписывании, а это может привести к разным последствиям зависящим от ошибки.
Кстати, посмотрите на эту статью с более взвешенным подходом к переписыванию с нуля.
Посмотрите примеры — переписывание с нуля, как правило, означает переосмысление задачи и часто вообще новый сегмент рынка — часто без выкидывание старой версии. То есть новый продукт для других людей.
SRP?
Да он подчеркивает сравнительно небольшую трудоемкость рефакторинга — постепенных изменений структуры без изменения функционала.
Скорее разбить код на куски которые не будут требовать от человека понимания всего кода, чтобы его изменить — а только конкретного куска.
И да, иногда, человек, который понятия не имеет что делает данный код (без чтения кода) — это я сам через год.
см также Грабли, на которые не стоит наступать
Дошло. Я ожидал либо
x.addTo(animals) либо static AddAnimal(animals, animalToAdd) просто по названию подумал, что функция метод добавляет животных в this
Почему?
ok. Опишите свой подход к дизайну, пожалуйста
Я не очень понял грамматически фразу мы "рассматриваем от" или "программная абстракция от"?
Разговор про абстракции начался с того, зачем они нужны. Вкратце — без них не получится написать кода, но абстракции более высокого уровня нужны чтобы писать его меньше, легче понимать и делать меньше ошибок. ООП позволяет создавать более высокоуровневые абстракции по сравнению с процедурным программированием без ООП.
В ФП есть, кстати, тоже свои способы.
Пожалуйста ассемблер Mov AX, 5
5 — это число, что есть абстракция, может обозначать и 5 баранов и 5 программистов и уровень какого-то сигнала
Регистр это тоже абстракция — ваш код может исполняться внутри ВМ и вообще ассемблер транслируется в микрокод.
Никто не писал. Никакой необходимости нет, просто в одном языке есть возможность сделать высокоуровневую абстракцию а в другом языке только низкоуровневую. Соотвественно в одном языке это можно выделить в отдельный кусок, переиспользовать его и понять один раз, в другом придется писать и читать понимать несколько копий одного и того же. Как у того народа где "камень у воды" и "камень в лесу" — это разные понятия.
Вполне возможно я не совсем точно выразился, но мы вроде достигли понимания того, что я имел ввиду.
Я не так хорошо разбираюсь в кобылах, я просто сказал, что в исходной поговорке не содержится этого утверждения. Может скорость кобылы чем-то ограничена сверху и она не может конвертировать облегчение в ускорение. )
Как угодно