Question: [Note: it's generally bad practice to include code in your cfcs, (see answers below), so consider this just research]

To summarize, I have a class and a subclass and one method that is overridden by the subclass. When I hard-code the method in the child class, everything works fine, when I use cfinclude to include it in the pseudo constructor, mixin style, I get a "Routines cannot be declared more than once." error. 

This seems pretty straightforward. What am I missin' re: this mixin?

parent class:

```
<cfcomponent >
    <cffunction name="hola" hint="i am the parent method">
        <cfreturn "hola - parent">
    </cffunction>
</cfcomponent>

```

child class:

```
<cfcomponent extends="mixinTestParent">
    <!---   this would work, successfully overridding parent method
    <cffunction name="hola" hint="i am the child method">
        <cfreturn "hola - child">
    </cffunction>--->

    <cfinclude template="mixinTestInc.cfm">

    <cffunction name="init" access="public" returntype="any" output="false">
        <cfreturn this>
    </cffunction>
</cfcomponent>

```

include: 

```
<cffunction name="hola" hint="i am the child method" access="public">
        <cfreturn "hola - child">
    </cffunction> 

```

runner:

```
<cfset test = new mixinTestChild().init()>
<cfdump var="#test.hola()#">

```

thanks in advance!!

Answer: 
I think you could get your stuff to work, but it not a good idea at all to do what you are doing. Includes work really well for managing text and HTML and outputting information to the screen. It's not used to for including functions. 

I found this for you: <http://www.justskins.com/forums/is-cfincludeing-from-cfcs-81144.html>

> 
> Just a follow-up after exchanging emails with Sean Corfield, Director of
>  Architecture at Macromedia.
> 
> 
> He said that cfinclude'ing files from CFC functions "is bad practice". I
>  personally thought it was good practice to simplify the CFCs, but he said that
>  not using cfinclude's encourages people "to refactor their CFCs into smaller,
>  more cohesive CFCs."
> 
> 
> As for copying "var" variables into the Variables scope in included files,
>  this is a CFMX 6.1 bug that, according to Sean, is fixed in CF7.
> 
> 
> Sean did not specifically say that using cfinclude's will cause errors, but I
>  am inclined to believe this practice did contribute to our weird errors. Our
>  errors were unrelated to the Variables scope and I am confident they will be
>  solved now that we added RAM to our server, but that is not to say the
>  cfinclude's did not contribute.
> 
> 
> CF's documentation does say it is ok to use cfinclude's so we are probably
>  going to run some tests before moving all of our code into the CFC itself.
> 
> 
>
Just to add to the answer from @iKnowKungFoo, the issue is that `<cfinclude>` is not shorthand for "stick the code in here, as if it was actually part of the file" like a `#include` would work in C. I say this because this is how most people see it as working.

In C, a `#include` is a compiler instruction (not C code, per-se), and indeed the code from the included file is actually included into the file before it's compiled.

In CF, that's not what happens. The included file is compiled separately, and then some Java jiggery-pokery (sorry for the technical term ;-) takes place to make it seem like the included code is inline with the code that includes it (if that makes sense).

Now... what's the ramification of this? When a CFM file compiled, functions within it a compiled as UDFs, which don't have any concept of inheritance or overriding or anything like that, because they're not that sort of context. It's only when a *CFC* is compiled that all that stuff is implemented. Basically CFMs are not compiled with any considerations of OO, whereas CFCs specifically are.

So one of the rules of UDFs is that there can only be one function of a given name per request... this can be demonstrated by creating a CFM which includes your file (the one with `hola()` in it) twice in a row: you'll get an error. Now why this rule is in place I have no idea. To me a function is just a variable, so a second function declaration of the same name should just overwrite the previous one. However CF has always been like this, so we should be used to it by now. And in the case of your code, your UDF (in the include) has the same name as the method in your CFC, which is enough for the error condition to occur. This kinda makes sense.

Does that help clarify what's going on, and why you're seeing what you're seeing?