-6

(JAVA) I have about 50 Getters, all return the same text, tag, type. Text and tag are String and type is int. The purpose is a forms that use repetitive fields along with form specific fields. I am having trouble with simplifying and reusing code?

public class DataTransferClass {

private DataTransferClass(){}

public class FirstName
{
    public String getText()
    {
        return "First Name:";
    }

    public String getTag(){
        return "First";
    }

    public int getType(){
        return android.text.InputType.TYPE_TEXT_VARIATION_PERSON_NAME;
    }
}

public class LastName
{
    public String getText()
    {
        return "Last Name:";
    }

    public  String getTag(){
        return "Last";
    }

    public int getType(){
        return android.text.InputType.TYPE_TEXT_VARIATION_PERSON_NAME;
    }
}

...

The answer I’m looking for is the best way to manage data returns, since I’m returning different primitive types return an array does not work very well. I understand that I can convert the integer into string and return an Array. But then I must convert the String back into an integer when needed. All fifty getters return the same primitive types. Maintaining three arrays with fifty elements is nearly impossible to maintain, update or modify specific elements.

closed as unclear what you're asking by gnat, Doc Brown, Bart van Ingen Schenau, amon, Jörg W Mittag Dec 21 '17 at 8:26

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 7
    Can you state this in the form of a question? – joshp Dec 21 '17 at 1:24
  • 2
    Why do you have inner classes which are getters? What purpose do they server? Could you post some sample code so we can see what you mean? This sounds very abnormal and I'm wondering exactly what you are talking about. – Maybe_Factor Dec 21 '17 at 4:31
  • 1
    "I am having trouble with simplifying and reusing code?" -> If that's the question, then the answer is "yes you are", apparently. – janos Dec 21 '17 at 8:00
  • A useful search phrase is "how to I implement repetitive fields / an array of fields programmatically?" If you are not doing it programmatically, then having 50 copies of nearly identical code snippet is unavoidable. See also: convention over configuration for an example of enablement of programmatically generated code. – rwong Dec 22 '17 at 20:46
2

It sounds like you have requirements that are causing some sort of explosion of getters and/or fields.

Sometimes we can find the simplicity and code reuse / DRY'ness we're looking for by using a templating engine, which is to say we write some code to generate some code. That way you can write the common stuff once (i.e. fix bugs in one place), maybe use a table to enumerate all the getter/field names, and then run the code to generate the classes. If this was C#, I'd suggest T4. For Java you can see here; also see Metaprogramming.

On another note, if this is an internal situation, you can access fields directly w/o using getters... Not recommended for a external API, of course, b/c introducing some additional logic cannot be done w/o changing the API and the clients using it.

2

First, not sure I really understand your question, so this answer may be way off base...

Once you have a lot of similar fields, consider an Array or Map for them.

For example, assuming you have already defined a basic class TestTagType to hold the two Strings and int, instead of

public TestTagType getFormValueName();
public TestTagType getFormValueAddress();
... 48 more ...

Consider if this can be better coded as

public TestTagType getFormValue(int index);

or, better, something like one of:

public TestTagType getFormValue(String name);
public TestTagType getFormValue(FormEnum name);

I really like the Enum option as, when you define the Enum, it documents the fields of the form. But if fields keep getting added or changed the much looser (some might argue "too loose") String option is more practical.

  • I do prefer the Enum option if at all possible, as it lets you expand on the definition of what it means to be a field quite easily. Unless fields aren't dynamically loaded, this should be a reasonable solution in most circumstances. – Neil Dec 21 '17 at 10:58

Not the answer you're looking for? Browse other questions tagged or ask your own question.