Можно ли возвращать null из функции?
Ну вот, вроде нашел тему для большого базара 
Одни говорят нет, при проблемах бросаем exception или возвращаем null объект.
Другие говорят да, без этого и жить то невозможно.
А есть ли какая то золотая середина?
Можно начать с того, что данная функция просто не имеет права возвращать null
string Get...
А после npex может быть или сразу или где-нибудь в другом месте. То бишь везде нужно делать дополнительные проверки.
Иначе говоря знание того что у клиента нет номера откладывается на неопределённое время, при этом без дополнительных проверок пользователь увидит просто трах тирибах.
Можно начать с того, что данная функция просто не имеет права возвращать null
string Get...
Функция возвращает такс айди, каким бы он неприятным, вонючим, неухоженным ни оказался. Если такс айди налл, надо вернуть налл, а не строить тут из себя...
NullTaxId = "TaxID does not exist";
Кто дал вам право вот так легкомысленно приравнивать простой и лаконичный налл и вот это ваше "сочинение на тему", которое в скобках? А другие в вашей команде знают, чем вы тайком занимаетесь, пока тимлид отвернулся?
Предполагаю, что если прога вылетает, то это именно то что хочет увидеть пользователь
И что? Чем больше вылетает прога, чем больше приходится перезагружать сервер или там ждать коннекта к базе данных, тем больше поводов для кофе-брейка и очень важных обсуждений в переговорках. Перезагружать сервера весело!
А есть ли какая то золотая середина?
Нет никакой золотой середины.
Делать null объект на каждый тип - немного перебор. Вместе с тем использование этого паттерна может облегчить понимание логики и упростить архитектуру.
Как обычно, серебрянных пуль не существует и каждое решение следует использовать там, где это имеет смысл.
то надо как то регламентировать невозможность его введения пользователем
интересное замечание, хотя нигде и не предполагался ручной ввод. Можно например добавить в конец '\0'
Но проблема то не в этом, а в том какой подход выбрать и при каких критериях, если оба варианта допустимы.
Выбор выдачи null просто похоже на привычку от которой трудно отказаться.
Нее, нельзя.Если НУЛЛ - значит - НУЛЛ. т.е. вообще не назнаался.А как его представить как предложено то надо как то регламентировать невозможность его введения пользователем... тем самым дублируя НУЛЛ.
Постепенно этот холивар переходит в соседний: null vs. 0 vs. "" vs. "Тут ничего нет"
серьёзно?
Почему схватились за пример со строкой, а ведь может быть и объект у которого есть проперти.
И почему лучше в каких-то местах проверять на null и не проверять на NullTaxId?
Дело то ведь не в одном конкретном случае, а в "глобальной" проблеме.
Если ты не проверяешь полученное значение
Ну так собственно в этот то и есть проблема.
Проверять х раз на null где только пользуем или на nullObject только там где действительно надо.
А ведь присваивание может происходить в одном месте, а использование в другом и ищи потом откуда там null.
не оборачиваешь вызов в try-catch
тут возникает следующих вопрос. А если указатель используется множество раз зачем его постоянно проверять, не проще ли один раз сказать - "фигвам нету такого ид тута"
И всё сразу ясно, в этом месте проблема возникла. А не ждать когда указатель понадобится, а потом сказать - "получили нулевой указатель".
И почему лучше в каких-то местах проверять на null и не проверять на NullTaxId?
Сколько видел кода - любое введение своих собственных обозначений для "налл", "нуль" и прочего заставляет проверять кроме стандартных обозначений ещё и свои собственные. Т.е. просто прибавляется работы.
Т.е. вместо привычных условных
if (null)
else if (0)
становится
if (null)
else if (0)
else if (empty)
else if (whateverAdditionalDesignation1)
else if (whateverAdditionalDesignation2)
...
Причём все варианты, кроме двух первых, обычно сводятся к двум первым. Т.е. все последующие проверки, кроме двух первых, избыточны.
По-моему, функция возврата айди должна возвращать айди. Если он может быть налловым по типу данных - пусть будет налловым. Функция возврата айди не знает контекста своего вызова (мы же все такие ООП, солиды, банды четырёх и прочие дяди Бобы?), значит контекст должен привноситься где-то снаружи неё - там, где эта функция вызывается. Вот по месту вызова и обрабатывайте этот налл - бросайте исключение (может даже кастомного типа), пишите содержательное сообщение, логируйте и прочее.
Варианты есть? При каких случаях что лучше использовать?
Так с ходу сложно придумать нормальный пример.
Попробую сформулировать так: если null не является ошибкой, то можно подумать над возвратом null объекта.
Например, если у тебя есть фабрика, которая создает объект для доступа к БД, то, в случае если фабрика по какой-то причине не может создать этот объект, нужно возвращать null, т.к. без БД жизни у программы нет :) И чем раньше мы пробросим ошибку наверх, тем лучше.
Если же null - валидный ответ системы, то null объект может оказаться очень полезным. Например, ты ищешь клиента по фамилии. Вбиваешь фамилию, клацаешь "Дальше". Если клиентов с такой фамилией несколько, то появляется список с выбором. Если такой клиент один, то сразу открываются данные клиента. Если клиента нет, то сразу открывается страница для ввода нового клиента. При таком юз-кейсе имеет смысл сделать null объект.
Собственно говоря, объект с дефолтным состоянием по сути и является null объектом. И такой подход используется довольно часто - создаем объект, после чего "подправляем" пару (из 100500) полей и в бой :)
Вбиваешь фамилию, клацаешь "Дальше". Если клиентов с такой фамилией несколько, то появляется список с выбором. Если такой клиент один, то сразу открываются данные клиента.
Зачем так делать? Это лишь запутывает пользователя, нисколько не ускоряет работу. Из-за разного поведения в том или ином случае и невозможности предсказать, какой именно случай будет. Чем более одинаковая работа по всем кейсам, тем больше автоматизма у пользователя вырабатывается. Когда ему может вывалиться то список, то заполненная форма, то пустая форма - ничего не вырабатывается.
Программист думает одно, но он часто ошибается, т.к. не работает со своей программой постоянно. Думает, что сразу показывать единственного пользователя удобно. Нихрена не удобно, если я готовлюсь получить список (руки уже в нужных местах на мыше и клаве, в голове паттерн - куда подвести мышь на следующем экране и нажать).
Зачем так делать?
Это просто пример, когда подход с null объектом становится более оправданным.
Это лишь запутывает пользователя, нисколько не ускоряет работу. Из-за разного поведения в том или ином случае и невозможности предсказать, какой именно случай будет.
Все зависит от конкретного юз-кейса.
Может быть реализовано несколько вывовод поиска.
Например, если было введено 3 или меньше знаков, то пользователь может нажать "Enter" и перейдет к списку.
Если больше 3 знаков то начинает работать всплывающее меню/автозаполнение. При этом если во всплывающем списке больше одного айтема, то по "Enter" будет переход к списку. Если в списке ровно 1 айтем, то редактирование этого айтема. Если же список пуст, то по "Enter" переходим к созданию нового клиента.
Такой подход вполне может сократить количество кликов. Ну и далеко не все и не всегда работают с мышью ;)
этот холивар
ну так с самого начала об этом и говорилось, а то уж сколько времени никаких сообщений вообще не было.
Хоть можно узнать различные точки зрения, тоже иногда полезно
Вот ведь негодяй, сам запретил тут писать о программировании квантовых программ, сам всех разогнал!
А теперь приходит и говорит - а давайте устроим холивары "виндавс против линукса, интел против амд" итдт итп....
*****
По теме нулей, когда блокчейн возвращет нули - это грустно! печально! гораздо веселей когда возвращает числа!
сравните картинки:
это уже бабосиками, так гораздо веселей:
А теперь рассказывайте, как можно зациклить списки : https://foren.germany.ru/showmessage.pl?Number=40889039&Bo...
Вопросы и Ответы - Программируем калькулятор пособий для беженцев вместе.
Сколько видел кода
интересно узнать абсолютные цифры 
Функция возврата айди не знает контекста своего вызова
Судя по тому, что обо всём что в скобках вам глубоко плевать, мне сложно понять что имелось в виду
Зачем обычному мапу что то еще знать?
Вот по месту вызова и обрабатывайте этот налл - бросайте исключение
ну так об этом и идет речь, только похоже вы хотите бросать исключение после вызова функции, а смысл?
Зачем повторять одну и туже работу при каждом вызове функции?
в случае если фабрика по какой-то причине не может создать этот объект, нужно возвращать null
А почему null, а не сразу исключение, тогда сразу всё заткнется без каких то дальнейших шагов.
И чем раньше мы пробросим ошибку наверх, тем лучше.
именно так
Можно ли возвращать null из функции?
Вот ты ж, изобретатели велосипедов...
В шарпе можно. Но не нужно. В хаскеле / sml / tasm нельзя. Да даже в паскале нельзя. Я ответил на твой вопрос? :)
Лично я лично в яве, чтобы сигнализировать отсутствие значения, задекларирую что метод возвращает Optional. Это не хаскеловский Maybe, но тоже можно жить.
В шарпе можно. Но не нужно....Я ответил на твой вопрос?
Не совсем. просто как мнение.
Нужны правила отчего не нужно. Запрещаем вообще или есть какие то исключительные случаи?
Да даже в паскале нельзя.
В каком именно?
https://www.oreilly.com/library/view/delphi-in-a/156592659...
То, что предписано для не назначенного значения.
Скользкий котяра, скользкий 
Есть конкретный пример, ожидается конкретный ответ.
Можно даже сказать - предписано выдать сообщение о конкретной ошибке и выйти из программы. (Пысы: в проге несколько соединений к базам данных)
Предположим обратное...
Получили, что значение объекта базы нулевое, что делаем дальше?
if(db == null) ...
чел, ты не дурачок случаем?
Исключение надо кидать не в мной упомянутой функции, а выше.
Скажем, функция определяет, является ли клиент Местной фирмой или иностранной. Т.к. для этого налоговый номер необходим, то тут сам бог велел кинуть исключение.
А почему null, а не сразу исключение, тогда сразу всё заткнется без каких то дальнейших шагов.
Ну можно и сразу исключение. Зависит от фабрики и от того, что она должна возвразать.
В общем случае фабрика не может знать является ли отсутствие объекта ошибкой. Ну скажем в случае если мы ищем заказ по ID и ничего не можем найти, то это скорее ошибка. А если мы ищем клиента по фамилии (где ID - это фамилия) и не можем найти, то это может оказаться просто новый клиент и никакой ошибки тут нет. Фабрика должна создавать объекты и не должна принимать никаких решений. Плюс к этому поведение фабрики всегда должно быть одинаковым.
Как бы там ни было, это уже детали реализации фабрики и договоренностей между архитекторами.
не скользкий. а опытный...
у тебя есть два субтипа объектов:
- который может не назначаться значением
- обязан иметь значение.
для первого нулл является нормально возвращаемым значением
для второго нулл - ситуация возникающая при ошибке.
Переводить ситуацию из первой во вторую путем введения суррогатного нулл-объекта однотипного со значимым результатом есть дебилизм обыкновенный, менеджерский... т.е. Я предпочту разруливание ситуации на уровне типов, а не значений.
Вопрос об исключениях вообще элементарен
- либо исключения используются для обработки ошибочных ситуаций
- либо они используются для нормального управления логикой программы (да, такое тоже случается)
Соответственно - либо - да, либо - нет.
чел, ты...
Странно, я считал, что вы находитесь в группе людей, умеющих вести цивилизованную дискуссию.
Разве с переходом на личности можно прийти к какому-либо результату?
Получили, что значение объекта базы нулевое… Т.к. для этого налоговый номер необходим
В упор не вижу никакой связи между этими двумя высказываниями.
Ну а если перейти к вашему примеру, то правильно ли я понял, что в одном случае нужно выдавать нулл, а в другом исключение? То есть намеренно делаем поведение функции непредсказуемым, для того кто не в теме.
клиент Местной фирмой или иностранной
почему фирмой? И откуда можно взять что именно определено как местная страна? Это всё видно отсюда? GetTaxIdByCustomerId(int)
не скользкий
еще как, пришлось за хвост дёрнуть, чтобы получить цивилизованный ответ 
В принципе можно было и согласится, но смущает "статистика"
Постоянно попадается что-то типа этого, но ни разу не наоборот.
https://medium.com/javarevisited/just-dont-return-null-dcd...
https://medium.com/@jadhavsid1101/why-returning-null-from-...
по мне так все логично
Функция, возвращающая налоговый номер, выдаёт null, Если он не определён.
почему фирмой? И откуда можно взять что именно определено как местная страна? Это всё видно отсюда? GetTaxIdByCustomerId(int)
если налоговый номер начинается с DE, то фирма местная. Если с какого-то иного кода страны, то иностранная.
Если налогового номера нет, то это исключение.
по мне так все логично
Только потому, что вы вероятно "живете" в этом домене.
А по мне, функция берет на себя слишком много и для этого много нужно смотреть реализацию функции.
Если налогового номера нет, то исключение.
Если налоговый номер не определён, то возвращаем null
Если налоговый номер неправильный, то?
Если фирма иностранная, то исключение.
Если клиент не найден то ?
И по вашему описанию хотелось бы видеть, что то в виде этого
string? GetTaxIdByCustomerId(int customerId, string residentСountryId)
И какое отличие от "номера нет" от "номер не определен"?
А если клиент не фирма?
В принципе можно было и согласится, но смущает "статистика"Постоянно попадается что-то типа этого, но ни разу не наоборот.https://medium.com/javarevisited/just-dont-return-null-dcd...https://medium.com/@jadhavsid1101/why-returning-null-from-...
Фигня все это, от лукавого. Нет никаких причин не использовать null или любое другое (другие) значения, если они прописаны в доках функции. Более того, если есть только один единственный особый случай, то гораздо удобнее использовать null. Ну типа: "Край, ничем не могу помочь. Разбирайся сам."
В первой ссылке какие-то мантры. А по поводу аргументов из второй ссылке:
- Return an empty collection - Это не по теме. Мы говорим о значении, а не о коллекции. Автор съезжает с темы.
- Throw an exception. Это вообще другой холивар: return vs. exception. Опять автор съезжает да и проблему не решает, т.к. это надо ловить выше.
- Return an optional value. This way, the caller can use the optional value to check whether a value was returned or not, and handle the empty case appropriately. - Ну и в чем выгода? По любасу надо проверять возврат по поводу особого случая?
- Use the Null Object pattern. Здесь типа даже если ничего не возращено, то все идет по плану. Это вообще зашквар какой-то. Типа юзер не найден, но далее все идет по плану. Это как?
- Use assertions. И чем это отличается от явных проверок? Ну впрочем это лучшее решение, чтобы проверять отсутствие null во время выполнения если это нельзя проверить во время компиляции (как в Котлин например). Полезно, если null вообще невозможен. Но мы же говорим о случае, когда она возможен.
Основная рекламируемая выгода от этих наворотов это избежать nullpointerexception (это как срашный сон). Но я бы сказал, что этb средства означают заметать мусор под ковер. Надо наоборот: чем раньше такие nullpointerexception возникают, тем лучше, поскольку сразу видно кто где накосячил, а не ждать весны (релиза), чтобы видеть кто где насрал.
В первой ссылке какие-то мантры. А по поводу аргументов из второй ссылке
разбирать приведенные ссылки особого смысла нет, это просто был как пример, что обычно попадается.
Более того, если есть только один единственный особый случай, то гораздо удобнее использовать null.
ничего не имею против, непонятно только отчего подобные рекомендации не попадаются так же часто как и "запрет" на использовании нулл
Мы говорим о значении
не знаю отчего вы так решили, разговор о том что может возвращать функция. Если требуется value type выделить, давайте выделим и разберем их отдельно
чем раньше такие nullpointerexception возникают
так именно об этом и разговор. Только если НПФ возникает - это уже ошибка, а раз ошибка то исключение должна выбрасывать функция.
Нужны правила отчего не нужно. Запрещаем вообще или есть какие то исключительные случаи?
Я не Ололёша, про шарп рассказывать не могу, я в нём не копенгаген. Но "в общем" - запрещаем вообще, единственный исключительный случай - когда нам запретить не дают. Требуют, чтобы мо могли хранить и, соответственно, возвращать null.
В каком именно?
Паскаль он один. Виртовский. Ну, пусть будет борландовский турбо-паскаль, ладно. Называть дельфи паскалем как называть шарп - си.
Гугл не советует:
Is Returning null a Bad Practice? Returning null can be considered bad practice because the caller has to explicitly handle the null checks and forgetting that can lead to unhandled exceptions.08.11.2023
В StackOverflow советуют так см. https://stackoverflow.com/questions/1626597/should-functio...:
Should functions return null or an empty object?
Returning null is usually the best idea if you intend to indicate that no data is available.
An empty object implies data has been returned, whereas returning null clearly indicates that nothing has been returned.
Additionally, returning a null will result in a null exception if you attempt to access members in the object, which can be useful for highlighting buggy code - attempting to access a member of nothing makes no sense. Accessing members of an empty object will not fail meaning bugs can go undiscovered.
А так вы сами писали раньше в этом форуме про вот такие переменные:int?, String?, итд... т.е. если написать метод вот так, то возращает пустоту без ошибок:
using System;
public class Program {
public static int? WhatAge() {
return null;
}
public static void Main() {
Console.WriteLine(WhatAge());
}
}
А в Си в 90х часто пользовались проверкой NULL, допустим если делать проверку на открытие файла, т.к. в языке Си нет try-catch:
FILE *f = fopen("test.txt", "r");
if (f == NULL) {
printf("Такой файл не существует!\n");
return 1;
}
Если посмотреть в Си файл stddef.h, там NULL так описывается, т.е. NULL=0:
#define NULL ((void *)0) #define NULL 0
Я сам только что затестил в Си:
#include <stdio.h>
int main(int argc, char *argv[]) {
if(0 == NULL)
printf("0 == NULL\n");
if(((void *)0) == NULL)
printf("((void *)0) == NULL\n");
return 0;
}
Выдаёт в консоли:
0 == NULL ((void *)0) == NULL
С Java уже давно не работал, насколько помню, там при объявление переменных нужно обязательно указать null. Например:
public class MySQLAccess {
private Connection connect = null;
private Statement statement = null;
private PreparedStatement preparedStatement = null;
private ResultSet resultSet = null;
Дневник тяжелобольного инвалидаIs Returning null a Bad Practice? Returning null can be considered bad practice because the caller has to explicitly handle the null checks and forgetting that can lead to unhandled exceptions.08.11.2023
Использование ножей опасно? Да, использование ножей опасно - можно порезаться, а кроме того, ими убивают. Использование ножей требует обучения, и нужно постоянно помнить об острой кромке. Выбросьте все ножи и покупайте всё уже нарезанное.
An empty object implies data has been returned, whereas returning null clearly indicates that nothing has been returned.
Additionally, returning a null will result in a null exception if you attempt to access members in the object, which can be useful for highlighting buggy code - attempting to access a member of nothing makes no sense. Accessing members of an empty object will not fail meaning bugs can go undiscovered.
Разница между исключением по наллу и исключением по пустому объекту лишь в том, что исключение по наллу уже встроено в систему, а по пустому объекту - ты можешь добавить сам. Вводя пустой объект, ты избавляешь себя от проверки на налл, но добавляешь необходимость проверки на пустой объект. Проверка на налл - одна простая операция. Проверка на пустой объект - зависит от реализации пустого объекта. Проверка на налл - универсальная операция, которая встречается много где и с которой все знакомы. Проверка на пустой объект в именно твоей бизнес-логике - специфическая операция, для которой нужно познакомиться с твоей бизнес-логикой.
Да и в любом случае формирование пустого объекта требует сначала проверки на налл (или на что там в БД считается за отсутствие объекта). Т.е. ты так и так делаешь проверку на налл, потом преобразуешь налл в пустой объект, потом делаешь проверку на пустой объект. И если ты всю эту херню делаешь в одной функции, то ты смешиваешь бизнес-логику и логику работу с другим слоем (база данных, например). Короче, ты привносишь много работы и мало смысла. Зато внешне это выглядит заумно - много слоёв, паттернов, схем, диаграмм для призентаций. Можно пилить такой проект в разы дольше, чем когда всё устроено проще. Но в реальности твои слои становятся связанными, теряется смысл введения этих слоёв, твои абстракции протекают. Вобщем, говнокод. Только не на уровне джуна, а на уровне сеньёра.
И что самое для Ололёшеньки обидное, все эти страдания по поводу "нельзя использовать null" появились исключительно потому что количество Ололёшо-подобных говнокодеров перешло в качество. Если раньше segfault из-за обращения по 0 адресу было редкостью, то теперь (оценочно) 3/4 ошибок в рантайме из-за дереференса нуль-пойнтера. В моём текущем проекте из анализа логов - примерно половина эксепшенов в логе из-за нулей.
Ничего не поделаешь, развитие. Обезьянок-говнокодеров становится всё больше, надо придумывать им инструменты, которые они не сломают и не убьются. Кухонные ножи им давать нельзя. Хорошо хоть есть откуда эти инструменты тырить. Плохо когда ворующие не понимают что и почему они воруют.
про шарп рассказывать не могу
ну вроде особых отличий в данном случае нет, принцип должен остаться неизменным
Но "в общем" - запрещаем вообще,
ну так это фактически и осталось для обсуждения, так как приходим к мнению, что всё-таки есть случаи когда нулл удобнее. И не только для возврата из хранения.
Паскаль он один. Виртовский
Насколько я помню он был предназначен для обучения и возвращать можно было только value type.
Возможно был и компилятор из книжки, но всё что я ассоциирую с временами паскаля было написано с использованием решений от борланда.
Он имел ввиду в хорошем смысле.
не знаю, хороший смысл в голову как то не приходит. Могу только сказать, что поведение нетипичное.
Может быть функция была выстрадана годами, а может еще что, что нам попросту неведомо.
Мне кажется, что в любом случае нужно концентрироваться на проблеме, а не на конкретном человеке.
Если раньше segfault из-за обращения по 0 адресу было редкостью, то теперь (оценочно) 3/4 ошибок в рантайме из-за дереференса нуль-пойнтера. В моём текущем проекте из анализа логов - примерно половина эксепшенов в логе из-за нулей.
Звучит как что-то С++ подобное. Как читал разных чуваков, делавших крутые штуки на С++, типа игровых движков, где стараются вылизывать производительность до блеска, любой крупный проект на С++ начинается с изобретения своей, ни с чем не совместимой, глючной и неполной реализацией автоматизированного управления памятью. Пишите на нормальных языках, где такое управление сделали за вас куда лучшие профессионалы и постоянно его поддерживают. Ну а для слишком самоуверенных действительно крутых чуваков сделали возможность и подвигать битики ручками.
Могу только сказать, что поведение нетипичное.
Может быть функция была выстрадана годами, а может еще что, что нам попросту неведомо.
Да что тут гадать. Он как Печкин - злой, потому что у него доски с парусом нет и фургона, на котором это всё возить можно. )))
Мне кажется, что в любом случае нужно концентрироваться на проблеме, а не на конкретном человеке.
А опыт говорит обратное - "нет человека - нет проблем". ))
По этой ссылке тоже высказываются различные мнения
https://stackoverflow.com/questions/1626597/should-functio...
Единственно, что не удается пока найти подобных рекомендаций в каких то статьях/блогах
"Returning null is usually the best idea if you intend to indicate that no data is available."
Скорее наоборот
ну вроде особых отличий в данном случае нет, принцип должен остаться неизменным
Что использовать вместо null зависит от инструментария языка. Что там в шарпе есть, nullable types? Типа "MyData? x" значит что x может быть MyData или null. Или "опциональные" значения? Вроде Optional или Maybe в хаскеле и Optional в яве.
ну так это фактически и осталось для обсуждения, так как приходим к мнению, что всё-таки есть случаи когда нулл удобнее. И не только для возврата из хранения.
"Удобнее" для кого? Изначальный вопрос стоял не как "удобно ли возвращать null". Есть люди, которым удобнее писать C++ на ассемблерных вставках, используя препроцессор. Или на перловских сокращениях. Никто понять не может, но ему удобно. Так что сначала надо определиться, что мы узнать-то хотим. Есть ли случаи, когда Ололёшеньке удобнее вернуть null? Конечно, что тут обсуждать.
Насколько я помню он был предназначен для обучения и возвращать можно было только value type.
Ну, списки в нём были. Ссылки были. И был nil. Борланд расширил, но если не лезть в ООП, (когда они это счастье добавили... в 5-м?) то он от классики недалеко ушёл.
Что там в шарпе есть, nullable types?
да есть
Optional в яве
тоже интересно https://habr.com/en/articles/658457/
"Удобнее" для кого?
ну уж точно не для отдельного человека. Скажем так - что можно написать в правилах оформления кода для команды. И главное, объяснить почему мы хотим так делать.
Ну вот, раз nullable типы есть, их и используем. Будет заставлять думать при обращении к объекту.
P.S. Мест, где имеет смысл использовать null-объекты на самом деле мало. Редко когда логичный null-объект сделать получается. В нём же смысл не в том, чтоб его сравнивать с результатом функции, а в том чтобы его можно было просто получить и использовать
ну уж точно не для отдельного человека. Скажем так - что можно написать в правилах оформления кода для команды. И главное, объяснить почему мы хотим так делать.
В шарпе я бы прописал использование nullable типов. Они не мешают вернуть null. Но бьют по рукам при дереференсе. Почему... Потому что обращение к null самая частая ошибка. И мы хотим её ограничить. Потому что уже сам создатель null сказал что говно придумал. Но Ололёшеньки же умнее этого старпёра,он им не указ! :)
Лично мне больше нравится Optional/Maybe, чем nullable типы. Они... сильнее бьют по рукам :) Сильнее бросаются в глаза, что мол, ахтунг! тут может быть неопределённое значение!
Про шарп не могу сказать, надо почитать. Насколько я помню Nullable<T> это и есть тип T? в шарпе, нет?
Обычно nullable Type это расширение типа (T?). При попытке получить его значение компилятор ругается если ты не обратился к нему "специальным образом", который скажет что делать если значения нет (null). Типа
MyObject? x = ....
x.doStuff(); // компилятор орёт
x?.doStuff(); // вызовет doStuff() или вернёт nullable Stuff? если x был null
У x есть все методы класса MyObject
А Optional<T> это "обёртка вокруг T". Его не передашь вместо T (и наоборот). У него нет методов T, только свои. У него есть или значение или "дефолтное значение". В языках с null обычно никто не мешает использовать null как дефолтное
значение.
x?.doStuff(); // вызовет doStuff() или вернёт nullable Stuff? если x был null
-------
не будет вызова это шарп
В языках с null обычно никто не мешает использовать null как дефолтное значение.
------
А надо?
мне вот больше нравится отдельный тип
Насколько я помню Nullable<T> это и есть тип T? в шарпе, нет?
Да, но нет.
Типа Т? не существует (вместо типа это вроде какая-то условная запись для чего-то в последних версиях языка), а тип Nullable<T> - существует, это дженерик.
Тип int? хоть и тождественен Nullable<int>, но сами эти условные записи как конструкции языка не всегда тождественны.
Да, но нет.
https://learn.microsoft.com/en-us/dotnet/csharp/language-r...
но сами эти условные записи как конструкции языка не всегда тождественны
В % отношении мона? Есть что то существенное, кроме притянутого за уши примера на SO?
так кстати, компилируется без проблем
var test = (a is int?) & b;
Да, но нет.https://learn.microsoft.com/en-us/dotnet/csharp/language-r...
Такая запись там нигде в коде не используется - лишь в описании. Вы можете создать дженерик с наллабл параметром типа? И чтобы он не гораничивался налловыми типами значений? Нет - в Сишарпе запись Т? означает лишь налловые типы значений. А если я хочу, чтобы параметр типа включал в себя не только их?
Ну вам же охота вместо одного универсального null для всех типов иметь отдельный null для каждого типа (этот ваш "пустой объект"). Вот и у других могут быть странные желания. Вы либо всем разрешите иметь странности, либо всем запретите, а то этому можно, а тому нельзя. ))
Ну вам же охота
Не следует делать далеко идущих выводов из некоторого количества сообщений
Вот и у других могут быть странные желания
Да пожалуйста, просто желание понять невозможно. Желание типа - слетать на Луну, как - то можно понять.
Но вот - слетать на Луну по пути заскочив на Марс, будет уже не так просто понять.
Вы можете создать дженерик с наллабл параметром типа? И чтобы он не гораничивался налловыми типами значений? Нет - в Сишарпе запись Т? означает лишь налловые типы значений. А если я хочу, чтобы параметр типа включал в себя не только их?
И тут Ололёшу накрыло и понесло... И чтоб Нью-Высюки стали столицей голактике! Ни меньфе!
нп
Подниму тему про нули, оказывается чем нулей больше - тем лучше.. и на конте но и в адресе в блокчейне!
Чем больше нулей, тем больше мы экономим газа, когда работаем со смартконтрактами, кароч АФД в адресе!
этим можно Бората потролить, сейчас все бездельники и дармоеды боятся что АФД всех их работать заставит!
.
Вопросы и Ответы - Программируем калькулятор пособий для беженцев вместе.
Кстати, я тут на днях столкнулся со случаем, когда null-объекты очень полезны :)
Пример - регулярные выражени. Как я и говорил, null-объекты могут оказаться полезными, когда у возвращаемого объекта есть логики.
Упрощенный код:
Match match = this.regex.Match(pattern);
while (match.Groups[REGEX_GROUPNAME_0].Success)
{
string groupName1 = string.Empty;
string groupName2 = string.Empty;
string groupName3 = string.Empty;
if (match.Groups[REGEX_GROUPNAME_1].Success)
{
groupName1 = $",{match.Groups[REGEX_GROUPNAME_1].Value}";
}
if (match.Groups[REGEX_GROUPNAME_2].Success)
{
groupName2 = $",{match.Groups[REGEX_GROUPNAME_2].Value}";
}
if (match.Groups[REGEX_GROUPNAME_3].Success)
{
groupName3 = $",{match.Groups[REGEX_GROUPNAME_3].Value}";
}
match = match.NextMatch(); // upd: забыл эту строчку :)
}
Без null-объекта этот код был бы не так хорошо читаем.
Для функции string.IsNullOrEmpty пофиг, налл у вас там или пустая строка. Да и чем проверка на налл от проверки на пустую строку отличается?
if (str != null)
if (str != "")
if (str != string.Empty)
Или какой налл-объект вы имеете ввиду?
Я тоже не совсем понимаю отчего разговор о нулл объекте
Return: An object that contains information about the match.
В любом случае возвращается один и тот же объект или мы думаем о разных вещах?
У этого Match сильно дофига свойств, чтобы его налл-объектом считать. Этак можно любой объект, где какое-то поле равно нулю, наллу или пустой строке, принять за налл-объект. При этом куча других полей у него заполнены.
Я тоже не совсем понимаю отчего разговор о нулл объекте
Ну мое понимает null-объектка - это некий объект (совсем необязательно другого типа), который выполняет действия "по умолчанию" (или имеет состояние "по умолчанию")
Regex.Match Method
Return: An object that contains information about the match.
В любом случае возвращается один и тот же объект или мы думаем о разных вещах?
Если совпадения нет, то все равно возвращается валидный объект, а не null, т.е. фактически null-объект.
Ну мое понимает null-объектка - это некий объект (совсем необязательно другого типа), который выполняет действия "по умолчанию" (или имеет состояние "по умолчанию")
Если совпадения нет, то все равно возвращается валидный объект, а не null, т.е. фактически null-объект.
Совершенно верно.
У этого Match сильно дофига свойств, чтобы его налл-объектом считать.
Ну во-первых, не так уж и много :)
Во-вторых, где определена граница, с какого количества свойств объект не может считать null-объектом?
В-третьиъ, хотя этого и не требуется от null-объекта, но у Match все геттеры, так что ты даже не сможешь изменить состояние объекта.
Этак можно любой объект, где какое-то поле равно нулю, наллу или пустой строке, принять за налл-объект. При этом куча других полей у него заполнены.
Null-объект - это объект с поведением "по умолчанию". Равно у null-объекта какое-то поле нулю или нет не имеет никакого значения. Null-объект находится в рабечем состоянии. Всегда.
у Match все геттеры, так что ты даже не сможешь изменить состояние объекта.
Рефлексией я что хочу, то и делаю. Причём могу даже удобных обёрток понаделать над каждым "лишь геттером", где через рефлексию обнажать его backing field, грязно надустанавливаться над его приватными сеттерами и совершать прочие непотребства. Все эти "приватности" - лишь рекомендация программисту, пользователю данного класса, что-то делать или не делать, чтобы помочь совершать меньше ошибок. Но запретить ему никто не может.
Рефлексией я что хочу, то и делаю. Причём могу даже удобных обёрток понаделать над каждым "лишь геттером", где через рефлексию обнажать его backing field, грязно надустанавливаться над его приватными сеттерами и совершать прочие непотребства.
В том, что ты можешь совершать непотребства мы все тут уже не один раз видели :)
Сути дела это все не меняет.
Если совпадения нет, то все равно возвращается валидный объект, а не null, т.е. фактически null-объект.
Можно конечно и с этой стороны посмотреть, но мне по душе больше классика
https://sourcemaking.com/design_patterns/null_object
Когда всегда возвращается один объект, но с разными состояниями, это всё же немного другое для меня. /фактически только верхняя половина рисунка/
ну камон, для каких-нибудь обработчиков я допускаю такое решение.
А представь - ты наговнякал таких структур для банального класса Address.
Передаёшь такой адрес в сервис отправки писем, сервис ессно очень умный, понимает, что адреса нет и ничего не делает.
Через какое-то время люди удивляются, почему клиент не реагирует на письма.
А представь - ты наговнякал таких структур
Представить можно много еще чего. Но всегда удобно иметь некие ориентиры.
По крайней мере, желательно разделить варианты когда возвращается простой (строка) или сложный объект.
И вот еще достаточно удобный вариант как враппер - всегда возвращается не нулевой объект.
Передаёшь такой адрес в сервис отправки писем,
А если нулл передаем, где будет отличие? "сервис ессно очень умный, понимает, что адреса нет и ничего не делает."
люди удивляются, почему клиент не реагирует на письма.
-------
мне вот интересно - если умный - какого-такого не сделал отчет - отправленных- миллион, не отправленных - сотня.
"Отправитель" в любом случае не будет разбираться с этой проблемой.
Вспомнил проблему именно с ехсептионом по нулл.
Считалась циклом какая-то сумма и на одних и на тех же данных результат получался существенно разным.
Предыдущий товарищ, чтобы все не падало, на нулле аккуратно ловил ехсептион вне цикла и продолжал обработку.
А вот что там было от нулла и до конца - просто отбрасывал.
При хорошей нагрузке нулл случался в разных местах выборки - получалась разная сумма.
вроде как с правилом определились - исключения только в случае баальшой ошибки.
Не надо смешивать теплое с мягким:
- исключение (или возврат) это технические средства откинуться из программы и что-то вернуть. Т.е. мы выбираем между throw или return.
- ошибки или не ошибки это семантика программы и логика обработки. "Пользователь не найден" это можно быть баальшой ошибки, если это запрещено в доках. Но это может быть нормально, если в доках написано что этого следует ожидать. Здесь мы решаем разрешается ли null или нет.
Ну чтобы было понятноее. Throw (exception) и return это два технических способа вывалиться их программы и вернуть какое-то значение в исходную:
- Можно использовать только return,
- а можно переписать все только на throw без возвратов вообще
Извне разницы не будет видно и это только вопрос удобства, предпочтений, best practices, религиозных и сексуальных предпочтений. Поэтому важно разделить эти два аспекта: логика программы и способ возврата (исключения vs. возврат).
Когда использовать исключения, а когда возврат и в чем разница? Это следующий холивар. Я бы сказал, что принципиальное отличие исключений в том, что они умеют вываливаться иерархически через многие уровни и делают это по умолчанию (если их не поймали). Возвраты таким не занимаются и вываливаются только на один уровень выше. Отсюда вывод: если хочешь чтобы твой результат мог быть виден на все уровни выше, то используй исключения (throw). Если твой резуьтат только для одного исходного метода, то используй возврат (return).
Когда использовать исключения, а когда возврат и в чем разница? Это следующий холивар.
У меня тут проблем нет. Всё достаточно прозрачно - исключения не должны управлять нормальной логикой программы. Один фиг на сколько уровней.
Я не хочу получать возврат "Пользователь не найден" если нет соединения с сервером.
Не надо смешивать теплое с мягким:
- исключение (или возврат) это технические средства откинуться из программы и что-то вернуть. Т.е. мы выбираем между throw или return.
- ошибки или не ошибки это семантика программы и логика обработки. "Пользователь не найден" это можно быть баальшой ошибки, если это запрещено в доках. Но это может быть нормально, если в доках написано что этого следует ожидать. Здесь мы решаем разрешается ли null или нет.
Старая прога, что я щас переписываю, по исключениям ветвит логику. Не всегда, но местами.
Каждый дро...т как хочет. Придёте вы на проект, и вы там не главный. Либо начинать дро...ть как все, либо валить. ))
Ну это понятно и примениму ко всему: вот придет барин, барин нас рассудит. Вопрос в другом: есть два (почти) равных механизма - возврат и исключения - какой когда использовать? А барина рядом нет, да и ему вообще все пофиг. Нафига ввобще вводили исключения? Их вводили, чтобы ловить что-то из преисподни, чего нет в обычных доках по либе, и что должно пролетать много этажей (наверх) вплоть до главной программы. А далее вопрос: должен ли я их использовать в своем прикладном уровне?
Старая прога, что я щас переписываю, по исключениям ветвит логику. Не всегда, но местами.
Во, о том и речь. Можно вернуть значение через return, а можно через throw. Но принимающий по любому будет должен ветвить логику и принимать решение. На фига тогда два механизма?
Мое имхо. Если return, то принмающий будет обязан обработать. А если throw, то принмающий может похерить, и пусть кто-то выше разбирается, который тоже может похерить (из-за незнания и непонимания что за хрень ему гонят снизу из преисподни) и все это дерьмо автоматом выплывет наверх и программа вылетит.
мне вот интересно - если умный - какого-такого не сделал отчет - отправленных- миллион, не отправленных - сотня."Отправитель" в любом случае не будет разбираться с этой проблемой.
Вот у тебя функция «повернуть руль на х градусов». Функция видит, что в буквальном смысле «пизда рулю», но вида не подаёт. Ты едешь в дерево, а криминалисты потом делают отчет: руль должен быть повернут, но не повернулся.
Все довольны.
Вопрос в другом: есть два (почти) равных механизма - возврат и исключения - какой когда использовать?
Бросить исключение это один из способов вернуть из метода какие-то данные. Некоторые так их и используют - т.е. воспринимают их не как исключительную ситуацию, а как нормальную работу программы, один из способов ветвить логику. Заводят кучу бизнес-исключений, и возвращают их через бросание. Для вызывающего кода разницы фактически нет - так и так приходится обрабатывать и возврат, и бросаемые вызываемым кодом исключения. Но если по логике программы исключительной ситуации не произошло, смысла возвращать данные через исключения нет - можно вернуть обычным способом. Просто раньше в том же Сишарпе не было способов удобно вернуть кучу разнотипных данных без создания своего аггрегационного типа или пачки out параметров. А теперь можно возвращать кортежи без костылей.
На фига тогда два механизма?
Механизм иключений позволяет ЛЮБОМУ коду вернуть некий набор типов ЕДИНООБРАЗНО - т.е. через механизм исключений. Свой аггрегационный типа возврата, кортежи, out параметры - это всё не такой привычный и распространённый способ, как обработка исключений. То, что нужно обрабатывать исключения, знают все, а то, что в том или этом фреймворке первый параметр возвращаемого кортежа - непосредственно возврат метода, а второй (или out параметр) - это данные по исключительной ситуации, знают лишь те, кто читает руководства к фреймворкам.
Но я согласен, что злоупотреблять исключениями не стоит. По их названию, они для исключительных ситуаций, а не для продолжения нормальной работы как ни в чём не бывало.
Когда я говорю отправить письмо клиенту и оказывается, что у клиента нет адреса, это для меня самый что ни на есть повод кинуть исключение.
Слушай, ну вот чё ты вышестоящему коду голову паришь? У него своих проблем куча. Ну разрули ты на своём уровне. Нету адреса - придумай что-то. Не напрягай вышестоящих.
Вон Гугел или кто там предлагает в Тетрис сыграть, если "опаньки!" и что-то пошло не так. Чё, Тетрис или три в ряд намутить не можешь, если адреса нет? Прояви креатив, инициативу, убеди клиента, что адрес ему на самом деле-то и не нужен, и без адреса люди как-то живут.
Вот в чём суть внедрения ИИ в софт? По крайней мере из сходя из того, что я наблюдаю во всяких поисковиках. Он ведёт себя как человек - пытается выпутаться из безвыходной ситуации, предлагает варианты, даже если не знает нужного ответа, стишок тебе для развлечения прочитает, в конце-концов. А не как тупая бездушная машина - нет адреса, бросаю исключение. Фу таким быть!
то у клиента нет адреса, это для меня самый что ни на есть повод кинуть исключение.
ну так это вроде в большинстве случае правильно. Операция отсылки письма без адреса бессмысленна, особенно когда сообщение должно быть.
Однако может быть проблема когда мы хотим посылать много сообщений, а уже у первого нет адреса.
Тогда это уже не отправка письма, а отправка очереди писем.
У нас как была функция отправки одного письма так и осталась. Только хотелки новые появились.
Прерывать работу всей очереди из-за одной ошибки
А кто об этом подозревает? Тесты прошли, всё работало нормально.
а криминалисты потом
------
Т.е. как и было написано - не пользователь...
руль должен быть повернут, но не повернулся.
------
Тебе полегчает если вместо поворота руля он останется в непонятном положении?
При этом криминалисты разведут руками - нихрена не оталось...
Ну можно конечно удариться в формализм, но, как мне кажется, важнее иметь нормальный функционал.
Я бы сказал, что наличие дополнительного типа NullObject далеко не всегда оправдано (более того, может просто загромождать код).
В данном случае я не вижу необходимости строго придерживаться паттерна :)
Извне разницы не будет видно и это только вопрос удобства
Не совсем так.
Во-первых, исключения дороже, чем просто возврат.
Во-вторых, на исключения ты обязан реагировать. Т.е. фактически тебе каждый вызов функции надо оборачивать в try ... catch. Это сделает код нечитаемым. А если где-нибудь забудешь обернуть, то предсказать место с которого продолжится программа будет нелегко :)
В-третьих, для нормального функционирования программы надо будет делать 100500 разных типов исключений, что опять таки загромоздит код.
Так что исключения - это все таки для обработки нештатных ситуаций и их не следует применять для контроля работы программы.
Я бы сказал, что наличие дополнительного типа NullObject далеко не всегда оправдано (более того, может просто загромождать код).
В принципе тут решение очень легко формализуется: надо переопределить метод - делаем подкласс. Не надо - оставляем то что есть. Если у нас immutable запись (без логики) зачем подкласс?
В комментах не уважают старичков. Намекают на их популизм.
А разгадка проста. Все эти принципы существуют не в отдельности
а вместе
И выделяя и продвигая один принцип, неизбежно ущемляешь другой. Т.е. нельзя следовать сразу всем этим принципам - в пределе они противоречат друг другу. Если же придерживаться разумного, и использовать все принципы в меру, то это уже не принципы, а просто нормальная работа. Подобно тому, как я не делю ходьбу на "принципы" бипедалирования, балансирования, фазу полёта, переноса центра тяжести и прочую заумную муть - я просто хожу. До всех этих Мартинов и "банд четырёх" были опытные люди, которые просто нормально работали и применяли эти принципы в разной степени в разных местах, по мере нужности, без выделения какого-то ограниченного набора и строгого описания его частей. Но выскочили на сцену почему-то всякие Мартины, банды четёрых и дяди Бобы, и начали создавать свою терминологию и систематизацию. Одни люди работают, другие инфоциганят и не препятствуют созданию вокруг себя религии, секты, которая постепенно возводит их догматы в абсолют и неизбежно искажает, превращая их в антипринципы. Т.е. то, чему нужно не следовать, а что нужно избегать. Оно и понятно - зачем препятствовать увеличению потока денег в свой карман и известности.
На арене цирка всё те же. Ололёшенька и его клоны с хабра. Не понимающие чуть меньше чем ничего. Но мнение имеющие. Оне ж погромизды!
А вы ещё спрашиваете можно ли null возвращать. Тут пора спрашивать как Ололёшеньке ручки отрубить, чтобы он классов не накодировал, а то у этого разработчика "выпячивание" LSP на то же Dependency Inversion плохо влияет. Но как, Холмс? Нет ответа. Он прокукарекал, а там хоть не расцветай.
Ну, глядя на шибко умных кодеров проекта, который я щас переписываю, я бы руки поотрубал кому-то другому. Там было всё по солиду, на интерфейсах на каждый чих, тесты-хуесты... Настало время менять куски приложения, развивать, удалять, добавлять - короче, делать всё то, что солид обещал, что оно будет проходить легко и непринуждённо. НИ-КУ-Я! Всё это нагромождение заумной хренятины лишь мешает переписывать код. А проще и быстрее было бы иметь словесное описание, или спецификацию на продукт и его функции, и реализовать всё с нуля на новых фреймворках. Тем более, что старый функционалитет настолько устарел, что там буквально кусками и модулями выбрасывали. Вместе со всем солидом отдирали, как старые ненужные обои и штукатурку. Все эти ипучие контракты (штук 12 проектов, состоящих из одних интерфейсов-контрактов, многоуровневых), которые местами просто не лезут на современный стек, а другими местами - не лезут в современные требования к приложению.
А что с наллом, таки можно его возвращать или как? Последнее от вас было
Ну мое понимает null-объектка - это некий объект (совсем необязательно другого типа), который выполняет действия "по умолчанию" (или имеет состояние "по умолчанию")Совершенно верно.
Если совпадения нет, то все равно возвращается валидный объект, а не null, т.е. фактически null-объект.
Т.е. у вас налл-объект выполняет какие-то действия или имеет состояние по умолчанию. А руки-то зачем прячете?.. )))
Там было всё по солидуСомнения некоторые есть
Ну вот, опять дедушкины сказки. "Если вам кажется, что вы понимаете принципы SOLID, значит вы не понимаете принципы SOLID."
Когда каждый трактует как хочет, обсирая трактовки других, объясняя любые неудачи просто и со вкусом: "сам дурак!"... В помойку такие принципы. Только поляну для всяких инфоцыган и разводил содержать.
объясняя любые неудачи просто и со вкусом: "сам дурак!"..
Не обязательно должны быть какие то крайности
Хотя мне понравилось объяснения одного писателя.
Вопрос: Вот вы пишете в книге 1, что Россия это богатая страна, а в книге 2, что бедная - где правда то?
Ответ: вот смотрите можем делать это, это и это - эта бедная или богатя страна, конечно богатая.
А вот смотрите - этого нет, этого нет и этого нет - это бедная страна или богатая, конечно бедная.
Ну, глядя на шибко умных кодеров проекта, который я щас переписываю, я бы руки поотрубал кому-то другому.
А с чего ты взял что ты что-то понял? Ты ж Ололёшенька. Гора апломба и ноль знаний. Увидел старый грузовик и ругаясь что это придумали какие-то дураки начал проволокой приматывать к нему оглобли. А то лошадь запрячь некуда, а приказали шкаф перевезти.
Т.е. у вас налл-объект выполняет какие-то действия или имеет состояние по умолчанию.
А "по умолчанию" после "какие-то действия" ты не скопировал просто так, или потому что опять ничего не понял? Иди, полазь по интернету, поучись.
что солид обещал
Принципы не могут что-то обещать, они же не люди 🙄
Всё это нагромождение заумной хренятины лишь мешает переписывать код.
Я предполагаю, эта "заумная хрень" должна была обеспечивать безболезненную смену технологий, чтобы убрать потребность к переписыванию 🙂
реализовать всё с нуля на новых фреймворках
С какой частотой нужно проект переписывать с нуля? 🫣 Вы точно успеете переписать все с нуля до выхода следующего "современного" фреймворка? И бюджет на это получите?
что солид обещалПринципы не могут что-то обещать, они же не люди 🙄
Принципы существуют лишь в головах людей - они эти понятия и придумали. А обещали те, кто эти принципы озвучивали. Они же по сценам ходят и умные книжки с семинарами выпускают. И каждый из них трактует эти принципы по-своему, и у него всегда припасена пачка коротких и ёмких ответов, почему у вас солид не выходит и так вам и надо. Т.е. декларировать-то они могут всё по бумажке одинаково, как в священных книгах написано, но понимают под этим каждый своё.
Просто компьютерные науки существуют относительно недолго, а всякие солиды так и вообще недавно появились. Но по аналогии вполне может быть, что в будущем всё это дело расколется, появятся свои программерские протестанты, апостолы истинной веры, и прочие схизмы. В принципе, оно уже. Ну и по аналогии же придётся потом выбросить всю эту дрянь скопом на помойку, т.к. оно и в оригинале-то недотягивало, а в результате и подавно будет представлять из себя смесь маразматического догматизма с мракобесием. Истинно говорю вам, будет переписан "Чистый код" в новом варианте, но останутся почитатели ветхого "Чистого кода", и и тот, и другой будут люди сжигать в кострах, на которых будут мучаться еретики, не почитающие третьего, единственно правильного "Чистого кода", и не прошедшие собеседований в монастыри истинной веры.
реализовать всё с нуля на новых фреймворкахС какой частотой нужно проект переписывать с нуля? 🫣 Вы точно успеете переписать все с нуля до выхода следующего "современного" фреймворка? И бюджет на это получите?
Из истории этой программы, всё оставалось на старых технологиях лет 15. А если бы не требовали соблюдать многие старые подходы, то уже всё было бы переписано, и ещё лет 10 можно было бы сидеть на попе ровно, на лайтовой поддержке этого кода. А потом снова всё переписать - так же легко и безболезненно по сравнению с рамками, которых понаставили эти ваши "правильные подходы".
Ну и требование, чтобы стиль кода оставался, как в старых модулях написано, чтобы преемственность и всё такое. Т.е. никакого тебе нового синтаксиса, особенно сокращающего простыни местами раза в два-три. Это потому, что безболезненная смена технологий, да.
А обещали те, кто эти принципы озвучивали.
было еще хорошо, что бы кто то хоть раз их дослушал до конца и чего то понял
Но похоже не будет ни первого, ни второго даже сухого поцелуя не останется.
Не знал, не видел, но осуждаю.
Возьмем принцип S - что там вообще может быть интерпретировано неверно? O - основа обратной совместимости и в частности хорошего API; L - строим дерево без семантических флуктуаций; I - меняем технологии не затрагивая домен, тестируем юниты, вводим абстракции..; D - основа современной энтерпрайз разработки.
Вы тролите? Вы, как сторонник плоской земли критикуете физические законы? ☺️
назад
список