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: 
You're getting the error because of the way the the CFC is instantiated.

When you have `hola()` in the parent & `hola()` in the child, where the child extends the parent, when the child CFC is created, it sees `hola()` in the parent and overrides it. However, that function still exists in the CFC. 

From the child CFC, you can reference both `hola()` (defined in the child CFC) and `super.hola()` (defined in the parent).

When you use `<cfinclude/>`, the CFC is instantiated and the contents of the included file are added to the mix. However, they aren't seen as part of the inheritance model, just as "other functions in this CFC", so you get the error.

I agree this is a bad practice when done instead of refactoring, but it is a good way to allow utility UDFs into the mix without making them part of your model.
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?