Ayende @ Rahien

Hi!
My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:

ayende@ayende.com

+972 52-548-6969

, @ Q c

Posts: 6,124 | Comments: 45,481

filter by tags archive

Code Generation and the Open Close Principal

time to read 1 min | 83 words

Vladan Strigo made a really inspiring comment about code generation in the NH Users list.

I didn't want to use codesmith for that because it would de-OCP-fy me in my future efforts :)

That makes a lot of sense, and manages to touch on what bothers me the most with code gen as an architectural approach. It gives up a very important concept, and that affect a lot of the stuff that is dependant on that.


Comments

Mark Lindell

I agree that Passive code gen can be abused.

I particularly don't like passive code gen other than a template starting point to save you some typing. Come on, snippets are passive code gen and no one would deny the benefit of those, right?

On the other hand, I do believe that active codegen can be used appropriately to solve the right problems. Infrastructure that are driven by metadata can benefit from active code generation. (Proxy generation?)

After all, isn't Reflection.Emit a form of active codegen?

I understand your dislike of code gen as an architectural solution when good design would solve the same problem without violating OCP. (yeah you know me -- sorry music joke)

Alon Fliess

So JIT is a violation of OCP, it does code generation from IL to assembler. Also any runtime implementation of proxy, interception layer, data accessors, etc. are bad.

I don't think that code generation has anything to do with OCP, its the design of your system that has. Code Generation may be based on the same good OO patterns. I have implemented a system were all my code generators are discovered in runtime. They registered themselves to a pub/sub mechanisms that calls them whenever they need to emit their code. I can remove or add a generator without touching any other generator...

Any generator can derived from existing one and change the code it emits.

This is an OO & OCP based design...

Alon.

Ayende Rahien

You missed this part: "code gen as an architectural approach"

I wasn't talking about emitting IL to do something at runtime. I was talking about code gen as an architectural approach, that is, we will define the application using (DB, XML, pretty pictures) and generate the code from there

Lars Wilhelmsen

Not to be annoying or anything - but isn't there a slight difference between "Principal" & "Principle"?

--larsw

Comment preview

Comments have been closed on this topic.

FUTURE POSTS

  1. RavenDB 3.5 whirl wind tour: I’ll find who is taking my I/O bandwidth and they SHALL pay - 15 hours from now
  2. The design of RavenDB 4.0: Physically segregating collections - about one day from now
  3. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - 3 days from now
  4. RavenDB 3.5 whirl wind tour: I'll have the 3+1 goodies to go, please - 6 days from now
  5. The design of RavenDB 4.0: Voron has a one track mind - 7 days from now

And 12 more posts are pending...

There are posts all the way to May 30, 2016

RECENT SERIES

  1. RavenDB 3.5 whirl wind tour (14):
    02 May 2016 - You want all the data, you can’t handle all the data
  2. The design of RavenDB 4.0 (13):
    03 May 2016 - Making Lucene reliable
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats