Class-based Message System Pattern I'm trying to create an extensible system for building messages.

I want each style of message to be a unique class. I don't want the client to have to worry about the class type when creating the message (or reading it – but that is not included here).

In the code below, I only use ints and Strings. The final version would wrap ints and Strings in another class with data validation if necessary.

// Run from main
import xx.xxx.StandardFactory.*;
private void standardFactoryTest() {
    StandardFactory standardFactory = new StandardFactory();

    BasePackage testPackage1 = standardFactory.makePackage("Text for One");
    BasePackage testPackage2 = standardFactory.makePackage(999);
    BasePackage testPackage3 = standardFactory.makePackage("Text for Three", 129);

    testPackage1.printData(); // prints “StringPackage value: Text for One”
    testPackage2.printData(); // prints “IntPackage value: 999”
    testPackage3.printData(); // prints “StringIntPackage value: Text for Three, 129”
}

package xx.xxx.StandardFactory;

public class StandardFactory {
    public abstract class BasePackage{
        public abstract void printData();
    }

    public class StringPackage extends BasePackage {
        private final String value;

        StringPackage(String value) {
            this.value = value;
        }

        public void printData() {
            System.out.println("StringPackage value: " + value);
        };
    }

    public class IntPackage extends BasePackage  {
        private final int value;

        IntPackage(int value) {
            this.value = value;
        }

        public void printData() {
            System.out.println("IntPackage value: " + value);
        };
    }

    public class StringIntPackage extends BasePackage  {
        private final String stringValue;
        private final int intValue;

        StringIntPackage(String stringValue, int intValue) {
            this.stringValue = stringValue;
            this.intValue = intValue;
        }

        public void printData() {
            System.out.println("StringIntPackage value: " + stringValue + ", " + intValue);
        };
    }

    public StringPackage makePackage(String value) {
        return new StringPackage(value);
    }

    public IntPackage makePackage(int value) {
        return new IntPackage(value);
    }

    public StringIntPackage makePackage(String stringValue, int intValue) {
        return new StringIntPackage(stringValue, intValue);
    }
}


Potential problems:
    If I add new classes I need to add them to the factory. I don't see this as too much work.
    Messages could take arguments in a different order. I will not need to make every different     combination of input for my purposes so this should not be a problem.
    Large packages may need five or six different arguments. This goes against the principle of     using few arguments in a function, but it would be the exception not the rule.

I am interested specifically in the following:


Is this a common design
pattern (is it a version of the factory pattern)? 
Are there more
suitable design pattern options available? 
Are there any obvious
improvements? 
Is it possible to have the factory static so I don't
need a factory object?


I am not interested in the following (with reasons):


Naming – This has been done as example code
Comments – I have not attempted to comment this code
Data validation – Not required at this point


Everything else is fair game.
Seems you are on the right way. But mostly depends how will the client use your factory and BasePackage.
Here are some my minor remarks for improvements:


Only BasePackage is to be public, all the implementation classes are to be hidden.
makePackage() should return BasePackage type.
To reduce possible 5..6 arguments think about varargs solution.
Yes, you may have factory as a static, because you don't have an internal state (at least for now).
Naming: if possible rename BasePackage to reflect your domain area. BasePackage for client perspective may be not clear. But it is ok if you have good package hierarchy.