Why is it "methods against properties"? A method does something. A property is, well, a member of an object. They're totally different things, although two kinds of methods commonly written - getters and setters - correspond to properties. Since comparing properties with methods in general is not meaningful, I'll assume you meant to talk about getters/setters.
Getter and setter method pairs are a code smell.
Not necessarily, I'd argue, but either way this isn't a matter of getters/setters vs. properties but a matter of whether either should be used. Also note that you can e.g. leave out the setX part just like you can make read-only properties.
What is important to a consumer of an object is what it does, not how it does it. Its behavior is what it does; its state is how it does it. If you find yourself caring about an object's state (except for persistence, though this also breaks OO), you're simply not doing OOP and losing out on its advantages.
A highly questionable attitude. If the GUI wants to output data held by a DataStuffManagerImpl, it needs to get that number from it somehow (and no, cramming half of the application into the widget class is not an option).
As the property gets more and more complex, the performance indication of using a property seems less and less truthful.
[Methods have] No performance guarantees. The API will remain truthful even if the method gets more complex. The consumer will need to profile their code if they are running in to performance issues, and not rely on word-of-API.
In almost all cases, all the validation logic etc. is still effectively O(1), or otherwise negible in cost. If not, perhaps you've gone too far and it's time for a change. And a getX() method is usually treated as cheap as well!
Sure, typing myObject.Length is easier than typing myObject.Length(), but couldn't that be fixed with a little syntactic sugar?
Properties are that syntactic sugar.
Less for the consumer to think about. Does this property have a setter? A method sure doesn't.
"Is there a setter for this getter?" Same difference.
The programmer of the API will think more deeply about methods with return values, and avoid modifying the object's state in such methods, if possible. Separation of commands from queries should be enforced wherever possible.
I'm not sure what you're trying to tell us here. For properties, there's an even stronger unwritten law not to cause side effects.
Why would you need to inject private properties? That's not what DI is for. Injecting private properties would violate encapsulation.
One of the constructor overloads on your class should specify everything the class needs to instantiate. If the class can't specify what it needs in it's public API, then it doesn't need it.
From http://natpryce.com/articles/000783.html (emphasis mine):
There are two aspects to Dependency Injection. Firstly, an object's
interface should define the services that the object requires as well
as those it provides. Secondly, the code that satisfies the
requirements of an object by giving it a reference to the services of
is collaborators is external to both the object and its collaborators.
For this reason, the pattern also used to be called "third-party
binding" or "third-party connect": some third party is responsible for
connecting and satisfying the service requirements of a component (the
party of the first part) with those provided by another component (the
party of the second part).
The name "Dependency Injection" only relates to the second aspect. And
worse, makes it sound like dependencies are "injected" through the
object's encapsulation boundary rather than explicitly defined as part
of the object's API. And so we get "dependency injection" APIs, like
that in JavaEE 5, which use reflection to poke dependencies into an
object's private fields, bypassing the constructor, adding a great
deal of complexity to client & test code while not providing the
benefits that the Dependency Injection pattern should deliver.
Best Answer
Arrays are reference types. That is when a property returns an array object it's returning a pointer/reference to it's internal array. The caller of the property can now modify that internal array (as they have a pointer to it), this is generally unwanted. To stop this you can return a copy of the internal array but now your doing a memory allocation and copy every time the property is used, and given that properties are meant to be light-weight that's not good.
This happens with any reference type that is mutable. If you have a private reference to a mutable reference type (Like a Stream, List or Dictionary) and you return that reference in a property than the caller can modify your data. If you have a value type (structs in C#) than they are always copied when they're returned from the property so the caller can't then modify your internal version of the data.