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.
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.
> 
> 
>