Why interfaces?

[che]

First of all, I like to thank Billy & others who take the time and
effort to advance .NET developers to produce better quality and more
maintainable apps.

My question is, I understand why different layers exist, ui + service
+ repository + domain, to make your app. easier to maintain. What I
don't understand is why introduce interfaces (and IoC, but let's take
this one step at a time) into the mix, e.g. IRepository? Doesn't the
fact having these layers already provide loose coupling and hide
implementation details from layers further up the chain? As far as I
can tell, the reason why you program to interface is to make your app.
more testable; to enable you to mock out DAL, for example. Is this
right?

[Simone Busoli]

Yes, that's one of the reasons. You might want to read this interview to Erich Gamma of the GoF on the topic: http://www.artima.com/lejava/articles/designprinciples.html

[DaRage]

That's right but it all come with cost. the cost of having to maintain
those interfaces and having to do the changes in both the
implementation and the interfaces.

Erich mentions that using interfaces is brittle since it breaks all
the clients if the interface is changed and for that he favors using
abstract class.

if you ask me, i think it introduces too much complexity and too much
effort. I wish that testing tools didn't make me right code
specifically for them.

On Dec 30, 3:12 am, "Simone Busoli" <simone.bus...@gmail.com> wrote:
> Yes, that's one of the reasons. You might want to read this interview to
> Erich Gamma of the GoF on the topic:http://www.artima.com/lejava/articles/designprinciples.html
>

[Simone Busoli]

I don't think that a discussion in this thread would bring anything good. It's been discussed in so many places and it's so widely adopted that I don't see the rationale behind stating that it's not good.

Just to make things clearer, this is not to make testing tools happy, I don't remember any ten-year-old book talking about patterns and principles mentioning testing tools.

Please, read some articles by Bob Martin about SOLID, especially the dependency inversion principle.

[DaRage]

since this such a conventional wisdom why don't you tell us why
instead of keep referring to what other people are saying.

On Dec 31, 8:19 am, "Simone Busoli" <simone.bus...@gmail.com> wrote:
> I don't think that a discussion in this thread would bring anything good.
> It's been discussed in so many places and it's so widely adopted that I

> don't see the rationale behind stating that it's not good.Just to make

[Luis Abreu]

It's only for tests...in fact, making testing easy is a nice side effect.
Now, you won't be using interfaces all over the place. You only need to use
them when/where you need it.

I believe the IRepository example was mentioned...I'm in favour of its use.
Even though today most of the stuff will be kept on a database, that info
should not get inside my domain. And with this approach I can easily get my
data, say, from a web service by simply exchanging the implementation with
another one without any changes on the code that uses the interface...

---
Luis Abreu

[Kyle Baley]

It's a bit of a rabbit hole to start a discussion on interfaces vs. abstract classes, isn't it? What are we going to add to the conversation that hasn't been covered here:

 

http://haacked.com/archive/2008/02/21/versioning-issues-with-abstract-base-classes-and-interfaces.aspx

http://haacked.com/archive/2008/02/21/abstract-base-classes-have-versioning-problems-too.aspx

 

Generally speaking, I prefer interfaces. I haven't felt any pain in maintaining both an interface and an implementation as you mention. Most of the time, the interfaces are pretty small anyway (otherwise, there are SRP issues). But I have felt pain trying to maintain abstract base classes. When do you decide a method should go on an abstract base class? What are the ripple effects if you change it?

 

These are rhetorical questions because I've heard the answers. Most of them boil down to the same ones I generally give in favour of interfaces: If you design it properly, you won't have these problems. And I will freely admit, I was much greener when I favored abstract base classes which probably accounted for much of my pain. 

[Kyle Baley]

My informal twitter poll on the question: interfaces or abstract base classes.

 

The overwhelming majority was predictable: both/either/depends

[Simone Busoli]

Because there would be a lot to say, which has been covered thoroughly in texts by people far better than me at explaining things to others. If you RTFM, you'd know what SOLID principles are, and working with abstractions is one key point to achieve them.

