Code Review: Active Directory Abstraction

[Bobby Johnson]

Hello Group,

I have been working recently to help clean up an ASP.NET code base for an internal LOB application. The code was originally created siloed cowboy style by a developer not very familiar with SOLID principals or TDD. So it is a bit of a spaghetti mess and Mr. Feathers' book is getting quite a workout. I have started building abstractions for each of the external touch points like ActiveDirectory and building them up as I see how those resources are being used.

This particular bit of code that I am going to show is attempting to hide AD goo behind an IUserInformationStore interface that looks like this:

public interface IUserInformationStore
    {
        User FindUser(IPrincipal principal);
        IEnumerable<User> FindUsersInRole(string roleName);
    }

The code shows integration tests for actually touching AD and the current implementation of the ActiveDirectoryUserInformationStore class. A specific point of interest that I am interested in hearing your comments on is the use of Extension Methods like MapToUser() and Get<T>(). I have never done this before and am curious what others who might be a bit more experienced than me think of it. I started doing this with the Get<T>() extension method because I did not like all the noise that casting from object creates (sadly the AD stuff in .NET holds a lot of stuff as arrays of objects) and the usage of Get<T>() I felt was more expressive of my intent. Then I started doing it with other "clunky" bits of code and now I am wondering if it is worth it.

Here is the code: http://gist.github.com/271356

Comments? Suggestions? Criticism? All welcome.


Bobby

--
"The explanation requiring the fewest assumptions is most likely to be correct."

- Occam’s Razor
http://en.wikipedia.org/wiki/Occam's_Razor

[Curtis Cooley]

This is more of a nitpick, and something I'd like to get others opinions on, but I hate .NET's idiom of putting I in front of interfaces. It munges up the domain model. I've always tried to name my interfaces more abstractly then the classes that implement them. So if I have a Car and I want an interface for it, I might choose Vehicle. In the .NET world you'd have Car implement ICar and then down the road have Airplane implementing ICar.

I know this is the way .NET is done, but I feel names are very important to code readability.

Plus I've always despised hungarian notation.

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To post to this group, send email to software_cr...@googlegroups.com.
To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.

--
Curtis Cooley
curtis...@gmail.com
home:http://curtiscooley.com
blog:http://ponderingobjectorienteddesign.blogspot.com
===============
Leadership is a potent combination of strategy and character. But if you must be without one, be without the strategy.
-- H. Norman Schwarzkopf

[Bobby Johnson]

That is an interesting comment. As a person who has done .NET dev for the better part of the last decade, I would say your Vehicle interface is more confusing in terms of code readability. I have no way of knowing just by looking at the usage of it if it is an interface, abstract base or an implementation. And I guess that is your point, it shouldn't matter to the consumer.

For me I see the interface as defining a contract between collaborators explicitly and the "I" is a part of that explicitness. And it't the way everyone else does it... 8)

[Jason Gorman]

It's not the way everybody else does it, I think. It used to be the
way Microsoft C++ programmers did it, which I think is where the
convention comes from. The client code doesn't care that it's an
interface, and if you're implementing or extending an abstraction, it
will be necessarily obvious. It comes from the same stable that used
to put things like m_ to denote member variables (redundant) and str,
int, obj etc to denote variable type. In a type safe language with
intellisense it imparts no new information and makes the code a little
less English-like.

Jason Gorman
www.codemanship.com

On Jan 9, 7:36 pm, Bobby Johnson <bobby.john...@gmail.com> wrote:
> That is an interesting comment. As a person who has done .NET dev for the
> better part of the last decade, I would say your Vehicle interface is more
> confusing in terms of code readability. I have no way of knowing just by
> looking at the usage of it if it is an interface, abstract base or an
> implementation. And I guess that is your point, it shouldn't matter to the
> consumer.
>
> For me I see the interface as defining a contract between collaborators
> explicitly and the "I" is a part of that explicitness. And it't the way
> everyone else does it... 8)
>

