В системах, где важно точное соответствие данных "как в документе", обычно поддерживаются разные типы этих самых документов, и соответственно набор полей.
Структуру нужно выбирать под задачу и здесь обычно формат понятен из требований. Например, имя и фамилия по отдельности могут интересовать в контексте поиска, сортировки или заполнения типовых форм. Для отчества с сортировкой ни разу не сталкивался.
В остальных случаях, когда нет понятных ограничений, лучше использовать opaque строки. У меня в адресной книге есть такие персонажи как "Mike холодильник", "Support", "k20-35", "Тамара шлагбаум" и т.п. и спасибо разработчикам, что не лезут с советами как правильно.
Но ведь эти взрослые люди, приходя на работу, на полном серьёзе считают, что здесь им достаточно лишь трех измерений, чтобы все объяснить.
Наблюдаемая нами Вселенная это какое-то странное кино, где одновременно показывают все серии разом, с начала времен.
Вероятно трёхмерным является только экран - как на двухмерном листе бумаги умещаются все ваши счета, по которым можно давать какие-то количественные оценки, называя это наукой, но ни чего нельзя сказать о содержании оплачиваемых СМС'ок.
Более того, за неимением другого опыта наш мозг совершенно не приспособлен постигать пространства размерностей, больших трёх
Оплачивая счета в конце месяца, понимаешь, что твоё существование измеряется не только высотой, шириной и глубиной, но так же мегабайтами, киловатами, литрами, количеством СМС сообщений, и еще кучей различных и ни как не связанных друг с другом параметров.
Тенденция в том, чтобы отвязать проблемы статической проверки корректности кода от момента компиляции, а тем более - рантайма. Ведь мы хотим, чтобы IDE посвечивала ошибки красненьким прямо в процессе ввода, а не кого-то потом. Поэтому структуры данных и типы теперь разбегаются по разным уголкам.
Структурная vs номинальная типизация это больше проблема проверки логической корректности программ, нежели вопрос времени исполнения. Опкодам в рантайме вообще без разницы по каким причинам их собрали вместе. К ООП это тоже имеет отношение поскольку-поскольку.
CA описывает архитектуру системы, а не отдельного компонента. Один из тезисов говорит про независимость от UI.
Бизнес логика по классике живёт на сервере, а ваше приложение под Android это тонкий клиент. Интересно, не является-ли такой клиент, в терминах данной архитектуры фактически тем самым UI, независимость от которого они хотят добиться?
Если ответ да, то изначальное желание затащить еще какую-то CA внутрь клиента, выглядит немного сюрриалистично.
Энтерпрайз, если дословно, это предприятие. В том самом, несколько архаичном для русского языка смысле, как некая активность, сопряженная с преодолением каких-то трудностей. Размер здесь не главное - с равным успехом это термин может использоваться как для небольших стартапов, так и корпораций-гигантов.
Enterprise Architecture это история про архитектуру бизнесов. Информационные системы и приложения лежат уровнем ниже. А в самом низу находятся различные технологии.
С тем же успехом можно сказать: смени пол и занимайся чем угодно. Смени планету и занимайся чем угодно. Смени... По факту людей, которые вложили годы своей жизни и труда в этот проект выставили за дверь. Причем это сделали их же коллеги. По большому счету, в решении ни кого не волнует ни отношение к происходящему, ни цели проводимых экспериментов.
Барбара кстати сама говорила, что немного в шоке от того, к чему пришла индустрия с подачи Дяди Боба - она в своей, в общем-то проходной, работе ни на какие такие откровения не претендовала, а сам принцип это просто цитата из более ранней работы её коллеги. Она использовала его скорее как гипотезу, нежели аксиому. В следующей публикации несколькими годами позже, с подачи своего науч.рука, принцип был оспорен. Но Мартина это ни сколько не смутило. Что их всех объединяло? - общая тусовка.
К сожалению это не так. Если команда не обладает нужной квалификацией, то тимлид будет вынужден сдасться если не при первом же продолбанном делайне, то при втором. А дальше их ожидает технический долг и все остальное по классике.
У меня был опыт работы в стартапе, где на первых этапах работали довольно дорогие ребята. Сделали с десяток разных вариаций продукта, естественно с соответствующим уровнем техлолга
Когда владельцы наконец-то поняли чего хотят, то наняли дешёвую команду, которая переписала по подготовленному нами ТЗ все практически с нуля. После чего первую команду разогнали. С точки зрения бизнеса это оптимальный вариант.
Дядя Боб является так же автором SOLID. Поэтому обосновать одно из его творений через другое это тавтология.
Там было время, когда бороться со сложностью пробовали путем усложнения структуры. Причем это предлагали ребята, у которых за плечами уже был кое-какой опыт разработки. Проблема в том, что до использования таких структур команда должна сначала дорасти. Если нет, то их внедрение делает только хуже. Все равно, что младенца сажать на двухколесный велосипед.
Архитектура конкретного проекта определяется не какими-то абстактными принципами, а вполне конкретными требованиями. В первую очередь - нефункциональными. Поэтому они в общем-то все всегда разные.
Кстати, часто эту байку рассказывают разработчики, не умеющие ни в одну из best practices. Стартапа через 3 месяца правда у них тоже не выходит, ровно по тем же причинам.
В системах, где важно точное соответствие данных "как в документе", обычно поддерживаются разные типы этих самых документов, и соответственно набор полей.
Структуру нужно выбирать под задачу и здесь обычно формат понятен из требований. Например, имя и фамилия по отдельности могут интересовать в контексте поиска, сортировки или заполнения типовых форм. Для отчества с сортировкой ни разу не сталкивался.
В остальных случаях, когда нет понятных ограничений, лучше использовать opaque строки. У меня в адресной книге есть такие персонажи как "Mike холодильник", "Support", "k20-35", "Тамара шлагбаум" и т.п. и спасибо разработчикам, что не лезут с советами как правильно.
Но ведь эти взрослые люди, приходя на работу, на полном серьёзе считают, что здесь им достаточно лишь трех измерений, чтобы все объяснить.
Наблюдаемая нами Вселенная это какое-то странное кино, где одновременно показывают все серии разом, с начала времен.
Вероятно трёхмерным является только экран - как на двухмерном листе бумаги умещаются все ваши счета, по которым можно давать какие-то количественные оценки, называя это наукой, но ни чего нельзя сказать о содержании оплачиваемых СМС'ок.
Оплачивая счета в конце месяца, понимаешь, что твоё существование измеряется не только высотой, шириной и глубиной, но так же мегабайтами, киловатами, литрами, количеством СМС сообщений, и еще кучей различных и ни как не связанных друг с другом параметров.
Тенденция в том, чтобы отвязать проблемы статической проверки корректности кода от момента компиляции, а тем более - рантайма. Ведь мы хотим, чтобы IDE посвечивала ошибки красненьким прямо в процессе ввода, а не кого-то потом. Поэтому структуры данных и типы теперь разбегаются по разным уголкам.
Структурная vs номинальная типизация это больше проблема проверки логической корректности программ, нежели вопрос времени исполнения. Опкодам в рантайме вообще без разницы по каким причинам их собрали вместе. К ООП это тоже имеет отношение поскольку-поскольку.
Разница как между частной собственностью и общественной.
Примером языков с поздним связыванием являются скриптовые. Для решения проблем с производительностью в них достаточно успешно используется JIT.
Не появятся-ли тогда одноразовые редакторы с поодной статьёй, и учёки лишь для того, чтобы отписаться?
Все ещё называете вещи своими именами? А вы отважные, однако.
Нужна-ли здесь CA или может быть какая-то другая архитектура?
CA описывает архитектуру системы, а не отдельного компонента. Один из тезисов говорит про независимость от UI.
Бизнес логика по классике живёт на сервере, а ваше приложение под Android это тонкий клиент. Интересно, не является-ли такой клиент, в терминах данной архитектуры фактически тем самым UI, независимость от которого они хотят добиться?
Если ответ да, то изначальное желание затащить еще какую-то CA внутрь клиента, выглядит немного сюрриалистично.
Энтерпрайз, если дословно, это предприятие. В том самом, несколько архаичном для русского языка смысле, как некая активность, сопряженная с преодолением каких-то трудностей. Размер здесь не главное - с равным успехом это термин может использоваться как для небольших стартапов, так и корпораций-гигантов.
Enterprise Architecture это история про архитектуру бизнесов. Информационные системы и приложения лежат уровнем ниже. А в самом низу находятся различные технологии.
С тем же успехом можно сказать: смени пол и занимайся чем угодно. Смени планету и занимайся чем угодно. Смени... По факту людей, которые вложили годы своей жизни и труда в этот проект выставили за дверь. Причем это сделали их же коллеги. По большому счету, в решении ни кого не волнует ни отношение к происходящему, ни цели проводимых экспериментов.
Барбара кстати сама говорила, что немного в шоке от того, к чему пришла индустрия с подачи Дяди Боба - она в своей, в общем-то проходной, работе ни на какие такие откровения не претендовала, а сам принцип это просто цитата из более ранней работы её коллеги. Она использовала его скорее как гипотезу, нежели аксиому. В следующей публикации несколькими годами позже, с подачи своего науч.рука, принцип был оспорен. Но Мартина это ни сколько не смутило. Что их всех объединяло? - общая тусовка.
К сожалению это не так. Если команда не обладает нужной квалификацией, то тимлид будет вынужден сдасться если не при первом же продолбанном делайне, то при втором. А дальше их ожидает технический долг и все остальное по классике.
У меня был опыт работы в стартапе, где на первых этапах работали довольно дорогие ребята. Сделали с десяток разных вариаций продукта, естественно с соответствующим уровнем техлолга
Когда владельцы наконец-то поняли чего хотят, то наняли дешёвую команду, которая переписала по подготовленному нами ТЗ все практически с нуля. После чего первую команду разогнали. С точки зрения бизнеса это оптимальный вариант.
Дядя Боб является так же автором SOLID. Поэтому обосновать одно из его творений через другое это тавтология.
Там было время, когда бороться со сложностью пробовали путем усложнения структуры. Причем это предлагали ребята, у которых за плечами уже был кое-какой опыт разработки. Проблема в том, что до использования таких структур команда должна сначала дорасти. Если нет, то их внедрение делает только хуже. Все равно, что младенца сажать на двухколесный велосипед.
Архитектура конкретного проекта определяется не какими-то абстактными принципами, а вполне конкретными требованиями. В первую очередь - нефункциональными. Поэтому они в общем-то все всегда разные.
Кстати, часто эту байку рассказывают разработчики, не умеющие ни в одну из best practices. Стартапа через 3 месяца правда у них тоже не выходит, ровно по тем же причинам.
ну то есть вопрос софта и умения им пользоваться.