Inheritance or Not

I have a web service that I call that returns an object of type A. I call this web service from a business layer. The business layer needs a few more properties on the object before it can be used by the GUI layer. I was thinking of using inheritance, however, the calls to the web service return an object of A, and there is no clean way (that I know of) to convert a base type to a derived type. So another option I was thinking of was using a class that has an object of type A and then the rest of my properties that I need.

Code:

---

Public Class B
    Private _A As A
    Public Property ObjectA() As A
        Get
            Return _A
        End Get
        Set(ByVal value As A)
            _A = value
        End Set
    End Property
    Private myNewProperty As String
    Public Property NewProperty() As String
        Get
            Return myNewProperty
        End Get
        Set(ByVal value As String)
            myNewProperty = value
        End Set
    End Property
End Class

---

Is there anything wrong with this approach? Is there a way I could use inheritance to get this done?

Is the web service immutable? I would guess that it is, or else you could just have it create a B that inherits from A, cast it to type A, and return it. It would still be a B, so you would have no issue with casting it back to a B. Of course, that would mean that the service itself would change somewhat, which is probably not that good an idea. The service is exposing an A, and every consumer should take that A and do with it as they please. Having it secretly expose a B that has been cast to an A, and only having certain people know that it is actually a B and can be cast back to a B, would be kind of cheesy, though possible.

I think the way you have it is the way that I would do it. One strange alternative would be to define a B that inherits from A, and which has a constructor that takes an A as an argument, then sets up its base from the argument. That would only be possible if A was designed in such a fashion that it would work, because the new B that took the return from the service would have to be able to constuct its base based on the return from the service, which is not always an option.

Quote:

---

Originally Posted by Shaggy Hiker

Is the web service immutable? I would guess that it is, or else you could just have it create a B that inherits from A, cast it to type A, and return it. It would still be a B, so you would have no issue with casting it back to a B. Of course, that would mean that the service itself would change somewhat, which is probably not that good an idea. The service is exposing an A, and every consumer should take that A and do with it as they please. Having it secretly expose a B that has been cast to an A, and only having certain people know that it is actually a B and can be cast back to a B, would be kind of cheesy, though possible.

---

You are correct, I cannot change it. Your idea of returning a B and then casting it to A is creative, but I agree that it is cheesy and wouldn't work if another consumer of the web service wanted it's own derived class returned.

Quote:

---

Originally Posted by Shaggy Hiker

I think the way you have it is the way that I would do it. One strange alternative would be to define a B that inherits from A, and which has a constructor that takes an A as an argument, then sets up its base from the argument. That would only be possible if A was designed in such a fashion that it would work, because the new B that took the return from the service would have to be able to constuct its base based on the return from the service, which is not always an option.

---

I was thinking of that as well, but as A grows in functionality, I don't want to have to remember to update a copy method in B. I have seen some implementations that use reflection to loop through the properties and copy them, but I would need a pretty recursive copy, as there are multiple reference type objects in A.

Thanks for the reply though.

P.S. I'd give you some rep, but apparently I have to spread it around first.

Can't you simply extend the class by creating a new Partial Class A, or perhaps use extension methods?

Quote:

---

Originally Posted by Joacim Andersson

Can't you simply extend the class by creating a new Partial Class A, or perhaps use extension methods?

---

Partial classes are not extensions; they are changes to the class itself. Partial classes are simply multiple parts of the same class in different code files. All parts are combined into a single class when compiled.

Extension methods are a possibility but not likely because if the original idea was to add extra properties then that would mean adding extra data. Where would that data be stored if you were to expose it via extension methods? Methods also don't support data-binding, which might be an issue.

Composition and inheritance, as already suggested, are really the only two viable alternatives here I think.

Yes, I know what a partial class is and how it works. But the fact is that you can extend a class using a partial class, the senario Negative0 has here is a perfect example since the partial class will exist in a different assembly than the original class, which belongs (as I've understood it) to the web service. That way it actually acts as an extension.

I'm also fully aware of the limitations of extension methods, but since I don't know how the class should be extended I throw that in as a suggestion.

Quote:

---

Originally Posted by Joacim Andersson

Yes, I know what a partial class is and how it works. But the fact is that you can extend a class using a partial class, the senario Negative0 has here is a perfect example since the partial class will exist in a different assembly than the original class, which belongs (as I've understood it) to the web service. That way it actually acts as an extension.

---

I think you'll find that you're mistaken. You cannot extend an existing class using a partial class. If you declare a single partial class in your own project then it is its own class. It will be in a different namespace to the original class so they are different classes. If you change the namespace so that they are the same then your class will actually hide the original class.

This is from the MSDN documentation for the Partial keyword:

Quote:

---

Indicates that a class or structure declaration is a partial definition of the class or structure.

You can divide the definition of a class or structure among several declarations by using the Partial keyword. You can use as many partial declarations as you want, in as many different source files as you want. However, all the declarations must be in the same assembly and the same namespace.

---

I know what MSDN says, and MSDN is wrong.

Edit: MSDN isn't really wrong but in this particular case if you have a web reference to a web service, you can actually extend the service with your own methods and properties. End Edit

I've done this, and to prove it to you I've attached a quick sample. It has a web reference to a webservice I wrote for my company, I'm not going to tell you how to use it since it requires authentication, but the code clearly shows that you can reach both the original methods in the web service + the ones I have in my partial class.

Edit 2 Since my point have come across I've removed the attachment since the web service it used is a bit sensitive.

Quote:

---

Originally Posted by Joacim Andersson

I know what MSDN says, and MSDN is wrong.

Edit: MSDN isn't really wrong but in this particular case if you have a web reference to a web service, you can actually extend the service with your own methods and properties. End Edit

I've done this, and to prove it to you I've attached a quick sample. It has a web reference to a webservice I wrote for my company, I'm not going to tell you how to use it since it requires authentication, but the code clearly shows that you can reach both the original methods in the web service + the ones I have in my partial class.

---

Ah, I see where you're coming from now. You're actually extending the proxy class, which IS defined in your own project, rather than the actual original class. Didn't consider that.

Exactly! It's an extension to the proxy class and since Negative0 wanted to extend the webservice class he can do that by extending the proxy using a partial class (to separate it from the auto genarated proxy).

Thanks guys, I'll give the proxy partial class a shot and see how it works. I'll post back later today.