> On Sat, Jan 9, 2010 at 10:30 AM, Curtis Cooley <curtis.coo...@gmail.com>wrote:
>
>
>
>
>
> > This is more of a nitpick, and something I'd like to get others opinions
> > on, but I hate .NET's idiom of putting I in front of interfaces. It munges
> > up the domain model. I've always tried to name my interfaces more abstractly
> > then the classes that implement them. So if I have a Car and I want an
> > interface for it, I might choose Vehicle. In the .NET world you'd have Car
> > implement ICar and then down the road have Airplane implementing ICar.
>
> > I know this is the way .NET is done, but I feel names are very important to
> > code readability.
>
> > Plus I've always despised hungarian notation.
>

> >>http://en.wikipedia.org/wiki/Occam's_Razor<http://en.wikipedia.org/wiki/Occam%27s_Razor>

>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "software_craftsmanship" group.
> >> To post to this group, send email to
> >> software_cr...@googlegroups.com.
> >> To unsubscribe from this group, send email to

> >> software_craftsma...@googlegroups.com<software_craftsmanship%­2Bunsu...@googlegroups.com>

> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/software_craftsmanship?hl=en.
>
> > --
> > Curtis Cooley

> > curtis.coo...@gmail.com

> > home:http://curtiscooley.com
> > blog:http://ponderingobjectorienteddesign.blogspot.com
> > ===============
> > Leadership is a potent combination of strategy and character. But if you
> > must be without one, be without the strategy.
> > -- H. Norman Schwarzkopf
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "software_craftsmanship" group.
> > To post to this group, send email to
> > software_cr...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > software_craftsma...@googlegroups.com<software_craftsmanship%­2Bunsu...@googlegroups.com>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/software_craftsmanship?hl=en.
>
> --
> "The explanation requiring the fewest assumptions is most likely to be
> correct."
>

> - Occam’s Razorhttp://en.wikipedia.org/wiki/Occam's_Razor- Hide quoted text -
>
> - Show quoted text -

[Corey Haines]

I second Jason's comment.

Personally, I spent a few years in using the I as the subject of the
verb phrase that the interface described. So, for example, what is the
role it describes?

I have a role for transporting people that a concrete class Bus.

ITransportPeople {
load(person)
unload(person)
}

class Bus : ITransportPeople {
}

Rarely did I have an interface that was a noun-phrase.

-Corey

> To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
>
>
>
>

--
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines

[Mark Nijhof]

Well within the .Net OSS community prefixing with an I is very common
so you could argue that this is a .Net convention. I like using the I
myself but more because that is what I always used to do. Personally I
always try to not do Car : ICar but more describing behavior so
perhaps something like Car : ICanDrive, IHaveFourWheels

But in my next project I'll do my very best to say no to my inner
drive for the I and try without it instead.

-Mark

> To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.

[Jason Gorman]

I think it makes most sense if interfaces correspond to roles - e.g.,
Person might implement Mother, Teacher, Voter etc with respect to what
specific clients wish to ask them to do.

> >> - Occam’s Razorhttp://en.wikipedia.org/wiki/Occam's_Razor-Hide quoted text -

>
> >> - Show quoted text -
>
> > --
> > You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
> > To post to this group, send email to software_cr...@googlegroups.com.
> > To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/software_craftsmanship?hl=en.- Hide quoted text -

[Ron Jeffries]

Hello, Corey. On Saturday, January 9, 2010, at 3:22:02 PM, you
wrote:

> Personally, I spent a few years in using the I as the subject of the
> verb phrase that the interface described. So, for example, what is the
> role it describes?

> I have a role for transporting people that a concrete class Bus.

> ITransportPeople {
> load(person)
> unload(person)
> }

> class Bus : ITransportPeople {
> }

> Rarely did I have an interface that was a noun-phrase.

