In my last post, we looked at using interfaces to support the multiple versions of the OptionObject without writing duplicated code. Interfaces are great for creating methods that can consume or return multiple concrete classes such as our OptionObjects. However, in C# at least, you can’t implement any common functionality through interfaces. They are simply contracts that define what the concrete classes are to implement. What if there was a common method that we wanted to extend our OptionObjects with? Welcome abstract classes.
Tag: AvatarScriptLink.NET
I first started working with myAvatar ScriptLink during the days of the OptionObject (v1). Shortly after, an updated version, OptionObject2, was released with some additional valuable properties. I completely missed the announcement of this version and didn’t stumble on it until well after the OptionObject2015 version was released. So I was using OptionObject in production, but I wanted to upgrade to a newer release without writing duplicate code. Inheritance became my solution and a foundation of the design of the AvatarScriptLink.NET library.
It can be overwhelming for behavioral health organizations running the Netsmart myAvatar to consider leveraging ScriptLink to extend its capabilities. Perhaps even more so for those who are utilizing it when it is suggested, as I did a month ago, that there are opportunities to improve. Experience, time, and cost can be significant barriers regardless of desire. These are the barriers that I hope we as a community can help each other overcome.
Rarely Simple 