Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 1 down vote favorite

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?

share|improve this question
2  
You can use auto-implemented properties and getter methods, should you need them e.g. int someId { get; set; } works. That said, full consideration should be made as to whether the property should be part of the interface. – StuperUser Oct 10 '11 at 11:17
Keep it simple - Don't use something because it is better. Use what you know is necessary to do the job right. – Emmad Kareem Oct 10 '11 at 12:13
Okay but were they talking about interfaces as in class APIs or interfaces the construct? – Erik Reppen Mar 7 at 1:41

3 Answers

up vote 5 down vote accepted

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.

share|improve this answer
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? – Tom Squires Oct 10 '11 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 '11 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? – Tom Squires Oct 10 '11 at 11:41
ps. thanks for your help :) – Tom Squires Oct 10 '11 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 '11 at 11:43
up vote 2 down vote

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.

share|improve this answer
up vote 0 down vote

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.