That's cool. I wish that had caught on.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
We cannot solve our problems with the same thinking we used when we created them.
-- Albert Einstein

[Corey Haines]

Yeah. You were at SDTConf in 2006 when the ideas and experiments I had done crystallized. .

On Jan 9, 2010 4:18 PM, "Ron Jeffries" <ronje...@acm.org> wrote:

Hello, Corey.  On Saturday, January 9, 2010, at 3:22:02 PM, you
wrote:

> Personally, I spent a few years in using the I as the subject of the > verb phrase that the inter...

That's cool. I wish that had caught on.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
We cannot solve our problems with the same thinking we used when we created them.
 -- Albert Einstein

[Simone Busoli]

I pretty much like they way you wrote the tests, there are just a few things I might have done differently or I would have asked an explanation for the way you did them:

• in the_user_should_not_be_the_default_guest_user why didn't you compare the returned user the an (the) instance of guest user and checked that they were different? Comparing just the name makes me think that you cannot really compare users or that it's just a workaround for some missing functionality.
• the_user_should_have_the_same_user_name_as_the_identity intent is not very straightforward, I would have written either a test helper method to return the identity name without the domain or a domain model property/method on the identity itself (I think you have one below). That way the test would be more to the point and wouldn't have to deal with how to retrieve the name without the domain, which is really not its concern.
• in the other methods of the same test class where you assert on user attributes I would have probably created an expected user an compared that with the actual one, instead of having several test methods checking for each single attribute.
• in the_user_should_be_the_default_guest_user the as the first point, I would compare it with an or the single instance of the guest user.
• in when_searching_for_users_that_belong_to_a_role I'm not sure I would have written both it_should_return_a_list_of_users and there_should_be_at_least_one_user, I would have though about writing a single test method which checked for a non-empty list, but I have a weak opinion about this.

BTW, I have been mostly nitpicking, I think it's well written.

[Bobby Johnson]

As has already been stated, everyone in the .net community does it. So it is a standard convention.

To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.

[Bobby Johnson]

Great feedback Simone. Thank you.

[Simone Busoli]

Rereading it now I noticed several typos, hope it was clear anyway.

[Jason Gorman]

Interestingly, "everybody in the .net community does it" has the
reverse effect on me ;-)

> > > - Occam’s Razorhttp://en.wikipedia.org/wiki/Occam's_Razor-<http://en.wikipedia.org/wiki/Occam%27s_Razor->Hide quoted text -

[Mark Nijhof]

Out of curiosity (and I know not everybody does this, honestly I
wouldn't even be able to give an estimate on percentages, I see both
ways happen) but lets say that 'everybody does it' why would that have
a reverse effect on you?

-Mark

> To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.

[Jason Gorman]

I'm going to stop making jokes on discussion groups. That's my New
Year's resolution.

> >> - Occam’s Razorhttp://en.wikipedia.org/wiki/Occam's_Razor-Hide quoted text -

>
> >> - Show quoted text -
>
> > --
> > You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
> > To post to this group, send email to software_cr...@googlegroups.com.
> > To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/software_craftsmanship?hl=en.- Hide quoted text -

[Mark Nijhof]

Sorry I missed it, perhaps mine should be to pay better attention to
the smileys, and I was honestly curious

[David Starr]

I have gone back and forth on IInterface convention. Firstly, the ICar interface is not the same issue as the I prefix itself. As Mark noted, the ICar is just not a nice interface. If it is simple abstraction you are after, I could see IVehicle with a Car implementation class, but behavior based interface definitions are preferable IMO.

ICanDrive
IGoesFast

So there real question is simply, what is the preference between ICanDrive and CanDrive as the interface name. From years of looking at code, I can tell you that I prefer an indicator in the class name to let me know it is an interface. Admittedly, this is not interesting to the domain, but it is interesting to me as a programmer. I am the one who has to read the code all day, after all.

