[noname00.pas]

Нужна помощь с проектированием классов. Что в каком классе писать и как оно должно между собой взаимодействовать? »

Понимаю, твоё затруднение.

Не буду за тебя заниматься проектированием архитектуры, лишь дам несколько непрошенных советов. Будешь ими пользоваться или нет - сам решай.

Я опишу тебе, как я разрабатываю архитектуру того, что делаю. Во многом я делаю ровно так, как рекомендуют всевозможные Agile методологии, но я в них не эксперт, так что не буду утверждать, что это они и есть

В начале работы я закладываю только лишь основные понятия, так сказать "архитектура в целом". Чтобы понять, как архитектура в целом должна выглядеть, нужно в предметной области (в твоём случае в покере) понять, что в игре главное. Какие основные понятия, какие происходят процессы и т.д. В примере с покером есть игроки, есть карты, есть комбинации, есть игровой процесс, там есть различные раунды, есть правила по которым совершаются ставки (и эти правила, возможно, достаточно сложны чтобы заслужить отдельного места в объектной модели). На самом деле на этом этапе важно детализировать каждый аспект настолько, чтобы ты чувствовал себя комфортно и как бы "видел" картину в целом.

Цель этого этапа - сформировать интуитивное знание, или чувствование будущей архитектуры. На этом этапе сильно помогает общая эрудированность в программировании, знание паттернов проектирования, различных подходов и алгоритмов. Ещё раз повторюсь - цель этого этапа не сформировать архитектуру, а сформировать чувствование архитектуры в тебе самом. Очень вероятно, что большую часть идей, принятых на этом этапе, впоследствии придётся отбросить. Но этот этап даст тебе базу, с которой ты сможешь начать.

Далее нужно сказать вот что. Я всегда пишу модульные тесты параллельно с продакшн-кодом. Это помогает быть уверенным в том, что код, который я пишу, работает. Если я пишу тесты, я отлавливаю большинство багов практически сразу же, и что немаловажно, я постоянно получаю подтверждение работоспособности моего кода. Уверенность в том, что у меня хорошее тестовое покрытие позволяет мне быстро и без колебаний перерабатывать код (то что называется рефакторинг), и менять что угодно в моей архитектуре на любой стадии. Если есть хорошее тестовое покрытие, даже глобальное изменение всей архитектуры вполне можно провернуть и в середине и в конце работы. И на изменения уходит как правило не так много времени.

Следующий важный аспект моего подхода заключается в постоянной очистке и переработке кода. Кажется первым суть подхода сформулировал Кент Бэк, автор методологии XP (extreme programming). Он сформулировал четыре правила, которые позволяют создать хорошую архитектуру. Он говорит, что архитектура является хорошей, если она:
1) обеспечивает выполнение всех тестов
2) не содержит дублирующегося кода
3) выражает намерения программиста (то есть код должен легко читаться, по Кенту Бэку это тоже является требованием архитектуры и я с ним согласен полностью)
4) использует минимальное количество классов и методов (тут я добавлю - без фанатизма. Количество минимальное, но чтобы при этом пункт 3 выполнялся. То есть если выбор между ясностью и краткостью, выбор стоит делать в пользу ясности)

Пункт первый обеспечивается если ты пишешь тесты параллельно с кодом и всегда следишь за их выполнением. Чтобы обеспечить пункты 2-4 нужно постоянно рефакторить код. Работая над каждой задачей, обращаясь к другим фрагментам кода, нужно постоянно повышать его качество.

И ещё одна немаловажная составляющая успеха - это короткие итерации. Я сначала планирую итерацию, которая занимает от 1 до 2 недель, набрасываю задачи и оцениваю их трудоёмкость, а потом их выполняю. Задачи на каждую итерацию выбираются так, чтобы в конце каждой итерации добавлялась полностью работоспособная функция или несколько. Такое планирование нужно больше для целей бизнеса, но и для разработчиков это очень полезная практика. Это позволяет сразу же видеть результат своей работы. При этом в самом начале работы, лучше всего в самой первой итерации, нужно обязательно реализовать версию, которую уже можно потыкать, покликать, поиграться с ней, а потом уже добавлять к ней функцию за функцией. В конце каждой итерации должна быть работоспособная версия, в которой добавилась одна или несколько функций. Это даёт... Хорошее настроение и уверенность в успехе. И это очень важно.

Надеюсь, что мои советы оказались полезными для тебя или ещё для кого-нибудь. К тому, как я сейчас работаю и как делаю архитектуру я шёл достаточно долго, и возможно трудно так сходу во всём этом подходе разобраться. Короче литература по теме:
Jeff Langr - Agile Java. Crafting code with test driven development (русского перевода не встречал. Книжка по джаве, но гибкая разработка там насквозь через всю книгу.)
Кент Бэк - Экстремальное программирование (у него несколько книг, я прочитал какую-то одну, )
Роберт К. Мартин - Чистый код

П.С. Вероятно в твоём приложении нужно будет обратить особое внимание на разделение ответственностей между бизнес-логикой (собственно игра) и сетевым взаимодействием (сервер, клиенты, сообщения, команды и т.д.).

[Killer_13]

Ваввв!!Вот это сообщенице. Спасибо огромнейшее! Не думал, что еще откликнутся.