Вопрос по java – Что такое один класс, один принцип ответственности?

6

Я хотел бы узнать оOne Class, One Responsibility принцип. Я нашел несколько статей об этом, но без примеров. Это помогло бы мне, если бы вы могли привести пример класса, который нарушает этот принцип.

Мне знакома идея, что метод должен делать только одно, например, методы get и set. Это не должно быть так же, какOne Class, One Responsibilityпотому что методы set и get оба реализованы внутри класса. Значит ли это, что класс нарушает правило, потому что у него есть обязанности как устанавливать, так и получать?

ЧтоOne Class, One Responsibility Principle?

objectmentor.com/resources/articles/srp.pdf Kevin Bowersox
stackoverflow.com/questions/3829306/… andersoj
Punctuation твой друг keyser
Единственный способ по-настоящему узнать, что это такое, - это поработать над реальным проектом и увидеть контрпримеры, так называемые объекты Бога - объекты, которые имеют код, который имеет дело со слишком многими отдельными проблемами логики программы. На небольшом проекте этот принцип трудно представить. Marko Topolnik
спасибо за ссылку. поэтому, если я буду следовать правилу, тогда я смогу увеличивать свои классы в геометрической прогрессии. user1348869

Ваш Ответ

5   ответов
1

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

Это концепция, которая кажется довольно простой; убедитесь, что конкретный объект (или метод, в этом отношении) обрабатывает один кусок логики. Если он обрабатывает больше, вам нужен другой объект (или метод).

Error: User Rate Limit Exceeded user1348869
0

когда вы не знаете, что она вам нужна, пока вы не попытаетесь обойтись без нее и не увидите, как она превращается в беспорядок:

Допустим, вы пишете свою собственную утилиту Logger, и, поскольку она начинается просто (синглтон с методами, которые пишут в stdout), вы решаете объединить все ее функции в одном классе. По мере использования вы придумываете дополнительные возможности для добавления:

different destinations to log to (stderr, a file, a queue, whatever)

ability to change formatting for messages

providing separate loggers for different categories

ability to filter messages for a category by log level

you want to be able to change logging levels while the program is running

new logging levels (ERROR, WARN, INFO, DEBUG, etc.)

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

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

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

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

0

о чем говорится, не намного. Один класс должен иметь только одну ответственность. Хотя может быть сложно определить обязанности. Примером может служить класс «DatabaseHandler», который обрабатывает все запросы к базе данных в приложении.

Дальнейшее чтение:сплоченность.

0

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

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

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

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

0

за что должен отвечать класс.

Если это класс с именем MailSender, он должен знать только, как отправлять почту. Код, создающий почтовый контент, не должен быть внутри него.

Похожие вопросы