The reason I want to see the I indicator is that if I don't see it, I probably need to view the definition code file to determine if I am looking at an interface or a class. IMO, that is just wasted keystrokes and time that my brain doesn't need to spend.

Yes, it is a signal for the developer, and I think that's fine as it makes my code more readable and easily maintained.

--
David Starr
Guild 3 Software, Principal Craftsman
208.577.7000
guild3.com | Training: pluralsight.com

[James Martin]

On Mon, Jan 11, 2010 at 6:01 AM, David Starr <da...@guild3.com> wrote:

.. 

The reason I want to see the I indicator is that if I don't see it, I probably need to view the definition code file to determine if I am looking at an interface or a class. IMO, that is just wasted keystrokes and time that my brain doesn't need to spend.

Is having to look at the interface or class definition for something that you're about to make a dependency of your code necessarily a bad thing? At the very least it probably makes you more carefully consider its use in your program. 

Thanks,

James.

[Mark Nijhof]

I think it is most useful when reading existing code, if you are going
to take a new dependency upon it you should know what you are talking
about indeed. But when reading code that is done (for the time being
anyway) then knowing this is useful without having to know the exact
details of the interface itself.

-Mark

[Curtis Cooley]

On Sun, Jan 10, 2010 at 4:05 PM, Mark Nijhof <mark....@gmail.com> wrote:
> I think it is most useful when reading existing code, if you are going
> to take a new dependency upon it you should know what you are talking
> about indeed. But when reading code that is done (for the time being
> anyway) then knowing this is useful without having to know the exact
> details of the interface itself.
>

How exactly is knowing, without bothering to look at the code, that
something is an interface useful? What would you do differently
depending on whether CanDrive is an interface or an abstract class or
a concrete class? If knowing is so useful, why don't .NET programmers
put ACCanDrive in front of abstract classes?

Once upon a time there was a cage full of gorillas. As an experiment,
a bunch of bananas were hung from the top of the cage. Whenever a
gorilla tried to reach a banana, the whole group was sprayed with cold
water. Once the group was conditioned to not try to get a banana, one
gorilla was replaced. Whenever the new gorilla tried to get a banana,
the others pulled him down. When he was conditioned to not to try to
get a banana, another of the original gorillas was replaced. This was
repeated until all of the original gorillas were replaced. None of the
existing gorillas had ever been sprayed by water, yet none of them
would try to get a banana. Why? Because that's the way it had always
been done.

--
Curtis Cooley
curtis...@gmail.com

[Mark Nijhof]

I knew I was a code monkey, never realized I was a gorilla ;P

Interface to me means behavior, but perhaps not all that the
implementation has to offer. But I agree I would find it much more
interesting to see that an actual concrete class is injected, because
then I would wonder why. This happens less often in my code. So
perhaps I need CXxxx ;)

Also I am not against not using the I when dealing with an interface,
I personally find it useful. But as I said in my next project I will
drop the I and see how that feels, I just hope my fellow team mates
don't get a bucket load of cold water thrown at them when I do.

With respect to the gorrilas, by behaving the way they do they didn't
get wet, but the reason why the second generation did it was because
the where trained to do so, now if they would be able to communicate
the reason behind their behavior then I am sure they would try that
first before pulling the new gorrila down. Most humans I know would
try that approach.

Also interesting is that animals that have never been into contact
with humans (whole generations) do not fear them, only those
generations that have learned (by experience) how evil we are to them
fear us.

When I trained my horses or dogs then consistency is key, so certain
behavior results in good while other behavior results in bad outcomes.
Also it is easier to train an animal when side by side with an already
trained animal.

-Mark

Sent from my iPhone

On 11. jan. 2010, at 02.35, Curtis Cooley <curtis...@gmail.com>
wrote:

[Curtis Cooley]

