Объект. DoSomething () по сравнению с DoSomethingWith [закрытый] (объект)

Generally speaking, this OOPish construct:

person.Run(distance);

is just a syntactic sugar for:

Person.Run(person, distance);

where person becomes an implicit this reference. There are some subtleties with virtual functions and such, but you get the idea.

As for your question, you're basically having a rich domain model versus an anemic one, and this is a subject of a great many debates.

Обычно класс, в данном случае Person , имеет поведение;

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

var p = new Person();
p.Run();

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

Если человек несет ответственность за выполнение, я бы предложил person.Run () если Run может обрабатывать другие типы объектов, и его можно как-то повторно использовать вне объекта person, тогда он может стоять сам по себе и называть его Excercise.Run (person);

Для меня я бы выбрал person.Run () ;

Я согласен с Брайаном. Просто для справки, я хотел указать на эту статью «Говори, не спрашивай» и «Закон Деметры». Здесь применимы оба.

Программист-прагматик: Говори, не спрашивай

Две вещи:

1. Это не вопрос вкуса, но имеет реальные технические последствия. Различия между функцией-членом и бесплатной функцией уже подробно обсуждались, я рекомендую взглянуть на книгу «Эффективный C ++» и / или статью Скотта Мейерса на http://www.ddj.com/cpp/184401197 In short, if you make a function a member function, you'd better have a darn good reason to do so.

2. The readability argument should be taken with care. It depends very much on the name of the member function. Remember the SPO - Subject Predicate Object rule: there's little doubt that person.run() looks better than run(person); (at least to an english-speaking person), but what if you have other verbs than 'run'. Some verb which takes an object, for instance 'to call' in case you want to make a phone call? Compare call( person ); vs. person.call();. The former looks much nicer.

В идеале сравнение некорректно по нескольким причинам: 1. В идеале каждый объект должен отвечать за свои собственные действия, например, в случае человека, человек будет отвечать за human.walk (), human.eat (), human.sleep () и т. Д. 2. Параметр, который передается в действие, является потребляемым ресурсом для этого действия. Было бы неразумно называть Life.walk (человек), поскольку прогулка - это не деятельность Жизни, а человек - не потребляемый ресурс. Здесь объект - человек. Однако было бы разумно сказать human.eat (еда); где еда - это расходный ресурс. 3. Образец, который вы предоставили, похоже, намекает на то, что во втором случае Run является статическим методом, а для функционирования объекта вы редко хотите реализовывать его как разработку статического метода.

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

Надеюсь, это развеивает ваши сомнения. Более подробно о шаблонах проектирования вы можете прочитать в книгах Мартина Фаулера. http://www.martinfowler.com/books.html

Есть небольшие отличия:

• person.Run () получает единственный параметр: this
• , если Excercise.Run (person) является статическим методом, он также получает один параметр
• , если Excercise является экземпляром, он получает два параметра: this и person

Очевидно, что третий подход необходим только в том случае, если вы должны передать оба параметра. Я бы сказал, что первый подход лучше ООП, и я бы выбрал второй только в особых обстоятельствах (например, если Person был запечатан).

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

Второй case больше подходит для интерпретаций вне объекта и лучше всего выполняется через интерфейсы. Таким образом, вместо того, чтобы брать объект человека, методы Excersize должны принимать интерфейс, скажем IExcersizable, который, например, перемещает конечности. Метод Excesize.run (IExersizable) может быстро перемещать одну ногу, а затем другую. Excesize.walk (IExersizable) может быть таким же, но медленнее.

Затем объект person может реализовать интерфейс для работы со спецификой движения «конечностей».