Является ли обнаружение для разработчиков проблемой при использовании принципов SOLID?

Я занимаюсь линейкой бизнес-приложений, где все остальные разработчики привыкли делать базовые CRUD-приложения или сосредоточены исключительно на создании симпатичных / функциональных интерфейсов, и я получаю много нового.

«С тем, как мы используем это, сотрудник будет иметь все, что вы можете сделать с сотрудником». И это было правдой. Этот «класс» имел тысячи строк кода, и все, что вы могли сделать с сотрудником, было там. Или, что еще хуже, была таблица данных о сотрудниках, и каждый разработчик выяснил, как делать то, что он хотел, в обработчике событий.

Все плохое в этом подходе было правдой, но, по крайней мере, разработчик, использующий сотрудника, мог, не обращаясь к другим документам, выяснить, как зарегистрировать сотрудника в плане медицинского обслуживания, повысить зарплату, уволить, нанять, перевести и т. Д. для менеджера и всех других основных идей. Или, если они использовали сотрудника для других необходимых таблиц данных, они могли просто делать то, что хотели.

Да, было много дублированного кода. Да, это был очень хрупкий код. Да, тестирование было намного сложнее, чем необходимо. Да, изменение функциональности вызывало страх, и копирование стало естественным благодаря подходу.

Но они могли, по крайней мере, узнать, что было доступно, создав один класс, или они могли делать то, что им нужно, не понимая разницы между интерфейсами, абстрактными классами, конкретными классами и т. Д. И им не нужно было искать ничего, кроме методы, возвращаемые intellisense или известные таблицы, в которых находились данные.

Я гуглил / глотал и даже yahoo! D, но я не нашел никакого подтверждения этой проблемы.

Так что, возможно, нет проблемы, и я просто что-то упустил. Я ломал голову, пытаясь найти решение, в котором разработчики, которые не работают с реальным поведением / дизайном, могут легко обнаружить, как что-то сделать, не обращаясь к каким-либо внешним документам или не сканируя имена классов в различных компонентах / проекты, чтобы найти тот, который звучит как он будет работать.

Единственное, что мне удалось придумать, - это, из-за отсутствия лучшего названия, «Table of Content Class», который больше ничего не делает, возвращая фактические классы (и на самом деле большинство из них являются интерфейсами, но они не знать разницу или даже заботиться), что другие разработчики могут использовать для выполнения реальных задач, желаемых. Все еще заканчиваются действительно большими классами, но в них почти нет поведения.

Есть ли лучший способ, который не требует глубоких знаний среднего уровня, где происходит фактическая реализация SOLID?

По сути, я спрашиваю, есть ли способ позволить разработчикам типа CRUD оставаться разработчиками CRUD в очень сложной системе?

Кажется, что то, что вы описали (то есть класс Employee, имеющий ВСЕ возможный код, который вы могли бы сделать с сотрудником), является чрезвычайно распространенным шаблоном, который я лично видел довольно много. Некоторые из этого кода я написал сам, прежде чем я знал лучше.

То, что начинается с класса, который должен представлять единую сущность с управляемым набором методов, превращается в нечто, что является кошмаром для обслуживания, потому что каждая функция и каждый выпуск продолжают добавлять все больше и больше в один и тот же класс. Это идет вразрез с принципами SOLID, которые гласят, что вы должны написать класс один раз и противостоять желанию изменять его снова и снова.

Некоторое время назад (до того, как я обнаружил шаблоны проектирования или SOLID, продвигаемые другими), я решил для своего следующего проекта немного изменить ситуацию. Я работал на сервере, который служил интерфейсом между двумя очень большими платформами. Сначала требовалась только синхронизация конфигурации, но я мог видеть, что это было бы логичным местом для многих других функций.

Поэтому вместо того, чтобы писать класс, который представляет методы, я написал классы, которые представляли методы (оказалось, что это шаблон «Command» из GoF). Вместо того, чтобы выполнять работу для клиента, все мои основные классы приложений стали постоянными держателями состояний и стали намного короче по длине. Каждый раз, когда мне приходилось добавлять новый интерфейсный метод к самой службе, я просто создавал новый класс с методом Execute (), который запускал все. Если у нескольких команд есть что-то общее, они происходят из общего базового класса. В конце концов, в ней было более 70 различных командных классов, и весь проект был очень управляемым, и работать над ним было действительно приятно.

