C＃-实例-抽象类的刚性

Question

I understand that

"Abstract classes can be modified without breaking the API ".

once a version (say 1.0.0.0) of class library is supplied to the party,when i design the another version (say 1.1.0.0) with modification,won't it break the code ?

can you give very simple example ,how is it possible ?

Answer 1

Abstract classes, and interfaces (to a lesser degree), are both what we consider a contract. Abstract classes can be more complex than interfaces in that they can have implementation as well as a contract definition. Both types can be modified without breaking a contract (API) in a couple ways. There are three basic kinds of contract changes:

1. Add a member
2. Remove a member
3. Modify a member

In C#, members can be methods, properties, indexers, and fields. The simplest, and first non-breaking change, is additions of members. Adding a member augments the API, but in no way changes the API that existed previously. Removal of a member is a breaking change, as the previous API does change when a member is removed.

The final option, modification of members, may or may not necessarily be breaking in C#. In the case of fields, the only modification is a rename. Renaming a public field is always a breaking change. Properties could be renamed, or they could have a setter/getter added or removed. Adding a setter/getter is not breaking, but all other property changes are breaking. Indexers and methods may be changed without breaking contract by the addition of a params parameter at the end of an existing parameter list. Any other changes to indexers and methods would also be breaking changes.

Beyond the API level, behavioral changes should also be taken into account. While we should always strive to keep the API and behavior as decoupled as possible, it is not always as cut and dry as that. Take important behavioral nuances and their effect on the use of an API into account when creating a new version. Such nuances might be exceptions thrown by a method, usage of other API members by an API member, etc.

Once you understand the three kinds of changes and how they affect a contract, you should be able to better control how you version your abstract classes and interfaces. Non-breaking changes are often labeled with a minor version change, or perhaps only a revision change. Breaking changes are often labeled with a major version change. If you take a careful approach to versioning, it should be a very manageable problem...just make sure you fully understand the impact before making breaking changes.

Answer 2

In these terms, I understand the API as the contract (set of public method definitions) that client code is able to utilize to when using version (1.0.0.0) of the class. Not "breaking the API", is possible only if, in the new version of the abstract class (1.1.0.0), the new methods you are defining are non-abstract. Any new methods that are abstract in version 1.1.0.0 implements will "break the API". (Also, altering method definitions that are non-abstract will "break the API".).

Answer 3

I think that statement means that the method body in abstract class can be changed-- without changing the interface.

Considering this:

public abstract class Animal
{
   public virtual string Speak()
   {
      return "erm";
   }
}

Later if you find out that the Animal is not speaking erm , but speaking ya , so in your version 1.1.0.0, you can just change the code to:

public abstract class Animal
{
   public virtual string Speak()
   {
      return "ya";
   }
}

In this case, if your client inherit Animal in other classes using your assembly version 1.0.0.0, then he doesn't have to change his code in order to compile with your 1.1.0.0.

Answer 4

First, i would say that this is not specific to abstract classes, but to classes in general.

Consider the following class:

public class SomeClass
{
    public bool IsValid(string input)
    {
        return !string.IsNullOrEmpty(input);
    }
}

It defines a method that takes a string and returns a bool . It will return false if the string is null or empty. Now, let's change it:

public class SomeClass
{
    public bool IsValid(string input)
    {
        return !string.IsNullOrEmpty(input);
    }

}

In this case we added a new method. The previus method is untouched. This change does not in any way affect code that uses the class. Next change:

public class SomeClass
{
    public bool IsValid(string input)
    {
        if (string.IsNullOrEmpty(input))
        {
            return false;
        }

        return input.Length > 5;
    }

    public void SomeNewMethod() {  }
}

Now we have altered the behaviour of IsValid . Old code will still complile without alteration, but the result for some input values have changed. This is one form of breaking change. Next change:

public class SomeClass
{
    public void IsValid(DateTime input)
    {
        // do something with the input
    }

    public void SomeNewMethod() {  }
}

Now we have altered the signature of IsValid . This will cause calling code to not compile. This is another type of breaking change.

And as you can see, these examples of breaking API has nothing to do with whether the class is abstract or not.

Answer 5

A little esoteric, but we've been hit by this - If your assembly is strong named and contains configuration data, you can break code by changing the version number. Unless you upgrade app|web.config when you upgrade assemblies, if a full binding path is used (say to reference a type), the new assembly will fail to load.

A more conventional answer could be you fixed a bug in the abstract class without needing to change any members.

A version policy is also recommeded, but it needs team-wide adoption to work.

Answer 6

Abstract classes can be modified without breaking the API.

That's just plain wrong, or totally misleading at best. An API is not only the syntactical aspect of a classes interface, but also its semantics - ie the described behaviour of a certain method.

Here's an example of what I mean:

// v1
public abstract class A
{
    void DoSomething()
    {
        ...
        if (someCondition)
        {
            throw new SomeException();
        }
    }
}

Now in the next version you might have:

// v2
public abstract class A
{
    void DoSomething()
    {
        ...
        if (someCondition)
        {
            throw new DifferentException();
        }
    }
}

And your 'API' - seemingly remaining unchanged - might look like this:

public class B: A
{
    ...
    void DoSomething(); // inherited from base
}

But actually, when replacing the base class v1 with v2, you didn't keep the API constant, because there might be some calling code that relies on SomeException to be thrown, not DifferentException . Sure, you can make modifications that leave both syntax and semantics unchanged, but that's what you always do when making a new version, and there's a lot of different techniques for that. It's not specific to base classes, be they abstract or not.