And no, it's not just for testability.

[Jerome]

a lot of oo design principle discussions dont seem to account for the fact that c# doesn't support multiple inheritance which is a factor in deciding whether to use interfaces or abstract classes.



 

2008/12/31 Kyle Baley <ky...@baley.org>

[che]

Another question I want to ask everyone is, would you use the same
architecture to develop enterprise as well as mid-sized projects with
20 entities/tables? Surely there is a cost to maintaining the
different layers. For smaller projects, I'm really tempted to use
something like ActiveRecord or even Subsonic to rev up project lead
time.

[Luis Abreu]

I tend to go with interfaces too, unless there really is something “I need” that should be shared by all instances of that type (ok, kind of vague, but hey, it’s new year’s eve, right?:) Happy New Year everyone!)

 

---

Luis Abreu

[Luis Abreu]

Well, yeah, there's a cost, but most of the projects I've been envolved with
have grown their initial expectations...but again, there's yagni, right?

The truth is that after I've started applying DDD (and I'm still studying
it) I'm hooked and I'll always use several of its main principles even in
small project.

---
Luis Abreu


> -----Original Message-----
> From: sharp-arc...@googlegroups.com [mailto:sharp-
> archit...@googlegroups.com] On Behalf Of che
> Sent: quarta-feira, 31 de Dezembro de 2008 17:06
> To: S#arp Architecture
> Subject: Re: Why interfaces?
>
>

[Kyle Baley]

Ya, after a while, some of it just becomes rote and it doesn't take much extra time to do things the same as you would a larger project. Besides, my smaller applications are ones I don't come back to often. It would be a pain to have to figure out the architecture all over again instead of just using my default one.

[DaRage]

RFTM is out of place her my friend. there is no manual to read when it
comes to architecture otherwise the whole thing would be much easier
wouldn't it.

now I know about SOLID but do you know about YAGNI and DRY? another
question to you.. if it's not for test what is it for? can you come up
with one reason? just one? one.. ok?

[Luis Abreu]

I've already mentioned loose coupling...don't you agree?

---
Luis Abreu


> -----Original Message-----
> From: sharp-arc...@googlegroups.com [mailto:sharp-
> archit...@googlegroups.com] On Behalf Of DaRage
> Sent: quarta-feira, 31 de Dezembro de 2008 22:02
> To: S#arp Architecture
> Subject: Re: Why interfaces?
>
>

[Damon Wilder Carr]

I agree we cannot add much here but I will offer this perspective which many
technologists still miss.

I think what this is truly about is simple and deceptive in that it is no
all about the code.

1) Reliable, semi-immutable implementation free representations you provide
others so they have a chance to use your work

2) Concepts that mirror the business domain, not the strange contextual
demands of any technology in that interface

3) The ability to 'jump through hoops' if required in the 'nasty
implementation' via a concrete implementer of above, which nicely shields
pollution of your API (which is what we are also talking about here) from
the technology/crap that often makes an API unusable

Code now is more then ever an exercise is writing consumable services that
mirror the domain, not the implementation choices. This is why Domain
Specific Languages are so compelling. The developers can write code that
reads like a functional spec.

So I would say indeed we could discuss architecture, design by contract,
etc. but the ultimate benefit in my opinion after 20 years of doing it is
this is about a fighting chance at true reuse, and true elimination of the
disconnect between the code and the problem domain.

Damon

[DaRage]

well...that depends what do you mean by loose couple and what is
achieved by it. if you mean that having dependency on an interface
allows the switching implementation then you're right, that is better
than having the dependency on the implementation. but if there is only
one implementation to the interface then what's the point? isn't that
YAGNI?

mind that what i mean by implementation is not a mock implementation
for testing purposes.

[Luis Abreu]

> one implementation to the interface then what's the point? isn't that
> YAGNI?
>
> mind that what i mean by implementation is not a mock implementation
> for testing purposes.

