Научиться проектировать архитектуру приложения [закрыт]

#c_sharp #книги #архитектура #проектирование

        
             
                
                    
                        
                            Закрыт. На этот вопрос невозможно дать объективный ответ.
Ответы на него в данный момент не принимаются.
                            
                        
                    
                
                            
                                
                
                        
                            
                        
                    
                        
                            Хотите улучшить этот вопрос? Переформулируйте вопрос,
чтобы на него можно было дать ответ, основанный на фактах и цитатах, отредактировав его.
                        
                        Закрыт 4 года назад.
                                                                                
           
                
        
Стал замечать, что по мере освоения C#, я все больше думаю о том, как архитектурно
реализовать ту или иную часть приложения.
Например, разрабатывая приложение для взаимодействия с USB-устройством, задумался
над тем, а как именно будут взаимодействовать его компоненты. 
Например, можно реализовать единственный класс, который будет заниматься всем: работать
на уровне WinAPI с USB, ожидать прихода пакетов, понимать протокол общения, реализовывать
последовательности команд и обработку ответов на них и т.д.
Но это неудобное решение. Лучше разделить по слоям и, например, вынести общение по
USB в отдельный модуль и тогда, если USB поменяется на Ethernet, то можно будет просто
написать новый модуль, не трогая остальное. 
Окей, пишем модуль общения по USB. Для этого пишем сначала интерфейс взаимодействия
с верхним уровнем. Написали. Так, что-то тут все заточено под синхронный обмен, а вдруг
понадобится асинхронный. Дополняем. И еще несколько параметров. 
Начинаем писать сам модуль. Оказывается, заложенная функциональность избыточна. А
еще вот тут что-то не так и там и т.д. Опять начинаем думать, исправлять/дополнять.
В итоге я зарываюсь в вопросы из серии "а как лучше сделать сейчас, чтобы в будущем
было удобно поддерживать?", производительность падает, а сложность придуманных конструкций
резко растет и в итоге получается какая-то каша, а не идеальный код, который я и хотел
получить.
Что я делаю не так? Как поступают опытные программисты? Как они избегают этих бесконечных
вопросов и при этом пишут вполне поддерживаемый и понятный код? 
Какую литературу можно почитать, чтобы прокачаться в этих вопросах? Шаблоны проектирования?
А не слишком ли они заточены под крупные проекты и сложны для небольших проектов? 
И есть ли у кого ссылки на проекты на C#, где можно посмотреть архитектурные решения?     

Ответы

Ответ 1

@yabloko, умение проектировать и находить баланс между текущими потребностями проекта
и созданием задела на будущее приходит только с опытом. Нельзя просто прочитать книжку
и обрести просветление. Поэтому пишите код, обдумывайте, изучайте как устроены чужие
проекты, моделируйте какие-нибудь примеры взятые с потолка. Проектируйте для разминки
небольшие "взятые с потолка" фрагменты функциональности. Просто на бумажке. Например:

простенький UI из текстовых полей и кнопок, но такой, чтобы при необходимости можно
было расширить количество виджетов;
список контактов, с возможностью импорта из разных источников (почта, twitter, соцсети);
текстовый редактор с простыми операциями над текстом (например, сделать выделенный
фрагмент КАПСОМ) и возможностью их отмены.
и т. п.

В общем фантазируйте и тренируйтесь.
Кстати про проектирование полноценного текстового редактора подробно разжевано в
"Банде четырех".


Ответ 2

Попробуйте думать в терминах сущностей и их ответственности. Какие сущности есть
в вашей программе, кто за что отвечает, кто о чём знает? Если вы не можете описать
одним коротким предложением ответственность модуля/класса/функции/переменной, возможно,
её надо переделать.
Вы не должны думать о том, нужно ли будет подменить кусок с USB на кусок с Ethernet.
Это может оказаться преждевременным дизайнерским решением, overengineering. Но вот
разделение на отдельные простые слои — правильная мысль, она поможет вам бороться со
сложностью проекта, сосредотачиваться каждый раз только на нужной части.
Точно так же, вы выделяете код в процедуру, если он имеет самостоятельный смысл,
а не для повторного использования. Даже если процедура используется всего один раз.
Стоит почитать какую-нибудь книгу по паттернам, но не увлекайтесь этим сильно: свои
мозги всяко лучше, чем консервированные идеи. Тем более, то, что в одном языке — паттерн,
в другом часть синтаксиса (пример: Observer в C# реализуется в одно объявление, а в
C++ требует уйму boilerplate-кода).


Ответ 3

Читайте про паттерны программирования. Например, есть такая книжечка "Паттерны проектирования"
авторы  Эрик Фримен, Элизабет Фримен, там на джаве все показывается, но суть понятна
и для других языков. Еще есть куча литературы по паттернам. используйте их, практикуйтесь,
и там постепенно придет понимание что и как делать.