Sorry, Mark, after rereading my post, I admit I was more cheeky than I
should have been, because I am really interested in the questions I
asked. How exactly would you code/design differently if you knew
CanDrive was an interface instead of a concrete class? I'm against the
who I thing because I think it leads to bad domain design and because
I think when coding to an API, you shouldn't care or know. If I am
missing something important, I want to know what I am missing.

Perhaps some examples:

When I see (I'm a Java guy so please pardon the syntax):

public class Car implements CanDrive

I know it's an interface.

When I see:

public class Foo {

CanDrive vehicle;
...
}

I don't care if CanDrive is an interface or class. Should I? If so, why?

Another argument I've heard is that in Eclipse, if you type in
ctr-shift-t (which brings up the type browser) then type I you get a
list of all the interfaces, but I've never actually opened Eclipse and
thought, gee, I wonder what all the interfaces are?

Please, this is not targeted at Mark, since he's admitted to not
seeing value in the I interface idiom, but if there is value, I would
like to know. Otherwise I just consider it another form of outdated
Hungarian notation at best and poor design at worst. To be completely
honest, and I hope I don't offend, but when I see interfaces beginning
with I, the first one I think of is IDontKnowOO

[Bobby Johnson]

I assume you find ruby developer incompetent for using boxcar casing
as well? Seriously, judging a developer on the use of a well known
idiom in a given language calls your credibility into question.

And here I thought I would get some impassioned heat for my use of
extension methods with some good comentary.

Sent from my iPhone

On Jan 10, 2010, at 7:38 PM, Curtis Cooley <curtis...@gmail.com>
wrote:

[John Daniels]

One possible benefit in knowing whether you're dealing with an
interface or a class is concerned with object creation, or, more
correctly, learning about creation in the environment. If it's an
interface then I know it isn't what I would use if I needed to create
objects that have that behaviour. I think there's also some small
benefit in knowing, for an interface, that the effects of invoking
operations on it won't always be the same.

When I'm trying to understand, for example, how to use a large Java
library, any clues I can get from reading existing code are useful. I
don't find the "I" intrusive, but I have some sympathy with the idea
that it might be better to prefix the class names rather than the
interface names. Still, that isn't going to change now.

One other thing: When designing for testability there's sometimes a
need to put an interface in front of every class (although this need
has reduced as test frameworks have matured). In such a world it's
painful to have to invent a new name for the interface. But perhaps
this pragmatism should have no place in our thinking.

--John

(In the interests of full disclosure, I should point out that I played
a small part, via a book I wrote some years ago, in propagating the
use of the I prefix outside the .net community. I don't feel any
regret :-). On the other hand, I don't feel that strongly about it
either, and I haven't used the convention on any projects recently.)

====
Original message
From: Curtis Cooley <curtis...@gmail.com>
Date: 11 January 2010
Time: 3:38:41 AM
Subject: [SC] Re: Code Review: Active Directory Abstraction
----

[Jason Gorman]

I think this discussion is getting unnecessarily heated and people are
probably saying things that are not really justifiable (even in jest).
I would not argue that anyone who sticks an "I" in front of an
interface name doesn't know OO design (it's true that there are many
ex-VB programmers who still don't get OO, but there are more than
their fair share in the Java, Ruby , Python, Perl and C++ communities
who still use SWITCH statements!!! The horror!) And I strongly favour
the opinions of anyone who questions received wisdom, design
conventions and canned formulae for "good code". Design wisdom like
"always use dependency injection" or "singletons are bad" or "don't
use getters and setters" is not real design wisdom, in my experience.
Design decisions need to be made on a case-by-case basis, applying a
balance of concerns (readability, complexity, coupling, speed, memory,
security, scalability, portability etc etc), and the questioning of
them should continue throughout the process.

Jason Gorman
http://www.codemanship.com

On Jan 11, 5:39 am, Bobby Johnson <bobby.john...@gmail.com> wrote:
> I assume you find ruby developer incompetent for using boxcar casing  
> as well? Seriously, judging a developer on the use of a well known  
> idiom in a given language calls your credibility into question.
>
> And here I thought I would get some impassioned heat for my use of  
> extension methods with some good comentary.
>
> Sent from my iPhone
>

