Стиль реализации статического класса

[maxkar]

Это не правило, это наблюдение того, что получается на практике

По архитектуре нужно скорее не читать, а писать. Основное, что определяет архитектура - набор абстракций. Абстракции лучше всего записывать человеческим языком, так как "названия класса" мало для описания абстракции. Отсюда вывод - нужно писать документацию (asdoc). Во время написания такой документации как раз могут всплывать ошибки архитектуры. Так, если параметр метода или конструктора плохо согласутеся с абcтракцией, выражаемой классом, значит, вероятно, нужно вынести дополнительный уровень абстракции (вместо параметра передавать уже созданный класс, например). Большой объем документации может свидетельствовать о том, что нарушен SRP. Обычно достаточно нескольких (1-5) предложений для хорошего описания. Конечно, встречаются и случаи, когда документации нужно действительно больше.

Далее. Нужно освоить полиморфизм и инкапсуляцию. И то, и другое ортогонально ООП (например, прекрасно выражается в ФП). Вообще, и то, и другое, связано с абстракцией. Полиморфизм - возможность описывать одной абстракцией различные детали поведения. Инкапсуляция - отсутствие "не соответствующих абстракции" деталей реализации. По данным аспектам книг не посоветую - не знаю.

Еще очень полезно освоить понятия coupling и cohesion. а также то, какие типы cohesion лучше и хуже. Здесь можно почитать "Совершенный код" Стива Макконела ("Code Complete"), глава 5 "Design In Construction". Там как раз описан coupling. Еще стоит посмотреть на главы 6.2 ("Good Class Interfaces") и 7.2 ("Design at the Routine Level"). Первая - про абстракции, вторая - про cohesion.

Желательно попробовать что-нибудь функциональное (lisp (не углубляясь в метапрограммирование), scheme, ml (ocaml/sml), haskell (хотя там уже уклон в сторону типов)). Практика написания на них закрепляет навыки функциональной декомпозиции (именно функциональной!) да и инкапсуляцию/полиморфизм демонстрирует в новом свете.

Еще могу порекомендовать "Practical API Design Confessions of a Java Framework Architect". Автор пишет о немного специфичной области, но много и общеприменимых идей. Для архитектуры особое внимание стоит обратить на различие "provides" и "requires". Отличие принципиальное и очень помогает в разработке. Обычно любой класс пишется либо для удовлетворения "requires" (и проектируется от требований в конкретном месте), либо "provides" - библиотечный класс, который предоставляет функции с широкой обсластью применимости. Двум сразу сценариям один и тот же класс удовлетворять не должен. На практике обычно большинство классов реализуются путем уточнения и написания "requires" (дизайн сверху вниз, пишется высокоуровневый код, затем реализуются его зависимости, для них реализуются их зависимости и т.п.). Потом уже выделяются библиотеки ("provides") которые с помощью адаптеров (разработанных от "requires") используются при решении задачи.

Еще у того же Макконела в "Совершенном коде" можно прочитать про метафоры программирования. Особое внимание стоит обратить "toolbox metaphor", это нужно для того, чтобы критично относиться к рекламе различных методологий.

Ну а после этого нужно писать дальше. Заниматься декомпозицией. На уровне кода. На старте приводит к большому количеству интерфейсов и классов, но дает достаточно много возможностей замены реализации. На уровне библиотек. У вас одна большая "стандартная библиотека" в компании или много маленьких? Если одна большая - распилить на много маленьких, но с хорошей функциональной cohesion. Например, библиотеки UI, функции работы с коллекциями, функции для работы с функциями, несколько библиотек работы с сетью (на разных уровнях абстракции). Освоить бранчевание кода (в version control)) и не бояться экспериментировать. С большим количеством небольших библиотек экспериментировать проще, чем с одной монолитной - гораздо точнее ясны требования к библиотеке и сама библиотека для переделки изолирована. Также нужно следить и за своим ощущением о "качестве" текущей архитектуры. Это удобство ее использования в самом широком смысле (необходимость писать лишний код только для удволетворения нужд фреймворка, неудачные абстракции, сложность модификации под другие задачи и т.п.).

А практически все остальные принципы следуют из уже сказанного выше. Тот же SOLID. SRP - это чистота абстракции и удобство полиморфизма. Open/Closed principle автоматически работает при разделении на дизайн от "requires" и "provides". Там же и его ограничения всплывают. Очевино, что "provides" для введения новой функциональности менять не стоит. А вот классы, созданные от "requires" как раз вполне можно (такие классы без их пользователя обычно имеют мало смысла). LSP - хорошее правило для работы с абстракциями. ISP - частный случай SRP на самом деле. Ну и плюс следствие "requires" и полиморфизма по каждому независимому аспекту (именно так и реализуется хорошее разбиение). Dependency Injection - еще одна реализация SRP, где разделяются ответственности за создание объектов и выполнение его функций.

В общем, архитектура - это больше практическая дисциплина. В ней мало теоретических работ. Так что фундаментального читать практически нечего. Но очень полезно читать всевозможные описания существующих проектов. Например, блоги разработчиков. Там описаны проблемы, варианты их решения и результаты примененеия решений. Полезно знать возникающие вопросы, последствия различных решений. При этом совершенно не обязательно соглашаться с самими решениями! Достаточно считать, что автор провел эксперимент и получил определенные результаты. Как их трактовать, решаете уже вы сами.