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?
asked Oct 10, 2011 at 11:05
3 Answers
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.
answered Oct 10, 2011 at 11:14
-
So if I have another class that uses the radius property is the class incorrect? In the example im currently working on I need to update a status and Activation date then save. Should I impliment ChangeStatus and a ChangeActivationDate methods instead? Oct 10, 2011 at 11:29
-
@Tom Squires Do all classes (now and potential future) that would implement this interface have the ability to change their status and/or activation date? If these methods are taking parameters, would all classes that implement this interface take the same parameters when changing status and/or activation date?– Thomas Owens ♦Oct 10, 2011 at 11:34
-
status yes, activation date no. I currently have diffrent types of request that inherit from one abstract request. Im thinking the interface should be on request not say orderRequest. Is that right? Oct 10, 2011 at 11:41
-
@TomSquires If you have a class hierarchy of requests, then the capability to change request can go into the interface, as long as you have it accept the highest possible class in the request class hierarchy. Then, each class can validate the arguments to ensure that it can handle it, using return types and/or exceptions to deal with invalid data.– Thomas Owens ♦Oct 10, 2011 at 11:43
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.
int someId { get; set; }works. That said, full consideration should be made as to whether the property should be part of the interface.