3

In my current system I decided to build some generic Extension methods to be reusable later inside the whole current system.

As I'm using Microsoft Code Contracts I decided firstly to include them to validate the source and the range.

1)

public static class MyExtensions {
    public static void RemoveRange<T>(this ObservableCollection<T> source, IEnumerable<T> range) where T : class {
        Contract.Requires(source != null);
        Contract.Requires(range != null);

        foreach (var element in range) {
            source.Remove(element);
        }
    }       
}

Another implementation manner is a classic way:

2)

public static class MyExtensions {
    public static void RemoveRange<T>(this ObservableCollection<T> source, IEnumerable<T> range) where T : class {
        if (source == null) {
            throw new ArgumentNullException("source");
        }

        foreach (var element in range) {
            source.Remove(element);
        }
    }   
}

Until this moment I didn't had such requirements to design generic classes in a manner that can be reusable in another systems

EDIT (start) (by another systems i mean concretly distinct systems, with different architecture. Example: the current systems if for financial sector, and it uses Code Contracts. But other system can be for military sector, which will not use Code Contracts for validation.) EDIT (end)

I discussed with my coleagues how about reusability of that Generic class with Extension methods in another systems ?

I) An opinios is to keep Code Contracts because is is a rule of validation in whole current system. (as in first example).

The advantage of this way is that I keep one way of validation in whole system (only via Code Contracts). The disadvantage is that this Tested Generic Class with Extension methods will not be reusable in another systems (which possibly will not use Code Contracts for validation) without replacing Contracts with classic If/Throw Exception.

II) Another opinion is to design Generic classes with Extension methods to be Reusable in another systems, even we didn't have until now such requirements. This opinion requires a classic implementation of validation, via IF and throw exception (as in second example).

The advantage of this way is that Tested Generic Classes with Extension Methods will be reusable without changes. But the disadvange is that another type of validation is approached.

Any suggestion/advice, concerning which approach to use, will be welcome.

Thank you for atention!

mihai
  • 2,746
  • 3
  • 35
  • 56

1 Answers1

1

You can add Code Contracts to a class library without introducing a dependency on Code Contracts for any other assembly that uses that class library.

The Code Contracts are implemented by a re-writer that changes the code that specifies the code contracts. The rest of the Code Contracts support is already baked in to .Net 4 or later, so other code can happily reference the library that uses Code Contracts without having to take any special steps.

Therefore you can use Code Contracts in some assemblies without worrying about anything else that references those assemblies.

Specifically, this statement is not true:

The disadvantage is that this Tested Generic Class with Extension methods will not be reusable in another systems (which possibly will not use Code Contracts for validation) without replacing Contracts with classic If/Throw Exception.

because you can reuse it in "other systems" (if by "other systems" you mean "assemblies that do not use Code Contracts").

Matthew Watson
  • 104,400
  • 10
  • 158
  • 276
  • Thanks. by "other systems" i mean concretly distinct systems, with different architecture. Example: the current systems if for financial sector, and it uses Code Contracts. But other system can be for military sector, which will not use Code Contracts for validation. – mihai Jun 26 '13 at 08:27
  • @meorfi Well that doesn't mean you can't use Code Contracts - since that is just used to validate things like program arguments, and since both approaches just throw exceptions, you should be able to use them interchangeably, at least for validating method arguments. – Matthew Watson Jun 26 '13 at 08:31
  • Do you mean that Code Contracts are a best practice which should be used in any kind of system? – mihai Jun 26 '13 at 08:39
  • @meorfi Not necessarily, but what I mean is that using them in one system won't adversely affect systems that don't use them. – Matthew Watson Jun 26 '13 at 08:43
  • What will happen if someone decides to not use Code Contracts because of the fact that it requires long time at each Rebuild (or other motivation) ... – mihai Jun 26 '13 at 08:43
  • @meorfi You won't be able to turn off Code Contracts in the assembly that uses them directly without replacing them with the old way of doing things. But what I'm talking about is the assemblies that *aren't* using Code Contracts don't need to care if they reference any assemblies that *do* use Code Contracts. (Unless they are worried about the extra 5 seconds of compile time if they rebuild the assemblies that use Code Contracts directly... which would be pretty weird.) – Matthew Watson Jun 26 '13 at 08:51
  • This way, I will not be able to reuse That class with Extension Methods (which validates with `Contract.Requires()` ) in any system which doesn't use Code Contracts. But a classic design (via `If/Throw Exception` ) will be reusable in both kind of systems, with Code Contracts, and without. – mihai Jun 26 '13 at 08:56
  • @meorfi That's silly. It's like saying you can't use Code Analysis in case someone complains that it takes a few seconds longer to compile if Code Analysis is turned on, or saying "That library takes longer to compile because you added more code to it - please remove that code". There will be NO compile or runtime problems for a system that doesn't use Code Contracts. Worrying about a few seconds of compile time for a system that is only infrequently rebuilt is not a good reason to avoid using it. – Matthew Watson Jun 26 '13 at 09:00
  • It's silly if we're discussing aroud "will compile long time than without" motivation. But there can be a lot of motivations. IMHO – mihai Jun 26 '13 at 09:04
  • @meorfi Ok, so can you list some of the other motivations? Let's assume that Code Contracts are going to continue to be supported, of course. – Matthew Watson Jun 26 '13 at 09:08
  • Thanks Matthew. That was simply my opinion, but some disadvantages of Code Contracts I see here http://stackoverflow.com/questions/4930496/code-contracts-nice-on-the-edge-but-not-ready-for-prime-time – mihai Jun 26 '13 at 09:13
  • @meorfi Firstly, you are talking about preconditions so any problems with postconditions do not apply. Secondly, the other issues mentioned there aren't issues at all. Code contracts don't slow the runtime code any more than the old way of doing the checks. As you can see in the question you linked, the accepted answer dismisses the concerns. – Matthew Watson Jun 26 '13 at 09:23
  • Yes, really. We've turned the question to the Pro / Contra for CodeContracts. Thanks for your opinion! – mihai Jun 26 '13 at 09:30