How Cerebrus? I don't understand why he is talking about "interface". And following is also confusing,
"We auto-gen the interface and implement the underlying code for the save and selectbyid methods in our first iteration" Generating the interface and then implementing the underlying code? Implementing where? obviously in some Class. Which means they are providing the class to clients NOT interface. And to make it simple why putting the methods if we haven't implemented them yet? On Fri, Nov 6, 2009 at 2:55 PM, Cerebrus <[email protected]> wrote: > > I think this is a perfect example of the correct use of Interfaces in > the context of modules under active development. It allows consumers > to interact with the public interface regardless of the state of > internal implementation of functionality. Abstract classes are not the > solution, in this case. > > I think "rbr" should clarify exactly what other metadata are the > consumers of the API looking for ? XML Comments are a good way to > indicate that the functionality is not yet implemented. I don't > recommend using the NotImplementedException route because that is a > runtime evaluation method. > > You could define your custom attribute (such as > "NotImplementedAttribute") but the consumers of the API need to have a > way to evaluate at design time what that attribute entails. > > On Nov 6, 7:05 am, Paulo Roberto Pellucci <[email protected]> > wrote: > > I guess your point is beyond the use of interfaces. Since interfaces is a > > contract and it will only allow public methods, shouldn't you be using > just > > a class or, maybe abstract class? > > > > > > > > > > > > On Thu, Nov 5, 2009 at 9:27 PM, rbr <[email protected]> wrote: > > > > > I have a problem that I am looking for a clean way to solve. > > > Currently, we provide interfaces as public apis for our internal > > > customers to consume. However, we may build and deploy an entire > > > interface that may take several iterations to fully conplete. For > > > example, say we have an IBankingSvc that has a save, selectbyid, > > > select by name and a delete method. We auto-gen the interface and > > > implement the underlying code for the save and selectbyid methods in > > > our first iteration. When we deploy this code for consumption by our > > > internal clients, we currently use XML comments to indicate the > > > selectbyname and delete methods are not yet implemented. > > > > > Not suprisingly, this is not always sufficient for the consumers of > > > our API. Is there a nice way to mark these methods say, with an > > > attribute, that would either hide these methods or clearly mark them > > > as not implemented? I am not familiar with a way to accomplish this > > > and would greatly appreciate a more graceful sulution. > > > > > Thanks in advance for any ideas or suggestions. > > > > > rbr > > > > -- > > Atenciosamente, > > Paulo Roberto S. Pellucci- Hide quoted text - > > > > - Show quoted text -