Might be...but not in this case. For instance, with the current interfaces I
can skip NHibernate if I want that. So, in this case I'm in favor of the
interface.

Luis

[DaRage]

what do you mean by skip NHibernate? do you mean switch to another
persistence framework?

if so, i don't think that's a required feature nor i think it's
achievable in real projects. I don't know about you but I've never
switched persistance framework because that's usually a decision make
in the beginning of the project and well thought in advance. isn't
this YAGNI again?

[Luis Abreu]

> what do you mean by skip NHibernate? do you mean switch to another
> persistence framework?
>

And how about simply don't caring about it? Using an interface for the
repository in this case is a must to guarantee that infrastructural details
don't creep into my domain. This is important to me: keep my components
loosely coupled is something I try to get really hard.

> if so, i don't think that's a required feature nor i think it's
> achievable in real projects. I don't know about you but I've never
> switched persistance framework because that's usually a decision make
> in the beginning of the project and well thought in advance. isn't
> this YAGNI again?

Well, I was not as lucky as you and I've had to work in several apps where
persistence was mixed between web services calls, "standard" ado.net and NH
(and yes, we changed persistency framework after releasing v1 of the
product). But this isn't the important thing here and that is not the only
reason I say it's important to have an IRepository interface. To me, the
most important thing is that with this approach gives me better coupling
between the components and db information stays out of my main domain
project.

Again, there really isn't any well defined approach that works everywhere
but I think that the IRepository interface is a good option for this
scenario.

I'm still not sure on why you say this is YAGNI...

Luis

[Kyle Baley]

One approach I've seen is to put off even creating a database until the last possible moment. As Luis said, it's an infrastructure concern so I don't want to think about it until I absolutely need to. That's a little too extremist for my taste but is certainly viable when you use interfaces. (And, it should be said, also with ABCs but you'd be overriding a lot.)

 

I think the YAGNI comes in when you ask "Why am I abstracting out the persistence layer at this point when I know I'm going against a SQL Server database?" It's a fair question and is kind of related to the other one on using a simpler architecture for smaller projects. I've wrestled with it many times while working on a small application for my dad's company. One in which there will almost certainly be only one developer on it, hopefully me for a very long time. But in the event of my untimely demise, is he going to be able to find someone to take up the mantle at the same price I'm charging him (i.e. nothing) for this "complicated" application? Perhaps a less involved approach would be easier for a junior person to understand. Because you just know the person he gets will be a cocky punk that will look at it and say "this is crap" and re-write it.

[DaRage]

I'll try to keep it short. i agree with you and I too like the domain
to be pure of any infrastructure and using interfaces does facilitate
this.

the YAGNI goes to the need of having to switch persistence because for
most projects (not only small) that's not a requirement. you said you
worked on a project like that and I believe you but that's not a
reason to include it in a generic architecture like S#arp.

you see i'm arguing with you and I'm half convinced. However, I'm
adamant believer that things should be kept as simple as possible but
not simpler to keep productivity high and also not litter the
architecture with artifacts that are not necessarily needed.

[DaRage]

for me I would never leave the database until the end because that's a
recepie for failure i think.

I don't think the idea behind DDD is to ignore the database but not to
make it the primary focus.

[Kyle Baley]

Yeah, I agree with you (though it's not quite as disastrous as you might think, especially with NHibernate). Typically, I put off creating the database only until I write my first integration test. Which is usually pretty early.

[Kyle Baley]

"that's not a reason to include it in a generic architecture"

 

What does "it" refer to here? I don't see anything in S#arp that is overkill.

[DaRage]

it: abstracting the database for the purpose of being independent of
database technology because most projects and especially big ones
never change the database technology they use.

[Kyle Baley]

Isn't that kind of the definition of NHibernate?

[Luis Abreu]

> I'll try to keep it short. i agree with you and I too like the domain
> to be pure of any infrastructure and using interfaces does facilitate
> this.

It seems like we agree on it, then :)

>
> the YAGNI goes to the need of having to switch persistence because for
> most projects (not only small) that's not a requirement. you said you
> worked on a project like that and I believe you but that's not a
> reason to include it in a generic architecture like S#arp.

I see YAGNI as adding features you're not needing. I see the IRepository
interface as decoupling. That's why I don't think it's YAGNI. Again, I might
be wrong, but until I'm proved wrong, that's how I'm seeing the current
architecture. And what do you guys think?

Luis

[DaRage]

in theory.. but in practice nHibernate does 80% of the database
interaction and 20% is hard wired. and this 20% is database dependent.

[Damon Wilder Carr]

I have for the last few years as a matter of necessity (why waste all that time?) left final DB schema to the end.

 

It’s insanely easy once you get used to it. After all the only transform in most cases would be related to two items:

 

1)       Performance Tuning (and we know to do that last already)

