[Java] Развитие мышления на уровне проектирования
Kent Beck - Test Driven Development
Как я уже писал в соседнем топике, если освоишь идеологию, то хороший дизайн будет получаться автоматом.
Joshua Bloch - Effective Java
Куча практических советов, как правильно готовить Джаву. Но там уже не только и не столько по архитектуре, сколько вообще в целом.
Как я уже писал в соседнем топике, если освоишь идеологию, то хороший дизайн будет получаться автоматом.
Joshua Bloch - Effective Java
Куча практических советов, как правильно готовить Джаву. Но там уже не только и не столько по архитектуре, сколько вообще в целом.
Joshua Bloch - Effective JavaНемного почитал: очень хорошая книга! Действительно полезные советы! Большое Вам спасибо за ссылку!
Куча практических советов, как правильно готовить Джаву. Но там уже не только и не столько по архитектуре, сколько вообще в целом.
Kent Beck - Test Driven Development
Как я уже писал в соседнем топике, если освоишь идеологию, то хороший дизайн будет получаться автоматом.
Чуть-чуть посмотрел: немного отпугнула "недостаточно академическая" манера автора; на первый взгляд показалось, что чересчур много "ремесла".
А это и есть ремесло - непростое и интересное, но ремесло. Хотя бы потому, что нигде нету метрики, что есть хорошо спроектированный код.
В общем, зря отпугнула.
Есть еще одна:
Nat Pryce, Steve Freeman - Growing Object-Oriented Software Guided by Tests
Попробуй ее, хотя там тоже не много академичности. И по-честному, ее после Кента Бека надо читать. А еще лучше после того как сам немного попробуешь ТДД - иначе много чего не уложится.
Но попробовать полистать чтобы проникнуться, и понять, как оно должно быть - сгодится.
В общем, зря отпугнула.
Есть еще одна:
Nat Pryce, Steve Freeman - Growing Object-Oriented Software Guided by Tests
Попробуй ее, хотя там тоже не много академичности. И по-честному, ее после Кента Бека надо читать. А еще лучше после того как сам немного попробуешь ТДД - иначе много чего не уложится.
Но попробовать полистать чтобы проникнуться, и понять, как оно должно быть - сгодится.
Если интересует проектирование именно предметной области, то можете посмотреть такую вещь:
Eric Evans - Domain-Driven Design: Tackling Complexity in the Heart of Software.
Статья в Википедии на эту же тему
В общем, там на самом деле не мало философии и отдельные главы читаются не так легко. Можете всего и не читать, если лень вникать в теорию. Практика начинается с главы 4 и идет до главы 7. Там объясняются основные элементы и идеи, используемые именно при проектировании предметной области.
Eric Evans - Domain-Driven Design: Tackling Complexity in the Heart of Software.
Статья в Википедии на эту же тему
В общем, там на самом деле не мало философии и отдельные главы читаются не так легко. Можете всего и не читать, если лень вникать в теорию. Практика начинается с главы 4 и идет до главы 7. Там объясняются основные элементы и идеи, используемые именно при проектировании предметной области.
Первое — конкретный совет о проектировании интерфейсов.
Попробуй научиться проектировать интерфейсы/реализации снизу вверх сначала — это проще.
Когда я учился проектировать, то изначально рисовал всё на бумажке по науке, а потом уже кодил. Честно признаюсь: получалось красиво, но совершенно дерьмово и нежизнеспособно.
В итоге научился так:
Через пять таких процедур можешь попробовать "на бумажке".
Второе — об объеме кода
Если у тебя уже 6000+ LOC, то пора уже хорошо продумывать то, что модно называть "архитектурой".
Третье — книжки
Fowler — Refactoring
Fowler — Patterns of Enterprise Application Architecture
GOF — Design patterns
Хотя они и о философии, но прочитать их придется.
Попробуй научиться проектировать интерфейсы/реализации снизу вверх сначала — это проще.
Когда я учился проектировать, то изначально рисовал всё на бумажке по науке, а потом уже кодил. Честно признаюсь: получалось красиво, но совершенно дерьмово и нежизнеспособно.
В итоге научился так:
- Создаешь конкретную реализацию без всяких там интерфейсов и прочих абстрактностей.
- Когда появляется потребность сделать похожую вторую реализацию, то ты просто (да-да!) копи-пастишь первую и правишь ее так, как требует того требования.
- Внимательно смотришь на две получивишеся очень похожие реалзиции и рефакторишь их, вынося в интерфейсы/утилитные/абстрактные классы общие части. До тех пор, пока дублирование кода не уйдет.
Через пять таких процедур можешь попробовать "на бумажке".
Второе — об объеме кода
Если у тебя уже 6000+ LOC, то пора уже хорошо продумывать то, что модно называть "архитектурой".
Третье — книжки
Fowler — Refactoring
Fowler — Patterns of Enterprise Application Architecture
GOF — Design patterns
Хотя они и о философии, но прочитать их придется.
Fowler — RefactoringСпасибо Вам за пост и ссылки на интересную литературу!
Почитал сегодня Фаулера "Рефакторинг: улучшение существующего кода" (2003 г.). Книжка не плохая, но все-таки по охвату материала, практической полезности и легкости чтения уступает, на мой взгляд, "Совершенному коду" Макконнелла. Возможно, книга "Совершенный код" единственная в своей роде ...
Когда появляется потребность сделать похожую вторую реализацию, то ты просто (да-да!) копи-пастишь первую и правишь ее так, как требует того требования.бедные джависты, как же вам тяжело
Внимательно смотришь на две получивишеся очень похожие реалзиции и рефакторишь их, вынося в интерфейсы/утилитные/абстрактные классы общие части. До тех пор, пока дублирование кода не уйдет.
бедные джависты, как же вам тяжело
Описанный метод вполне легитимен и работает.
Описанный метод вполне легитимен и работает.ну в нормальном языке (с лямбдами и замыканиями) примерно такой подход сам собой получается, только почти без промежуточного копипаста. Т.е. по сути всё так же, но в java это выглядит тяжелее и мучительнее, и многие очень долго приходят к такому стилю.
в нормальном языке (с лямбдами и замыканиями)Это c#, что ли?
ну в нормальном языке (с лямбдами и замыканиями) примерно такой подход сам собой получается, только почти без промежуточного копипастаЯ правильно понял - ты пытаешься сказать, что в каком-нибудь Руби вообще не нужен рефакторинг?
нет, рефакторинг наше всё
Это c#, что ли?ты транслируешь мемы из интернетов, кроме это больше ничего не умеешь?
Оставить комментарий
nikola1956
Сегодня отчеливо понял недостаток собственных знаний в области проектирования больших проектов на Java (> 30 классов в среднем примерно по 200-300 сток в каждом) . Когда проект сравнительно небольшой (примерно один "человеко-месяц" то более-менее удается "держать его в голове". Но когда объем возрастает, остро встает вопрос о формулировании удобных абстракций в терминах предметной области и последующей, соответствующей этим абстракциям факторизации классов на меньшие классы, выделение новых пакетов и т.п.До настоящего времени я в основном довольствовался полезнейшими рекомендациями из книги "Совершенный код" (С. Макконнелл но теперь требуется новый уровень осмысления вопросов проектирования и факторизации, так сказать более экономный способ мышления.
Но где подчерпнуть нужные понятия для такого осмысления ? Да, есть книги вроде "Рефакторинг с использованием шаблоном" (Кириевски) или "Шаблоны проектирования в Java" (Гранд но как в них ориентироваться ? какие понятия использовать, чтобы материалы подобных книг воспринимались как "справочная информация", а не как отдельные темы для скурпулезного изучения ? Посоветуйте, пожалуйста, полезную литературу, краткую, без "мельтешения" и "зауми", с уклоном в сторону "философии" и раскрытия смысла самых полезных понятий в области современных методологий проектирования ПО.