DISQUS

DISQUS Hello! Andrey Shchekin's Blog is using DISQUS, a powerful comment system, to manage its comments. Learn more.

Community Page

Andrey Shchekin's Blog

Jump to original thread »
Author

Sins of .NET API Developers

Started by Andrey Shchekin · 10 months ago

There are several annoying design flaws I often stumble into in .NET APIs. I haven’t seen Design Guidelines on this matter, so I think I’ll point to 3 of these myself.


The Generic Sin
Do provide a non-generic overloads to generic utility methods. Ayende ... Continue reading »

7 comments

  • Ayende Rahien

    1 year ago

    Try IKernel.ResolveAll(), it has non generic version
    reply
  • Andrey Shchekin

    1 year ago

    Thanks, it solves the problem at hand.
    reply
  • Jeff Brown

    1 year ago

    Gallio and MbUnit v3 have already handily resolved the IFixtureFactory issue you mentioned. The system is much more open to extension now. Components can even be replaced via the IoC if you like.

    This is something I have *thought* very carefully about. Trust me. I don't doubt we could do even better. Let me know if you have any ideas. (MbUnit v2 is a different story.)

    As for internal test fixtures, this is something we have considered and can very easily change. It's not entirely clear its a good idea. For example, we might encounter problems in partial trust execution environments.

    However, you do make a good case regarding the interaction with [InternalsVisibleTo] and the implied constraints on the visibility of any derived types. Previous requests for this feature have largely been from people wanting to mix test fixtures with production code.

    In any case I'll go ahead and enable internal fixtures in the next update. Not really worth fussing over.

    In the future, if there's anything else you want a tool to do, please just ask for it. It might already be there or it might be something that has just yet to be done pending sufficient demand.
    reply
  • Andrey Shchekin

    1 year ago

    Thank you, Jeff. I know that I could have asked you directly instead of blogging it, but I wanted to stress the importance of solving these things by default.

    As for Gallio, I'll enjoy working with it when it's out, but it is not here yet. So, since I wanted to extend a stable version, I haven't looked deep into Gallio.
    reply
  • Jeff Brown

    1 year ago

    The best way to ensure that problems are solved is to get involved.

    I'm pretty smart and I spend a fair amount of time thinking about these issues upfront so that they are "solved by default." But I will miss stuff or I will postpone it due to conflicting priorities.

    So I count on the community of other smart people like yourself to point out deficiencies that affect them so that they can be directly addressed.

    Also keep in mind that I only found this post accidentally. So you're lucky I even noticed it at all. The issue tracker and mailing lists are much better ways to ensure that your feedback gets noticed and taken into consideration.
    reply
  • Andrey Titov

    1 year ago

    I've found another example similar to your #2.
    Rhino mock can't create partial mock on non pulic types. So I can't test my BC classes using partial mocking because they are all internal for BL and are accessible outside only with public facade.
    reply
  • Andrey Shchekin

    1 year ago

    Jeff, I am sorry for having bashed MbUnit, but for me this post was about common deficiencies, and MbUnit was only an example, since I use it every day.

    Andrey, have you tried [assembly: InternalsVisibleTo(RhinoMocks.StrongName)]?
    reply

Add New Comment

Returning? Login