2)      Legacy Compatibility for part of the schema

3)      Test Data Maintenance (to avoid imports to changed schema)

4)     Complex Second-Level Caching Scenarios

 

 

I am having a hard time thinking what possible value could be added in caring until at least the 80% done mark about denormalization, index optimization, etc.

 

#4 – If your ORM does not abstract this, get a new ORM. Don’t try unless you are cornered by a knife wielding ninja to write a read/write distributed synchronized cache here either… We all know to love immutability I am assuming when we can have it.

 

#3 – test data : If you care about this your not likely using a mock framework with any automated build regression. That is a much, much larger showstopper.

 

#1 - That is deployment/non-functional performance related and you couldn’t possibly know what you need to do until the end anyway. See: Premature Optimization.

 

NHibernate and the wrapper over it (ActiveRecord) as well as others really make this painfully easy. It gets people excited when you talk about it because it seems to be against conventional wisdom, but after bring home many quite large DDD systems for a long time now, what could I be missing?

 

If there is any downside, I cannot imagine the huge time savings over the cycles would not exponentially make up for it.

 

Damon

 

From: sharp-arc...@googlegroups.com [mailto:sharp-arc...@googlegroups.com] On Behalf Of Kyle Baley
Sent: Friday, January 02, 2009 11:12 AM
To: sharp-arc...@googlegroups.com
Subject: Re: Why interfaces?

 

Yeah, I agree with you (though it's not quite as disastrous as you might think, especially with NHibernate). Typically, I put off creating the database only until I write my first integration test. Which is usually pretty early.

> > Luis<br

[Damon Wilder Carr]

Uh.. I mean 4 items (grin)..

 

I have for the last few years as a matter of necessity (why waste all that time?) left final DB schema to the end.

 

It’s insanely easy once you get used to it. After all the only transform in most cases would be related to two items:

 

1)       Performance Tuning (and we know to do that last already)

2)      Legacy Compatibility for part of the schema

3)      Test Data Maintenance (to avoid imports to changed schema)

4)     Complex Second-Level Caching Scenarios

 

 

I am having a hard time thinking what possible value could be added in caring until at least the 80% done mark about denormalization, index optimization, etc.

 

#4 – If your ORM does not abstract this, get a new ORM. Don’t try unless you are cornered by a knife wielding ninja to write a read/write distributed synchronized cache here either… We all know to love immutability I am assuming when we can have it.

 

#3 – test data : If you care about this your not likely using a mock framework with any automated build regression. That is a much, much larger showstopper.

 

#1 - That is deployment/non-functional performance related and you couldn’t possibly know what you need to do until the end anyway. See: Premature Optimization.

 

NHibernate and the wrapper over it (ActiveRecord) as well as others really make this painfully easy. It gets people excited when you talk about it because it seems to be against conventional wisdom, but after bring home many quite large DDD systems for a long time now, what could I be missing?

 

If there is any downside, I cannot imagine the huge time savings over the cycles would not exponentially make up for it.

 