> On Jan 10, 2010, at 7:38 PM, Curtis Cooley <curtis.coo...@gmail.com>  

> > On Sun, Jan 10, 2010 at 6:21 PM, Mark Nijhof <mark.nij...@gmail.com>  

> >> On 11. jan. 2010, at 02.35, Curtis Cooley <curtis.coo...@gmail.com>  
> >> wrote:
>
> >>> On Sun, Jan 10, 2010 at 4:05 PM, Mark Nijhof <mark.nij...@gmail.com>

> >>> curtis.coo...@gmail.com

> > curtis.coo...@gmail.com

> > home:http://curtiscooley.com
> > blog:http://ponderingobjectorienteddesign.blogspot.com
> > ===============
> > Leadership is a potent combination of strategy and character. But if
> > you must be without one, be without the strategy.
> > -- H. Norman Schwarzkopf
> > --
> > You received this message because you are subscribed to the Google  
> > Groups "software_craftsmanship" group.
> > To post to this group, send email to software_cr...@googlegroups.com
> > .
> > To unsubscribe from this group, send email to software_craftsma...@googlegroups.com
> > .
> > For more options, visit this group athttp://groups.google.com/group/software_craftsmanship?hl=en

> > .- Hide quoted text -

[Steve Strong]

Of course, other languages differ. In C# we would have:

public class Car : CanDrive

There's no distinction here between classes and interfaces and no way
without navigating to theCanDrive definition to know. For me, I find
that the 'I' prefix does not get in the way but does aid readability,
particularly when it's not my code I'm reading, or if I'm reading
outside of an IDE.

Even in usage, I find it useful to know the difference. If it's an
interface then I know that the implementation can be swapped easily
(for example, during testing). If it's a class, then I need to read
much further before understanding what flexibilty I have with respect
to the actual runtime type.

This is one of those where I don't think there is a "correct" answer;
it's up to the team, the language etc to settle on one and then be
consistent in usage. I certainly don't think that using "I" implies
poor OO skills, just a different perspective on what matters to that
team.

In terms of ubiquitous language, I probably would use "I" or indeed
"interface" at all - I'd much rather refer to a "CanDrive contract".

Just my 2p

Steve

Sent from my iPhone

[James E Taylor]

I am quite shocked that this is being debated by people who wish to
become craftspeople in software. It really doesn't seem important to
me.

However, now I find myself driven to partake, here are my two pence
worth:

There is a (weak IMO) argument that annotating type names is helpful
to overcome IDE limitations.

There is a (slightly stronger) namespace argument that -- in a spring
or TDD or TOD world where everything comes out of interfaces -- you
need to give different names to interfaces and their basic or default
implementations (although I prefer a clean interface name and a dirty
implementation name).

Otherwise I think the point is moot.

[Mark Nijhof]

Hehe I was going to apologise for high jacking the thread.

[Ron Jeffries]

Hello, Bobby. On Monday, January 11, 2010, at 12:39:42 AM, you
wrote:

> I assume you find ruby developer incompetent for using boxcar casing
> as well? Seriously, judging a developer on the use of a well known
> idiom in a given language calls your credibility into question.

I don't see any judging going on, and certainly not anything about
boxcar casing.

I see Curtis saying that

public class Foo implements Anything

tells us Anything is an interface, and that the IAnything convention
is not necessary there. He goes on to say that when we see

public class Bar {
...
Anything thing;
...
}

he doesn't see any need to know whether Anything is an interface or
not, and asks why one does need to know.

I'm not seeing any thing about judging people in that.

> And here I thought I would get some impassioned heat for my use of
> extension methods with some good comentary.

