G'day exilepanda,

Firstly, I concur with ++Fletch's response. What follows is additional information.

"... I have Robo class, which subclass from Robo::Arm Robo::Head Robo::Feet ..."

I may be misinterpreting your intent; however, I think you may want an OO structure something like this.

• Robo - a top-level class implementing generic functionality.
  • Robo::Arm - a subclass of Robo which inherits generic functionality from Robo and implements specific functionality required by Robo::Arm objects.
  • Robo::Head - a subclass of Robo which inherits generic functionality from Robo and implements specific functionality required by Robo::Head objects.
  • Robo::Feet - a subclass of Robo which inherits generic functionality from Robo and implements specific functionality required by Robo::Feet objects.
  • Other subclasses of Robo which may become apparent as development progresses or for subsequent extension, e.g. Robo::Body. These would fit into the OO structure in the same way as the three subclasses already mentioned.
• Robot - a separate top-level class which composes or aggregates (has-a relationships) Robo::* subclasses. This may be more involved than that; however, your OP description doesn't provide sufficient information to speculate further.

I recommend you read "perlintro: OO Perl" and follow the links therein. In particular, perlootut provides, amongst other things, definitions of inheritance and composition.

"... I learned I can use Exporter ... to obtain methods from other class(modules)."

You don't say where you learned that: it's poor advice. If you look in the "What Not to Export" section of Exporter, you'll see the very first item in the list reads:

"method names (because you don't need to and that's likely to not do what you want),"

If you are hand-crafting all of your classes — which, unless it's for a learning exercise, I don't recommend — the parent pragma would probably be the way to go (note that the base pragma is generally discouraged).

Take a look at "perlootut: PERL OO SYSTEMS". You haven't supplied enough information for a recommendation; perhaps try Moose and Moo first.

"However, if a method is not solely depends on themselves, I mean, the being called method require attributes defined in the class's own constructor to work properly, the tricks of above will not work. The result is that I can access the method, but the method won't work properly."

I don't understand what you're trying to describe in that paragraph. Showing some code pointing out what you want versus what you're getting would help greatly. Take a look at SSCCE.

"Is that any trick that you can kick on the constructor ..."

After following the advice above, you may find this is unnecessary. If you still need it, how it is achieved will depend on the code you use. I'm very much guessing here but, if you chose Moose, then something documented in "Moose::Manual::Construction: OBJECT CONSTRUCTION HOOKS" would likely be what you're after.