ООП: сколько программной логики должно быть заключено в связанные объекты / классы как методы?

Question

У меня есть простая программа, которая может иметь администратора или обычного пользователя. В программе также есть два класса: для UserAccount и AdminAccount. Администратор должен будет выполнить следующие действия (варианты использования): Add_Account, Remove_Account и т. Д.

У меня вопрос, должен ли я попытаться инкапсулировать эти сценарии использования в объекты?

Только тот, кто является администратором, вошел в систему с учетной записью AdminAccount, должен иметь возможность добавлять и удалять другие учетные записи. Я мог бы иметь подпрограмму без класса, которая добавляет новые объекты UserAccount в систему и вызывается, когда администратор нажимает кнопку «Добавить учетную запись». В качестве альтернативы я мог бы поместить эту процедуру в качестве метода внутри объекта AdminAccount и заставить событие кнопки выполнить некоторый код, например «Admin.AddUser (имя, пароль)».

Я более склонен пойти с первым вариантом, но я не уверен, как далеко этот бизнес ОО должен идти.

Answer 1

Сколько логики должно быть в объектах?

Все это.

Объектно-ориентированный 101 сказал бы, что у вас должен быть класс Account. Пользователь и администратор - это роли, которые могут наделять друг друга различными полномочиями, но поведение добавления и удаления учетных записей из системы не должно меняться.

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

Если вы сначала думаете о графическом интерфейсе, вы делаете это неправильно.

Answer 2

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