Ваш "класс TOC" не слишком далек от того, что я сделал. У меня была абстрактная фабрика (GoF), которая отвечала за создание команд. Внутри фабричного класса я скрыл большинство деталей за базовым классом и макросами в стиле ATL, поэтому, когда программист должен был добавить или просмотреть запрос, они пошли туда и увидели только:

BEGIN_COMMAND_MAP()
    COMMAND_ENTRY( CChangeDeviceState )
    COMMAND_ENTRY( CSetConfiguration )
    ....
END_COMMAND_MAP()

В качестве альтернативы (или в дополнение к) вы можете поместить все ваши действительные классы команд в отдельное пространство имен, чтобы, когда люди кодируют и им нужно что-то запускать, они просто вводят имя пространства имен, а Intellisense перечисляет все команды, которые вы определили. Затем каждая команда включает все методы get get / set, которые точно определяют, какие параметры ввода и вывода.

Вы также можете изучить использование шаблона Facade (GoF). Вместо того, чтобы выставлять более 1000 классов вашим инженерам CRUD. Спрячьте их всех за один класс, который выставляет только то, что нужно. Я все еще придерживаюсь того, чтобы каждое «действие» было своим собственным классом, но ваш класс Facade может иметь методы, которые будут создавать экземпляры каждого из ваших действий, и снова, с Intellisense, они сразу увидят, что доступно. Или же у Facade есть реальные методы, но внутренне заставляйте их создавать команды, ставить их в очередь и ждать ответов. Затем вернитесь, как если бы был сделан регулярный вызов метода.

(*) Я не хотел вдаваться в подробности, но на самом деле у меня был набор классов «Command» и «CommandHandler». Это отделяло ответственность за управление / постановку в очередь / сериализацию параметров ввода / вывода от классов, которые фактически «обрабатывали» эти команды.

Это может быть проблемой. Особенно, если вы плохо называете вещи. Но есть ряд решений, не прибегая к сложным классам. Черт, класс с слишком большим количеством методов может быть одинаково трудным для навигации с Intellisense.

Попробуйте использовать пространства имен (C #) или пакеты (Java), или любую аналогичную концепцию вашего языка (я буду называть их все пространствами имен), чтобы упростить проблему.

Начните с названия вашей компании. Это ограничивает Intellisense только пространствами имен, написанными вами. Затем, если у вас есть несколько приложений, используйте вторую часть пространства имен, чтобы разделить их. Включите пространство имен Core для вещей, которые существуют в разных приложениях. Далее разбейте вещи на типы функциональности. И так далее.

Если вы сделаете это правильно, вы получите очень обнаруживаемые предметы.

Например, если я хочу подтверждение пользователя, я набираю «MyCo». и это дает мне список пространств имен приложений. Я знаю, что база данных User используется во всех наших приложениях, поэтому я набираю «Core». тогда я получаю список типов функциональности. Одним из них является «Валидация», так что это кажется очевидным выбором. И в рамках валидации есть «UserValidator» со всеми его функциями.

Как это бывает, для вещей, которые я часто использую, я быстро запомню названия или, по крайней мере, условные обозначения. Поскольку я делаю много изменений в правилах проверки, я буду знать, что все мои классы проверки называются FooValidator, где Foo - это имя таблицы. Так что на самом деле мне не нужно пересекать пространства имен. Я просто наберу UserValidator и позволю IDE сделать остальную работу.

Но из-за вещей, которые я не могу вспомнить, все равно довольно легко их найти. И когда я это сделаю, я могу удалить префикс пространства имен.

Поскольку вы называете их «разработчиками CRUD», мы предполагаем, что вы не считаете их хорошими. Мы не знаем, означает ли это, что они также не понимают вашу сферу деятельности. Если они понимают предметную область, классы должны иметь для них смысл. Зная, что было построено несколько классов, они должны сначала взглянуть, потом спросить, рассмотреть вариант создания с нуля в качестве третьего варианта.

Поскольку умение автоматически знать, как использовать / повторно использовать класс, просто взглянув на него, не следует ожидать с первого раза. Вам нужно будет документировать и, возможно, предоставить дополнительные объяснения в ходе обучения или, возможно, во время проверки кода.

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