Тёмная тема
Kartonagnick
> Да. Это не очевидно?
Просто я не считаю, что нужно придумывать самодельное название и примешивать сюда дизайн каким-то боком. Дизайн вообще обычно переводится как проектирование в русских книгах.
LIVe
> Просто я не считаю, что нужно придумывать самодельное название и примешивать
> сюда дизайн каким-то боком. Дизайн вообще обычно переводится как проектирование
> в русских книгах.
>
Я не придумывал слово "дизайн".
Я не придумывал слово "использование".
Их значения вы можете посмотреть в толковом словаре.
Можно конечно развести еще и лингвистический спор на несколько страниц. Да только толку от этого не будет. Каждый волен называть вещи как ему вздумается, но лучше придерживаться общепринятой терминологии.
LIVe
> Каждый волен называть вещи как ему вздумается, но лучше придерживаться
> общепринятой терминологии.
use case ---> usage ---> дизайн использования ---> и есть "общепринятая терминология"
К слову сказать - термины не нуждаются в специальном толкователе, их можно понимать "как есть".
Kartonagnick
> use case ---> usage ---> дизайн использования ---> и есть "общепринятая
> терминология"
Нет дизайна использования. Есть варианты использования. Книги и google подтвердят.
LIVe
> Нет дизайна использования. Есть варианты использования. Книги и google
> подтвердят.
Чем "дизайн использования" отличается от "вариантов использования" ? кроме того, что последнее предполагает несколько способов.
Kartonagnick
> Чем "дизайн использования" отличается от "вариантов использования" ? кроме
> того, что последнее предполагает несколько способов.
Тем, что ты похоже сам это выдумал. Google об этом не знает. И ты только будешь путать людей, предлагая им сомнительные термины.
Kartonagnick
> Я не совсем понимаю, что такое "прокачка". Но делать запросы куда то в базу
> данных гую вообще нафиг не упало. Не его компатенция, и ни его обязанность.
Ну магазин типа - что еще не купили, а прокачка - это то что уже купили, ну там навороты базы, танка, робота, кораблика, вооружение.
Насчет остального - это была реакция на это.
> Для работы гуи не нужна сеть. Для работы сети не нужен гуй. Удобно тестировать
> узлы.
> Удобно разрабатывать узлы в отдельном от игры проекте
> Можно распараллелить разработку Вася пилит гуй, а Петя - сеть.
Как можно отлаживать работу и логику ГУЯ , да и в целом управления игрой, тем более сетевой, не получая данных ?
LIVe
> Тем, что ты похоже сам это выдумал. Google об этом не знает.
Первая же ссылка в гугле:
http://designforuse.net/
LIVe
> И ты только будешь путать людей, предлагая им сомнительные термины.
Есть термины. Это слова которые в зависимости от предметной области могут иметь разные, но всегда официальные, точные значения.
Например: функция-член класса. Это термин, который имеет официальное и точное значение.
Есть слэнг. Напоминают термины, но менее официальны.
Например "метод класса". Нигде в стандарте языка вы не встретите это словосочетание. Поэтому что это не термин. Однако, в среде программистов очень широко распространен. Видимо, потому что проще, чем официальный термин.
Слэнг так же, как и терминология служит для облегчения понимания.
А есть простые слова. Которые нужно понимать в их обычном бытовом значении.
Например:
"дизайн",
"дизайн использования".
"use case".
Вы понимаете к чему я клоню?
bodja
> Как можно отлаживать работу и логику ГУЯ , да и в целом управления игрой, тем
> более сетевой, не получая данных ?
Давайте проясним два момента:
1.
Что вы подразумеваете под "логикой ГУЯ" ? Логику работы самой библиотеки, или логику работы конечного пользовательского интерфейса, который был создан "под ключ" конкретной игры?
Потому что если первое - это делают разработчики библиотеки. Используют юнит-тесты, или ещё что нибудь а этом роде.
2. Что значит "не получая данных" ?
Я вижу вы так и не поняли сути схемы из поста #45
Потому что если бы поняли, у вас бы не было сейчас этого вопроса.
Такой принцип разделения узлов нужен именно для того, что бы любому узлу подсунуть на вход все что захотите.
А если у вас есть возможность спокойно подсовывать узлам любые свои данные, соответственно, вам будет легко и просто протестировать узел на предмет корректной работы для любых возможных ситуаций.
Пример:
Спасибо. Интересно читать.
Только вот... Не стоит использовать подчеркивания без гиперссылок. Я читаю с планшета и это очень мешает.
Если я правиль-Eugene-
> Только вот... Не стоит использовать подчеркивания без гиперссылок. Я читаю с
> планшета и это очень мешает.
Спасибо. Если я правильно понял речь идет о кроссылках на другие части книги. Я их именно подчеркиванием выделял. А те что должны вести на еще не переведенные главы пока просто подчеркнуты. Но мне осталось всего две главы перевести и после этого я эти ссылки поправлю.
Если речь о чем-то другом - буду признателен если напишете конкретнее.
LIVe
А, если будет исправлено, то все хорошо.
Kartonagnick
> Что вы подразумеваете под "логикой ГУЯ" ? Логику работы самой библиотеки, или
> логику работы конечного пользовательского интерфейса, который был создан "под
> ключ" конкретной игры?
Второе, универсальный трешак никому не нужен.
ЗЫ В целом я использую просто разделение кода и данных, ну а само развертывание и поведение динамической части гуя зависит от данных, допустим то же xml не плохо с этим справляется. Вот и все разделение, с серверным программистом достаточно просто согласовать сам протокол обмена.
bodja
Не осилил ваш поток сознания.
Включать телепатию лень.
Тема в архиве.