Package ec

# Interface Prototype

All Superinterfaces:
  `Cloneable`, `Serializable`, `Setup`

All Known Subinterfaces:
  `GPNodeSelector`

All Known Implementing Classes:
  `ADF`, `ADFArgument`, `ADFContext`, `ADFStack`, `ADM`, `AMALGAMSpecies`, `AnnealedSelection`, `BestSelection`, `BitVectorIndividual`, `BitVectorSpecies`, `BoltzmannSelection`, `BreedingPipeline`, `BreedingSource`, `BucketTournamentSelection`, `BufferedBreedingPipeline`, `ByteVectorIndividual`, `CheckingPipeline`, `CMAESSpecies`, `CrossoverPipeline`, `DoubleTournamentSelection`, `DoubleVectorIndividual`, `DOVSFitness`, `DOVSSpecies`, `ERC`, `ESSelection`, `FirstCopyPipeline`, `FirstSelection`, `Fitness`, `FitProportionateSelection`, `FloatVectorIndividual`, `FloatVectorSpecies`, `ForceBreedingPipeline`, `FullBuilder`, `GEIndividual`, `Gene`, `GeneDuplicationPipeline`, `GenerationSwitchPipeline`, `GeneVectorIndividual`, `GeneVectorSpecies`, `GEProblem`, `GESpecies`, `GPBreedingPipeline`, `GPData`, `GPIndividual`, `GPNode`, `GPNodeBuilder`, `GPProblem`, `GPSpecies`, `GPTree`, `GrammarParser`, `GreedyOverselection`, `GrowBuilder`, `HalfBuilder`, `HyperboxSpecies`, `Individual`, `InitializationPipeline`, `IntegerVectorIndividual`, `IntegerVectorSpecies`, `InternalCrossoverPipeline`, `KozaBuilder`, `KozaFitness`, `KozaNodeSelector`, `LexicaseSelection`, `LexicographicTournamentSelection`, `ListCrossoverPipeline`, `LongVectorIndividual`, `MasterProblem`, `MetaProblem`, `MultiBreedingPipeline`, `MultiObjectiveFitness`, `MultipleVectorCrossoverPipeline`, `MultiSelection`, `MutateAllNodesPipeline`, `MutateDemotePipeline`, `MutateERCPipeline`, `MutateOneNodePipeline`, `MutatePromotePipeline`, `MutateSwapPipeline`, `MutationPipeline`, `NEATGene`, `NEATIndividual`, `NEATInnovation`, `NEATNetwork`, `NEATNode`, `NEATSpecies`, `NEATSubspecies`, `Nonterminal`, `NSGA2MultiObjectiveFitness`, `Particle`, `PBILSpecies`, `Problem`, `ProportionalTournamentSelection`, `PTC1`, `PTC2`, `PushBuilder`, `PushInstruction`, `PushProblem`, `RandomBranch`, `RandomSelection`, `RandTree`, `RatioBucketTournamentSelection`, `RehangPipeline`, `RepeatPipeline`, `ReproductionPipeline`, `Rule`, `RuleCrossoverPipeline`, `RuleIndividual`, `RuleMutationPipeline`, `RuleSet`, `RuleSpecies`, `SelectionMethod`, `ShortVectorIndividual`, `SigmaScalingSelection`, `SimpleFitness`, `SizeFairCrossoverPipeline`, `SpatialTournamentSelection`, `SPEA2MultiObjectiveFitness`, `Species`, `StubPipeline`, `SUSSelection`, `Terminal`, `TopSelection`, `TournamentSelection`, `Uniform`, `UniquePipeline`, `VectorCrossoverPipeline`, `VectorIndividual`, `VectorMutationPipeline`, `VectorSpecies`

public interface Prototype extends Cloneable, Setup
Prototype classes typically have one or a few prototype instances created during the course of a run. These prototype instances each get setup(...) called on them. From then on, all new instances of a Prototype classes are Cloned from these prototype instances.

