Why are all of the Layer classes sealed as of the 10.2.4 release?

[LukePatterson]

I have my own derived classes for ArcGISDynamicMapServiceLayer, ArcGISLocalTiledLayer, WmsLayer, and  ArcGISTiledMapServiceLayer that I used with the WPF SDK and through the beta for .NET. Yes, I can work around this but I feel as if I am being forced out of an object oriented design pattern.

Luke

[dotMorten_esri]

This is by design. Please share your scenarios that requires this

[LukePatterson]

I have additional data and fields that go along with my layers that do not come from a gis data source. I just find it useful to be able to derive from the class directly so that I can make use of this information easily on my end. As Anargyros pointed out, I can work around this. It's more of a complaint than anything. If I encounter my layer through some event coming from the map control, I would rather cast it to my derived type and have access to my data readily available than have to keep my data separate and look it up based on an identifier for the layer. The only purpose that I see for having a sealed class is to attempt to restrict what a developer that is using your library can do. Therefore I don't see the benefit in making this change for the release. Just an opinion/rant though

[dotMorten_esri · Accepted solution]

@Mike: Since layers inherit from DependencyObject, I would suggest you use AttachedProperties for this. It saves you a lot of subclassing and allows you to easily attach your own objects to all the layers, without having to subclass all of them. It will also simplify your workflow down the line when we start supporting saving/restoring the map to disk and portal (where we wouldn't be able to support subclasses like this).

Attached Properties Overview

[LukePatterson]

@Morten: Thanks for the advice. I'm in the process of working around this one right now. Glad to hear that saving and restoring  is coming in the future! How about next release ?

[JonDicken]

Hi,

This is also something that is causing us some pain transitioning our solution from 10.2.3 to 10.2.4. We had also derived our own layers to handle not only additional properties, but also additional methods providing particular functionality we wanted.

Attached Properties like you say would be another way of handling this, but not so great for the methods we want to expose.

Again, composition over inheritance is valid a great deal of the time, but there are also scenarios were I would argue inheritance is actually more logical and practical.

We are working around this, but I do consider it poor form to have left these classes unsealed for the entire beta run and then to seal them on release.

Regards,

Jon

[AnargyrosTomaras]

Composition over Inheritance http://en.wikipedia.org/wiki/Composition_over_inheritance would be a valid OOP solution to your issue.

[LukePatterson]

Agreed. This is the solution/workaround to my problem. Just seems like pointless work and results in less appealing code in my opinion. While on the other hand adding sealed to the layer classes has no real benefit, it's just an annoyance to developers using the SDK that would like to derive from these classes.

Luke

[dotMorten_esri]

I'm sorry for the change. Some layers were sealed in the beta, but it was a mistake others weren't. Methods weren't overrideable, so the subclassibility only really served a purpose with respect to "attaching stuff" to the layers. Something that as mentioned can be handled through attached properties, or wrt to methods, using extension methods.

Unfortunately we're not able to change this due to some infrastructure changes, as well as some upcoming features in 10.3 (that I'm sure you would want to use) would make the inheritance approach a lot worse for you than using attached properties now.