Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.17.70.79] |
|
Страницы: (4) 1 2 [3] 4 все ( Перейти к последнему сообщению ) |
Сообщ.
#31
,
|
|
|
С чего ты это взял? ) |
Сообщ.
#32
,
|
|
|
Цитата korvin @ С чего ты это взял? ) Ну хз Мне кажется логичным наличие в языке механизма для работы со значениями во время компиляции и так же логичным кажется использовать ключевое слово const. |
Сообщ.
#33
,
|
|
|
Цитата D_KEY @ Мне кажется логичным наличие в языке механизма для работы со значениями во время компиляции и так же логичным кажется использовать ключевое слово const. Это в тебе профдеформация говорит. |
Сообщ.
#34
,
|
|
|
Цитата korvin @ Цитата D_KEY @ Мне кажется логичным наличие в языке механизма для работы со значениями во время компиляции и так же логичным кажется использовать ключевое слово const. Это в тебе профдеформация говорит. Возможно. Но ты раскрой мысль-то про константы. |
Сообщ.
#35
,
|
|
|
Цитата D_KEY @ Но ты раскрой мысль-то про константы. А что там раскрывать? Нет никакой разницы, как называется ключевое слово, хоть const, хоть val, хоть let, хоть def. Возможность работать со значениями во время компиляции от этого никак не зависит. |
Сообщ.
#36
,
|
|
|
Цитата korvin @ Нет никакой разницы, как называется ключевое слово, хоть const, хоть val, хоть let, хоть def. Возможность работать со значениями во время компиляции от этого никак не зависит. Суть не в названии, а в наличии возможности. Т.е. смогу ли я потом воспользоваться значением константы для условной компиляции, например? Или для определения размеров массива, хотя бы. Можешь погуглить про constexpr в C++ или про то, что в D есть. |
Сообщ.
#37
,
|
|
|
Цитата D_KEY @ Суть не в названии, а в наличии возможности. Ну раз суть не в названии, то почему ты докопался до названия? ) Цитата D_KEY @ Т.е. смогу ли я потом воспользоваться значением константы для условной компиляции, например? Условная компиляция — зло. ) Цитата D_KEY @ Или для определения размеров массива, хотя бы. Сможешь. Цитата D_KEY @ Можешь погуглить про constexpr в C++ или про то, что в D есть. Спасибо, я знаю про constexpr. При чём тут это, не совсем понятно, но можешь тоже погуглить про eval-when в Common Lisp, например. ) Добавлено Или вот. |
Сообщ.
#38
,
|
|
|
Цитата korvin @ Цитата D_KEY @ Суть не в названии, а в наличии возможности. Ну раз суть не в названии, то почему ты докопался до названия? ) Да я ж просто сказал, что предпочел бы const для констант Цитата Условная компиляция — зло. ) В общем случае нет. Цитата Спасибо, я знаю про constexpr. При чём тут это, не совсем понятно Ну мой const это что-то близкое к constexpr. По поводу template haskell смотрел когда-то, что-то слабее даже плюсовых шаблонов показалось. Но я подзабыл уже. Добавлено В любом случае мы отделяем то, что происходит во время компиляции. О чем я и говорю. |
Сообщ.
#39
,
|
|
|
Цитата D_KEY @ В общем случае нет. Да. В том числе и в общем случае. ) Добавлено Цитата D_KEY @ По поводу template haskell смотрел когда-то, что-то слабее даже плюсовых шаблонов показалось. Оно не совсем прямо соотносится с плюсовыми шаблонами, скорее ближе к макросам лиспа. |
Сообщ.
#40
,
|
|
|
Цитата korvin @ Цитата D_KEY @ В общем случае нет. Да. В том числе и в общем случае. Аргументы-то есть? |
Сообщ.
#41
,
|
|
|
Сообщ.
#42
,
|
|
|
Цитата sergioK @ не val а var и начиная с 10 версии, которая не LTS, с 11 пока мало где можно выходить в продакшен, ждем 17 вроде до сентября , Не Java, а любой нормальный язык, начиная с… 1970-х примерно. |
Сообщ.
#43
,
|
|
|
Вроде не протухла же тема?
Я как поимевший дела с индусами могу сказать, что, думаю, что они это делают, что бы от самих себя защититься. Вообще, делать интерфейсы с константами нормальная практика с незапамятных времен. И нет в ней ничего плохого. Другое дело, что люди не понимаю че делают (лично я ненавижу статический импорт) что бы не писать имя интерфейса могут сделать реализацию для интерфейса с константами. ХЗ зачем им это может понадобиться, лично я думаю, что они просто не в себе. В общем, интерфейсы с константами в яве это нормально (передней край индусской науки к сожалению не аргумент). Но для защиты от индусских дураков предлагается железобетонный способ. Ну и с архитекторской т.з. это все выглядит немного криво, потому что они в диаграммах в основном сидят. А тут прямоугольничек, который вроде как и можно использовать определенным способом, но никогда не нужно. Людей с ОКР это раздражает, я знаю |
Сообщ.
#44
,
|
|
|
Цитата Felan @ Вроде не протухла же тема? Ой как раз в тему, У меня command pattern и при инициализация я свои классы с ключами гружу в map , И все бы хорошо, но вдруг главный индус архитектор мне его убирает - аргументация у них есть fresh developers и им тяжело использовать фабрику , обычный switch лучше switch key { case 1: return channel1Service.download(..) case 2: return channel2Service.download(..) и т,д } У было IService service = factory.getService(int key ) И тут Я понимаю что по неволе становлюсь расистом Эти индусы вообще реальные системы писали ? И только схемы рисовали ? Если у них fresh developer и счас не умеет работать паттернами , так как он научиться тогда , мои джуны прекрасно с фабрикой работали. |
Сообщ.
#45
,
|
|
|
Ну тут я с индусом соглашусь.
Насколько я понял из объедков кода, это не фабрика а фабричный метод. Хотя и он тут не к чему. Это должно называться Сервис локатор. Вообще, архитектурные паттерны очень похожи друг на друга. И они не про рантайм. Они про статическую структуру. Про то как взаимодействуют классы, а не объекты. Поэтому и важно привильно их применять. По сути, фабричный метод вполне может заменить сервис локатор. В принципе и то и то будет работать. Даже можно сказать одинаково. Но когда один архитектор будет разговаривать с другим, они буду понимать определенные нюансы связанные с каждым паттерном. Потенциальные пути расширения функционала. Не все что можно навесить на одно, можно навесить на другое без потери "архитектуры" извиняюсь за тавтологию . А данном случае, зачем здесь фабричный метод? Его вывод не зависит от статики, от действительного типа объекта в рантайме. Он зависит только от параметра. Так что да. Простой кейс тут более уместен, ну в крайнем случае сервис локатор (я не знаю подробностей). А индусы они в общем тоже разные бывают. Как и все остальные. Но специфика культурного кода присутствует конечно ЗЫЖ Интересно посмотреть оригинал переписки... мало ли, че там они на ломаном басурманском накорябали, кто чего не понимает |