"Тип данных (тип) — множество значений и операций на этих значениях."
Так как набор операций изменяется, то это уже другой тип.
эта штука не меняет тип String, но она обозначает тип "nullable string" который может быть проассоциирован с переменной. Так же как и int[10] не меняет тип int, а делает новый тип по int и количеству элементов.
Предупреждения — это дань переходному периоду — фактически у этих конкретно типов пока более слабый контроль, но концептуально — это тип. Поэтому и синтаксис такой
Возможно, он просто не успел. В Котлине это сразу было или потом добавили?
Логически правильно тогда либо не позволять создавать объекты такого типа никак кроме как десериализацией (и допустим вручную, но с заполнением всех полей). Либо десериализация возращает тип, который знает, что все поля заполнены. Хотя наверное, так все вообще сложно будет.
Если инициализировать в конструкторе есть гарантия, что в уже созданном объекте не будет null, иначе состояние, когда есть объект и там null — допустимо (в процессе десериализации)
Потому, что вы рассматриваете это как основной кейз
О! Начались песни про то, что мы превратили компьютер, выполняющий миллиарды операций в секунду, в пишущую машинку, не способную стабильно выводить на экран пару символов в секунду
И рынок выбирает именно это — электрон с кучей прослоек, на не какой-нибудь редактор написанный на ассемблере.
Я уже давно давно не работал над проектами (кроме личных) где нужен только один человек. Вы живете в каком-то другом мире — у вас все программирует один человек, он уходит в отпуск точно зная, что нет багов, ведет параллельно документацию описывающую код и не ошибается и быстродействие — единственный критерий эффективности.
А вот Java printf — с этих позиций, похоже, вообще не оценивали.
Если не оценивали за столько лет, может быть нет задач, где это является узким местом?
Невозможно написать быстрый код «оптимизируя узкое место уйдя от SOLID». Это так не работает. То есть да, можно легко перейти от скорости в 0.1% от оптимальной к 1% от оптимальной. А вот уже даже 30%-40% получить, если у вас код в стиле фабрик-фабрик-фабрик сделан — не так-то просто.
А по моему как раз наоборот, если есть SOLID то изменить начинку куска кода не меняя интерфейс проще.
Когда функциональность не меняется а внутренняя структура меняется. Выделение методов, выделение интерфейса, добавление параметра в метод (обработка этого параметра уже не рефакторинг). Перемещение метода из класса в класс и т.д. Вообще можно поискать с примерами.
то в подобном подходе больших проблем не будет
То есть отделение UI от остального нужно только если есть две команды? А я читал что бывают еще проблемы с повторным использованием, например, того же кода с другим UI и автоматизированным тестированием. Даже если пишет один человек.
С моей точки зрения вы правы, SOLID имеет свою цену. Так же как и любое другое повышение уровня абстракции. Переход на языки высокого уровня, СУБД, библиотеки тоже имеют свою цену.
Если бы вы использовали вместо sprintf на C специально написанный для вашего случая код на ассемблере, вероятно, это заняло бы еще меньше ресурсов.
Кстати, думаю, что если на каких-то задачах sprintf является узким местом, там бы код оптимизировали возможно уйдя от SOLID.
Для упрощения кода есть альтернатива переписыванию — рефакторинг. Постепенные маленькие, часто автоматизированные эквивалентные преобразования кода.
Но вот нужно ли нам стремиться любой ценой код, в
котором аккумурированы все эти знания?
Любой ценой не надо.
Нужен ли нам код, позволяющей программе работать, «когда файл находится на дискете, а юзер ее выдернул посреди всего» — в программу для телефона?
Не знаю. Он эта логика так же работает при вытаскивании SD-карты?
И полезна ли работоспособность программы в старых версиях Windows 95 в 2019м году?
Наверное нет, но вопрос, нет ли таких же штучек относящихся в бизнес логике? Вот вы взяли написали многостраничный текст который описывает кусочек кода. Допустим вы указали там все нюансы бизнес логики; допустим, вы абсолютно идеально вносите изменения (не забывая обновить документ и не совершая при этом ошибок) и потом решили его переписать. Так как все люди и людям свойственно ошибаться — вы же можете совершить ошибку при переписывании, а это может привести к разным последствиям зависящим от ошибки.
Кстати, посмотрите на эту статью с более взвешенным подходом к переписыванию с нуля.
Посмотрите примеры — переписывание с нуля, как правило, означает переосмысление задачи и часто вообще новый сегмент рынка — часто без выкидывание старой версии. То есть новый продукт для других людей.
Код, отвечающий за сетевые соединения, вдруг выбрасывает из ниоткуда собственные диалоговые окна; это должно обрабатываться в коде UI.
SRP?
Такие проблемы могут быть исправлены по одной: аккуратным рефакторингом и изменением интерфейсов. Это может сделать один программист работая аккуратно и внедряя свои изменения целиком, никому не мешая. Здесь — тоже про «одного человека». И это — не случайно.
Да он подчеркивает сравнительно небольшую трудоемкость рефакторинга — постепенных изменений структуры без изменения функционала.
"Тип данных (тип) — множество значений и операций на этих значениях."
Так как набор операций изменяется, то это уже другой тип.
эта штука не меняет тип String, но она обозначает тип "nullable string" который может быть проассоциирован с переменной. Так же как и int[10] не меняет тип int, а делает новый тип по int и количеству элементов.
Предупреждения — это дань переходному периоду — фактически у этих конкретно типов пока более слабый контроль, но концептуально — это тип. Поэтому и синтаксис такой
Я думаю, также C# недостаточно плох по сравнению с Котлин тоже. Так что котлину придетбя бороться с C# для которого есть большая поддержка
Почему вы считаете что он читатся легко? Рациональные аргументы?
if (person.PhoneNumber == null)
throw new ArgumentException("Phone number missing entirely");
if (person.PhoneNumber.Number == 0)
throw new ArgumentException("Actual number missing");
if (person.PhoneNumber.Code < 0)
throw new ArgumentException("WTF?");
Лично мне не очень нравится три раза писать и читать одно и то же.
Круглые не считаются?
Это также аргумент чтобы заменить a * 2 на switch(a){ case 1: return 2; case 2: return 4
Потому, что на вопрос "из чего может состоять паттерн?" среди можно ответить "паттерн" — т.е. он как бы определен через самого себя.
Возможно, он просто не успел. В Котлине это сразу было или потом добавили?
Логически правильно тогда либо не позволять создавать объекты такого типа никак кроме как десериализацией (и допустим вручную, но с заполнением всех полей). Либо десериализация возращает тип, который знает, что все поля заполнены. Хотя наверное, так все вообще сложно будет.
Он и относится к типу, просто это тип анонимный. То, что тип реализован атрибутом, это уже детали реализации.
Если инициализировать в конструкторе есть гарантия, что в уже созданном объекте не будет null, иначе состояние, когда есть объект и там null — допустимо (в процессе десериализации)
А как вы определили, что он "абсолютно не читаем", а не просто "непривычен"?
Так я и не говорю, что всегда и везде. Ничего не стоит использовать всегда и везде.
Даже если это так,
это только один из пяти миров.
Это зависит от того, насколько эти места критичны
Потому, что вы рассматриваете это как основной кейз
И рынок выбирает именно это — электрон с кучей прослоек, на не какой-нибудь редактор написанный на ассемблере.
Кто сказал что нельзя? Любые принцыпы можно нарушать, если знаешь зачем.
Я уже давно давно не работал над проектами (кроме личных) где нужен только один человек. Вы живете в каком-то другом мире — у вас все программирует один человек, он уходит в отпуск точно зная, что нет багов, ведет параллельно документацию описывающую код и не ошибается и быстродействие — единственный критерий эффективности.
У меня другие задачи.
je suis hindou.
Если не оценивали за столько лет, может быть нет задач, где это является узким местом?
А по моему как раз наоборот, если есть SOLID то изменить начинку куска кода не меняя интерфейс проще.
Когда функциональность не меняется а внутренняя структура меняется. Выделение методов, выделение интерфейса, добавление параметра в метод (обработка этого параметра уже не рефакторинг). Перемещение метода из класса в класс и т.д. Вообще можно поискать с примерами.
То есть отделение UI от остального нужно только если есть две команды? А я читал что бывают еще проблемы с повторным использованием, например, того же кода с другим UI и автоматизированным тестированием. Даже если пишет один человек.
С моей точки зрения вы правы, SOLID имеет свою цену. Так же как и любое другое повышение уровня абстракции. Переход на языки высокого уровня, СУБД, библиотеки тоже имеют свою цену.
Если бы вы использовали вместо sprintf на C специально написанный для вашего случая код на ассемблере, вероятно, это заняло бы еще меньше ресурсов.
Кстати, думаю, что если на каких-то задачах sprintf является узким местом, там бы код оптимизировали возможно уйдя от SOLID.
Для упрощения кода есть альтернатива переписыванию — рефакторинг. Постепенные маленькие, часто автоматизированные эквивалентные преобразования кода.
Любой ценой не надо.
Не знаю. Он эта логика так же работает при вытаскивании SD-карты?
Наверное нет, но вопрос, нет ли таких же штучек относящихся в бизнес логике? Вот вы взяли написали многостраничный текст который описывает кусочек кода. Допустим вы указали там все нюансы бизнес логики; допустим, вы абсолютно идеально вносите изменения (не забывая обновить документ и не совершая при этом ошибок) и потом решили его переписать. Так как все люди и людям свойственно ошибаться — вы же можете совершить ошибку при переписывании, а это может привести к разным последствиям зависящим от ошибки.
Кстати, посмотрите на эту статью с более взвешенным подходом к переписыванию с нуля.
Посмотрите примеры — переписывание с нуля, как правило, означает переосмысление задачи и часто вообще новый сегмент рынка — часто без выкидывание старой версии. То есть новый продукт для других людей.
SRP?
Да он подчеркивает сравнительно небольшую трудоемкость рефакторинга — постепенных изменений структуры без изменения функционала.
Скорее разбить код на куски которые не будут требовать от человека понимания всего кода, чтобы его изменить — а только конкретного куска.
И да, иногда, человек, который понятия не имеет что делает данный код (без чтения кода) — это я сам через год.
см также Грабли, на которые не стоит наступать
Дошло. Я ожидал либо
x.addTo(animals) либо static AddAnimal(animals, animalToAdd) просто по названию подумал, что функция метод добавляет животных в this
Почему?