Author Topic: Extension Methods  (Read 2439 times)

0 Members and 1 Guest are viewing this topic.

sinc

  • Guest
Extension Methods
« on: July 13, 2009, 09:53:43 AM »
I finally discovered extension methods, and started converting some existing code to use them instead.

I seem to notice that my code now runs slower in debug mode.  Other than that, it seems the same as always.  I can even run the debug build and it runs normally, as long as I'm not running it from the debugger.  As far as I know, I changed nothing, except for moving some existing code from a utility class to extension methods.

Is this expected?  Has anyone else noticed this?  It doesn't really matter a whole lot, since it only seems to affect debug mode, but it seemed odd.

jmaeding

  • Bull Frog
  • Posts: 304
  • I'm just here for the Shelties.
Re: Extension Methods
« Reply #1 on: October 12, 2009, 03:47:47 PM »
Ha, you wrote this back in June, and I just stumbled onto them now.
I saw that Tony T did some for resultbuffer things, but now I have a much bigger need for them.

I know people say to inherit instead of extend, and in my situation, I do have the code so could inherit.
What I have is a set of objects not relient on AutoCad.
I created an "alignment" (just a polyline really) object, and its properties are all non-acad derived.
However, I want to add methods like "Draw" which would involve acad of course, or bricscad someday too.
I will have two or more sets of draw function definitions eventually.
I had thought about using partial classes, but my alignment class is in a different project than my Acad based functions.
I want that core class to be completely standalone from the cad specific parts, hence the separation.
So it seems like the answer is extension methods.
For the acad project, I have an AcadExtension project.  For Bricscad, an BCadExtension project, all with same extension methods and signatures.
The extension projects become like plug-ins specific to some circumstances.  If you keep namespaces the same, the rest of the projects do not notice (code-wise), except for the reference path that must change for the right plug-ins.  Any comments on this approach?
James Maeding

jmaeding

  • Bull Frog
  • Posts: 304
  • I'm just here for the Shelties.
Re: Extension Methods
« Reply #2 on: October 12, 2009, 03:58:44 PM »
I forgot to mention, I don't really like my extension method approach here.
The reason is that I cannot use the extension methods in the base class code for debugging.
Sometimes I want to draw a point on screen, but cannot do so if in a calc routine of the base class.
I like the idea of partial classes better, and creating separate projects for each cad platform, where the core class files are shared.
I get mutiple assemblies then though, one for each platform.
James Maeding

sinc

  • Guest
Re: Extension Methods
« Reply #3 on: October 12, 2009, 04:54:05 PM »
That's not really what Extension Methods were designed for.

Extension Methods enable you to add methods to a class that you don't have the source code for.  But that's not what you're doing.

It sounds like what you want is an abstract Draw() interface in your Alignment class, which then calls a concrete implementation, which varies depending on the platform.  It's been too long since I studied Design Patterns, and I forget their names, but I think this is the one that is often called a "Bridge" pattern.

jmaeding

  • Bull Frog
  • Posts: 304
  • I'm just here for the Shelties.
Re: Extension Methods
« Reply #4 on: October 12, 2009, 05:32:25 PM »
That's what I thought, so there must be a better way.
It seems like this might be common, to have a base set of objects that must have methods defined differently for each system they might run on.
You would want the ability to have one dll for the core, then add-on dll's for the system specific stuff.
I have a feeling the common solution is to "mix" the right recipie of common and specific source codes files in projects made for each system.
So I would end up with CivilEngineAcad2009.dll, CivilEngineBcad2009.dll and so on.
That goes against my idea of a common library or objects, and separate adapters for each system.  I might just have to choose a compromise.
James Maeding

It's Alive!

  • Retired
  • Needs a day job
  • Posts: 8718
  • AKA Daniel
Re: Extension Methods
« Reply #5 on: October 12, 2009, 09:17:20 PM »
Just make wrapper classes....
How are you interfacing with Bricscad?

jmaeding

  • Bull Frog
  • Posts: 304
  • I'm just here for the Shelties.
Re: Extension Methods
« Reply #6 on: October 13, 2009, 12:33:09 PM »
so create "parallel" objects for each platform that inherit from the common library?
That still does not solve the issue where I cannot use cad platform dependent methods when troubleshooting the inner workings of the base library.
I think I am setting up my own walls - I want a cad platform independent set of code, yet want to test it on a specific platform.
Maybe I have to choose my poison - keep separation via inheritance or extenders, or combine core and extensions in one project per platform with partial classes.
Are you picturing another option?  I definately am looking for more.
Thx
James Maeding

jmaeding

  • Bull Frog
  • Posts: 304
  • I'm just here for the Shelties.
Re: Extension Methods
« Reply #7 on: October 13, 2009, 12:34:52 PM »
forgot to mention, no bricscad interaction yet.  I will look into it more soon.
James Maeding