I understand why it is a good idea to code to an interface rather than to a concrete class. I find it hard to implement though as other methods generally need to use properties of the given object. Have I got the wrong end of the stick?
I don't see why needing properties matters. Don't focus on what you need to perform the operation, but rather what operations are needed. The data needed to perform said operations will be determined by the implementing classes.
For example, you have a
Shape interface. One of the methods in this interface is
getArea(). You say that anything that is a
Shape must be able to calculate its area - that implies that it must have the appropriate properties and members to do so. If a
Circle class implements the shape interface and needs a
getArea() method, that implies that (since
getArea() doesn't take any parameters), that the
Circle instance must be aware of it's radius. If a
Rectangle class implements the
Shape interface, that implies that it must somehow maintain its length and width.
In the case where you need external access to a property of an object you should make it part of the interface. The usual convention is to add set_foo() and get_foo() methods to provide this access.
It is fairly common to need a few getter and setter functions, but you should think about the interface before adding too many. In particular you should make sure that the property is a property of the class, not of the implementation. Don't expose implementation details outside of the class, only properties which will always be a part of any reasonable implementation of that class.
Think of interface conformance as a step beyond type safety. Identify things that are changed and ways they can be changed, define interface that provides them all and then while writing to interface assures you don't worry you'll confuse parameters or mess up units.
You can always assign special meta-values for "Do not affect" or "Not applicable", stubs that discard unnecessary information or provide blanket "default" values if your interface is "on the large side". But you're better off if you use more granular, smaller interfaces to cover smaller chunks of functionality. It will be better to separately implement "work data" and "configuration" interfaces, than requiring implementation of one huge "input data" interface, or even split "work data" further for various sources/types, like Activation and Status being separate interfaces - classes that need both, implement both.