I think you're getting both passion and commentary. I wonder why you
don't think so.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
It's easier to act your way into a new way of thinking
than to think your way into a new way of acting. --Millard Fuller

[Ron Jeffries]

Hello, James. On Monday, January 11, 2010, at 5:06:51 AM, you
wrote:

> I am quite shocked that this is being debated by people who wish to
> become craftspeople in software. It really doesn't seem important to
> me.

One possibility is that some things that don't seem important to you
actually are important.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Think! -- Aretha Franklin

[James E Taylor]

I don't deny that is possible.

I don't have the book to hand but I believe the zeroth coding standard in the great book C++ Coding Standards is something akin to "don't sweat the small stuff".

Let's just -- for a moment -- consider that I might be wrong and this falls into the "not seemingly not important" bucket.  It must fall into the small stuff sub bucket, no?  And if so, we've probably sweated enough.

[Ilja Preuß]

I'd humbly suggest that if it's not that important to you, you simply
stop sweating, and at the same time kindly accept that those of us who
feel that it's important - or perhaps even just interesting - enough,
would like to sweat some more.

Cheers, Ilja

2010/1/11 James E Taylor <james.e...@gmail.com>:

[Ron Jeffries]

Hello, Ilja. On Monday, January 11, 2010, at 7:38:03 AM, you
wrote:

> I'd humbly suggest that if it's not that important to you, you simply
> stop sweating, and at the same time kindly accept that those of us who
> feel that it's important - or perhaps even just interesting - enough,
> would like to sweat some more.

Thank you for putting that so much more nicely than I would have!

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
I must create a system, or be enslaved by another man's;
I will not reason and compare; my business is to create. --William Blake

[Bobby Johnson]

OK, I may have gotten a bit perturbed last night by this statement:

"To be completely honest, and I hope I don't offend, but when I see interfaces beginning with I, the first one I think of is  IDontKnowOO."

No point to me raging on the internet especially at a group of developers whose opinion I respect and asked for for something that was most likely said as a joke anyway. So, I offer my humblest apologies.

Maybe the reason this idiom stays alive in the .NET community is due to the lack of multiple inheritance? So I can have a class that inherits from a base ala:

public class Car : Vehicle {}

but I can't have multiple bases ala:

public class Car : Vehicle, SafetyDevice {}

but I can implement as many interfaces as I like:

public class Car : Vehicle, IIndicateTurns, IIndicateReducedSpeed, IHonk {}

From the developers perspective it is nice to be able to look at Car and see it has a base class and has implemented these added behaviors. Looking at the line above I an tell pretty quickly if I am able to inherit from the class ManualTransmission or need to come up with a different design.

But in the grand scheme of things, I have an "I" in my interfaces because the framework uses "I"s for interfaces and the discussion with my about why I randomly decided to drop the "I" seems like a pointless waste of time in that context. Having said that, I do see the point all the anti-"I" guys are trying to make and think it's a valid comment.

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To post to this group, send email to software_cr...@googlegroups.com.
To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.

--

[Bobby Johnson]

So I have had some time to digest this the code that I wrote and I think I have discovered what is making me feel uneasy about it. For reference the code can be found here: http://gist.github.com/271356

On the surface, the use of extension methods seems to make the code more expressive at the point the extensions are used. But under the surface, extension methods are simply compiler tricks to hide static methods. I have inherited enough code that was a nasty tangle of dependent static methods to know that this is an anti-pattern. And you can even see the anti-pattern starting to emerge in this code sample. MapToUser() depends on Get<T>(), IsActiveAccount() and GetRoles(). Over time these things tend to grow and become more tangled. I think this is what is giving me heartburn.

Now, having said that a huge portion of the Linq code base is implemented with extension methods. I use Linq a lot to make my code more expressive and feel it was a great addition to the tool set. It seems that linqs methods all revolve around collection manipulation.

I wonder if there are some rules of thumb for extension methods. Does anyone else have insight into what I am saying?