http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Not only for that, although this is the classic reason for interfaces. That is something that I would call YAGNI on. What I am striving for is to have IAuthenticationService and an ActiveDirectoryAuthenticationService. With a big disconnect between the two. I don't give a chopped monkey liver for the impl when I am using it, and I really shouldn't. http://ayende.com/2810/more-reasons-for-interfaces#comment9http://ayende.com/2810/more-reasons-for-interfaces#comment9Wed, 03 Oct 2007 09:43:16 GMTI think I get it now. So in future you could create a different implementation and then change between them if need be? Thanks for your help by the way. http://ayende.com/2810/more-reasons-for-interfaces#comment8http://ayende.com/2810/more-reasons-for-interfaces#comment8Wed, 03 Oct 2007 09:26:45 GMTI don't think it violate DRY. If one of the method change, I make the change in one place, and let R# handle it. The main reason that I am using interfaces instead of classes is that I want to separate the WHAT from the HOW http://ayende.com/2810/more-reasons-for-interfaces#comment7http://ayende.com/2810/more-reasons-for-interfaces#comment7Wed, 03 Oct 2007 08:46:55 GMTThanks for the reply Ayende but doesn't that kind of violate the don't repeat yourself principle? If one of the methods change then you have to update the interface as well as the implementation (well technically you don't but the interface is then pointless). Why wouldn't you just create a normal class instead with blank methods i.e. F() { } and then go from there? http://ayende.com/2810/more-reasons-for-interfaces#comment6http://ayende.com/2810/more-reasons-for-interfaces#comment6Wed, 03 Oct 2007 08:31:09 GMTDave, I tend to be of mixed mind here, often enough I will pre-create the interface and some initial methods, proceed to use it, then write up an implementation. That approach make it very easy to just add/remove methods when I explore what I need of it. Other times I will just see the need of it and create it as I go along. http://ayende.com/2810/more-reasons-for-interfaces#comment5http://ayende.com/2810/more-reasons-for-interfaces#comment5Tue, 02 Oct 2007 21:47:04 GMTCould you please expand on this approach a bit more? Do you create all your interfaces first to define what is going on and then implement them classes to define how they work? Is that so that if you want to change the behaviour you can simply implement the interface again and revert back to the old implementation if required in the future? Thanks. http://ayende.com/2810/more-reasons-for-interfaces#comment4http://ayende.com/2810/more-reasons-for-interfaces#comment4Tue, 02 Oct 2007 09:13:35 GMTI think one reason why you have a greater appreciation for interfaces and build your code to allow you to swap in implementations is that you are comfortable with IoC. It's just a logic way of doing things, once you're used to an infrastructure that provides you with the appropriate implementation depending on configuration. As long as people still primarily write the code that creates a concrete class by hand and then have to cast it to an interface, using an interface easily becomes an afterthought until you need a second implementation. http://ayende.com/2810/more-reasons-for-interfaces#comment3http://ayende.com/2810/more-reasons-for-interfaces#comment3Sun, 30 Sep 2007 05:40:06 GMTI agree with you. Great post. http://ayende.com/2810/more-reasons-for-interfaces#comment2http://ayende.com/2810/more-reasons-for-interfaces#comment2Sat, 29 Sep 2007 14:57:08 GMTI do exactly the same thing for exactly the same reason. http://ayende.com/2810/more-reasons-for-interfaces#comment1http://ayende.com/2810/more-reasons-for-interfaces#comment1Sat, 29 Sep 2007 04:41:30 GMT