Должен ли я иметь логику в своем классе модели или других классов - PullRequest
Новая
       38

Должен ли я иметь логику в своем классе модели или других классов

5 голосов
/ 27 марта 2012

Я просто хочу, чтобы у меня в голове были другие мнения об этом, например, у меня есть класс user_controller и класс user 


class User
   attr_accessor :name, :username   
end

class UserController
   // do something about anything about users
end

Вопрос в том, должна ли у меня быть логика в классе User, чтобы она была 


user = User.new
user.do_something(user1)

or it should be 

user_controller = UserController.new
user_controller.do_something(user1, user2)

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


john = User.new
john.accept_friend(jane)

instead of 
user_controller = UserController.new
user_controller.accept_friend(john, jane)

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

Редактировать: Происходит действительно хорошее преобразование, но мне очень нравится здесь больше от людей. Спасибо всем.

Ответы [ 4 ]

8 голосов
/ 27 марта 2012

Да, вы должны сохранить логику в вашей модели! То есть, если вы делаете реальное объектно-ориентированное программирование (и похоже, что вы делаете). Цитировать Википедия :

Объектно-ориентированное программирование (ООП) - это парадигма программирования, использующая «объекты» - структуры данных, состоящие из полей данных и методов вместе с их взаимодействиями - для разработки приложений и компьютеров программы.

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

Мартин Фаулер говорит, что использование логики вне вашей модели - это анти-паттерн.

1 голос
/ 27 марта 2012

Большинство людей сказали бы, что вы не должны хранить логику в своих модельных классах. Исключения могут включать:

  • вспомогательные функции для доступа к содержащейся коллекции (addToList(Object o), getFromList(int index) и т. Д.)
  • Стандартный объект и аналогичные переопределения (equals, hashCode, toString, clone, compareTo и т. Д.)
  • Предварительная / постобработка данных (например, исправление строк в верхнем регистре или тому подобное)

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

0 голосов
/ 27 марта 2012

В таких сценариях следует учитывать компромисс.Хорошо добавить accept_friend в пользовательский класс, если вы уверены, что пользовательский класс не будет увеличиваться в размере в будущем.

С другой стороны, предпочтительно переместить accept_friend в классы обслуживания, такие как UserController, в следующемсценарии.

  1. Чтобы избежать увеличения пользовательского класса.Такая логика может быть перемещена в эти подклассы (Usercontroller), таким образом, классы выглядят простыми

  2. Для возможности восстановления.Завтра, если существует класс с именем superuser, который также нуждается в функции accept_friend, класс UserController можно возобновить следующим образом:

user_controller = UserController.new

user_controller.accept_friend(Суперпользователь1, суперпользователь2)

0 голосов
/ 27 марта 2012

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

попробуйте прочитать больше об информационном эксперте.

...