The purpose of a prototype is to make it possible to ask classes, determined at run-time by user parameters, to instantiate themselves very many times without using the Reflection library, which would be very inefficient.

ECJ makes extensive use of Prototypes. Individuals are prototypes. Species are prototypes. Fitness objects are prototypes. Breeding pipelines and selection methods are prototypes. In the GP section, GPNodes and GPTrees are prototypes. In the Rule section, Rulesets and Rules are prototypes. In the Vector section, Genes are prototypes. And so on.

ECJ uses Prototypes almost exclusively instead of calling `new`. This is because `new requires that you know, in your code, the exact class of the object to be created. Doing so programmatically essentially precludes being able to set up object graphs dynamically from parameter files.`

Sadly, clone() is rather slower than calling `new`. However it is a lot faster than calling java.lang.Class.newInstance(), and somewhat faster than rolling our own "cloner" method.

Prototypes must be Cloneable, Serializable (through Setup), and of course, Setup.

- ## Method Summary

  Modifier and Type
  Method
  Description
  `Object`
  `clone()`
  Creates a new individual cloned from a prototype, and suitable to begin use in its own evolutionary context.
  `Parameter`
  `defaultBase()`
  Returns the default base for this prototype.
  `void`
  `setup(EvolutionState state, Parameter base)`
  Sets up the object by reading it from the parameters stored in state, built off of the parameter base base.

- ## Method Details

  - ### clone

    Object clone()
    Creates a new individual cloned from a prototype, and suitable to begin use in its own evolutionary context.

    Typically this should be a full "deep" clone. However, you may share certain elements with other objects rather than clone hem, depending on the situation:

    - If you hold objects which are shared with other instances, don't clone them.
    - If you hold objects which must be unique, clone them.
    - If you hold objects which were given to you as a gesture of kindness, and aren't owned by you, you probably shouldn't clone them.
    - DON'T attempt to clone: Singletons, Cliques, or Populations, or Subpopulation.
    - Arrays are not cloned automatically; you may need to clone an array if you're not sharing it with other instances. Arrays have the nice feature of being copyable by calling clone() on them.

    Implementations.

    - If no ancestor of yours implements clone(), and you have no need to do clone deeply, and you are abstract, then you should not declare clone().
    - If no ancestor of yours implements clone(), and you have no need to do clone deeply, and you are not abstract, then you should implement it as follows:

      ``

           public Object clone()
               {
               try
                   {
                   return super.clone();
                   }
               catch ((CloneNotSupportedException e)
                   { throw new InternalError(); } // never happens
               }

    - If no ancestor of yours implements clone(), but you need to deep-clone some things, then you should implement it as follows:

      ``

           public Object clone()
               {
               try
                   {
                   MyObject myobj = (MyObject) (super.clone());

                   // put your deep-cloning code here...
                   }
               catch ((CloneNotSupportedException e)
                   { throw new InternalError(); } // never happens
               return myobj;
               }

    - If an ancestor has implemented clone(), and you also need to deep clone some things, then you should implement it as follows:

      ``

           public Object clone()
               {
               MyObject myobj = (MyObject) (super.clone());

               // put your deep-cloning code here...

               return myobj;
               }

  - ### setup

    void setup(EvolutionState state, Parameter base)
    Sets up the object by reading it from the parameters stored in state, built off of the parameter base base. If an ancestor implements this method, be sure to call super.setup(state,base); before you do anything else.

    For prototypes, setup(...) is typically called once for the prototype instance; cloned instances do not receive the setup(...) call. setup(...) may be called more than once; the only guarantee is that it will get called at least once on an instance or some "parent" object from which it was ultimately cloned.

    Specified by:
      `setup` in interface `Setup`

  - ### defaultBase

    Parameter defaultBase()
    Returns the default base for this prototype. This should generally be implemented by building off of the static base() method on the DefaultsForm object for the prototype's package. This should be callable during setup(...).