Damon

 

From: sharp-arc...@googlegroups.com [mailto:sharp-arc...@googlegroups.com] On Behalf Of Kyle Baley
Sent: Friday, January 02, 2009 11:12 AM
To: sharp-arc...@googlegroups.com
Subject: Re: Why interfaces?

 

Yeah, I agree with you (though it's not quite as disastrous as you might think, especially with NHibernate). Typically, I put off creating the database only until I write my first integration test. Which is usually pretty early.

> > Luis<br

 

[Kyle Baley]

Can you give me an example? I just finished a WinForms application where I developed locally on SQL Server (because I was disconnected from our network). When I deployed to users' machines, the only change I made was to the config file to have it connect to Oracle.

[DaRage]

There are plenty of examples of applications I worked on. one example
is implementing search algorithm where i found that I had to do the
sql myself and could not rely on nHibernate to generate it since it
had unions and recursive queries.

[Billy]

Che,

I don't intend to hijack this thread, but you're right in suggesting
that something like ActiveRecord or Subsonic would be more appropriate
in some situations. S#arp Architecture is not a one-shoe-fits-all
solution and could be seen as being a bit overkill for trivially
simple applications. In fact, I used MonoRail/ActiveRecord a few
months ago for a very small ecommerce store that I did recently...it
was a very small application and ActiveRecord worked well for the
need.

Every project demands a careful analysis of various alternatives to
determine which set of tools is most appropriate for the task at
hand. I believe that #arch covers 80% of .NET, data-driven web sites
nicely but that there are projects that it may not be appropriate
for. It's certainly up to you and your team to decide if it's
appropriate for the project at hand and what tools should be used if
not.

Billy

[Billy]

DaRage,

After catching up with the remainder of the thread, I think my
response to Che (which I feared would hijack the thread) is actually a
good response in this case as well. S#arp Architecture is not trying
to be anything for anybody. It's appropriate for those who buy-in to
the idea of coding to interface. It's appropriate for those who
believe that the database is an infrastructural detail to be addressed
after the domain and business logic has already been established. In
my opinion, it's not appropriate for people who prefer a more data or
model driven approach. In short, there are many ways to skin a cat
and S#arp Architecture is just one of them. If you do not buy into
the principles behind it (which aren't objectively "best practices"
but simply "practices that we believe in"), then you may want to
consider other alternatives.

I do not wish to come across as laconic, but it's almost ironic to
discuss whether or not coding to interface is a good idea in this
forum. If you find a model driven approach more appropriate, you may
want to consider looking at ADO.NET Entity Framework or ActiveRecord.
But we certainly welcome you here if you've been swayed at all!

Billy

[Billy]

And with respect to your 3rd point, the SQLite integration that Lee
Carter provided greatly mitigates the risk of having to maintain a
"live" testing database and the fragile tests that creates. Lee's
addition has greatly reduced time that I spend maintaining test data
while still being able to support data communications.

Billy

On Jan 3, 1:46 pm, "Damon Wilder Carr" <da...@agilefactor.com> wrote:
> I have for the last few years as a matter of necessity (why waste all that
> time?) left final DB schema to the end.
>
> It's insanely easy once you get used to it. After all the only transform in
> most cases would be related to two items:
>
> 1)       Performance Tuning (and we know to do that last already)
>
> 2)      Legacy Compatibility for part of the schema
>
> 3)      Test Data Maintenance (to avoid imports to changed schema)
>
> 4)     Complex Second-Level Caching Scenarios
>
> I am having a hard time thinking what possible value could be added in
> caring until at least the 80% done mark about denormalization, index
> optimization, etc.
>

> #4 - If your ORM does not abstract this, get a new ORM. Don't try unless you

> are cornered by a knife wielding ninja to write a read/write distributed

> synchronized cache here either. We all know to love immutability I am

> assuming when we can have it.
>

> #3 - test data : If you care about this your not likely using a mock

> <http://ado.net/>  and