Implementation problem.

[AlchemyDesign]

Hey guys, new to the forums here! I figured that this would be the best place to ask, so please, Admins, if this is in the wrong forum, I am terribly sorry. Anyway, on to my problem.

First let me say that this ISN'T any sort of homework, just my own personal satisfaction and enjoyment. Okay, so, in my program I am aiming to take a rather large amount of text that is broken down into sections which will be sortable (hopefully) via a dropdown box. Now, my quandry comes in how to implement and work the text itself. Would it be best to hard code all of the text, say, into their own separate print methods and just use the dropdown selections as calls? Or should I use text files and read it in at runtime and break it up via flags:

Ex: -888 Random text here blah blah blah blah -999
-888 Next Line of Text here blah blah blah -999

Or is there a completely different way to do this that I'm unaware of since I'm a mere Java Neophyte.

[GregBrannon]

Welcome to the forum! Please read this topic to learn how to post code in code or highlight tags and other useful info for new members.

What do you mean, "hard code all of the text," versus, "use text files and read it in at runtime and break it up via flags"? I'm sure it makes sense to you, but you haven't explained it well. If you're asking whether you should TYPE all of the text or COPY the text from an existing source and PASTE it into a file that will be read into the program, which do you think sounds more attractive?

[AlchemyDesign]

Lol, thank you. I'm very sorry, it does make sense to me...I don't really have code yet cause I'm not sure which way would be easiest unless you want me to use the tags for separating simple text examples? But I'll come up with some examples here.

Okay, what I'm doing is taking a games rule sets, and want to make them searchable via keywords. So I have the following:


Rule Name1 - Rule text block goes here for the rule.
Rule Name2 - Rule text block goes here for the rule.
Rule Name3 - Rule text block goes here for the rule.


As for hard code I mean taking each of the Rules and make a method for each:

public class RuleSet
{
public static main(String[] args)
{
   ---
   ---
 
   switch(ruleChoice)
   {
       case 1: ruleOne();
           break;
       case 2: ruleTwo();
           break;
       case 3: ruleThree();
           break;
       default: statement;
    }
}
 
public static void ruleOne()
{
     Print Rules text to output
}
 
public static void ruleTwo()
{
    Print Rules text to output
}
 
public static void ruleThree()
{
    Print Rules text to output
}
}

Or should I copy it from text files at program run?

public class RuleSet
{
public static void main(String[] args) throws
                                             FileNotFoundException
{
     static Scanner inFile = new Scanner(new FileReader = ("file location"));
 
     while(file has next)
     {
         somehow read file in and seperate
         into manageable blocks
     }
}
}

[GregBrannon]

Ah, much better.

If the rule names and their definitions will never change or are not editable, then hard coding them makes sense. If the opposite is true, then I suggest you save them to a file or configuration file and read them when the program begins and save them when it ends. Java doesn't do random file access well or conveniently, so plan on reading all data in and storing in appropriate variables when the program starts and then writing any changes to the data when the program exits or when the user chooses, as appropriate.

[AlchemyDesign]

Ah, okay, thanks...I wasn't sure if people actually did things like that or I was just being a novice. More ego than anything else I guess.

[aussiemcgr]

I try to hardcode as little as possible and load my runtime information from files, services, databases, ect.
Apart from making the code more maintainable, I also find it forces me to code very generically, which makes expanding my runtime information at a later time so much easier.

For example, let's say we had rules with different types that we wanted to organize, but we were loading those rules at runtime. We could have classes like these:

public enum RuleType {
	TYPE_ONE,
	TYPE_TWO;
}
 
public class Rule {
	public RuleType type;
	public String name;
	public String details;
 
	public Rule(RuleType type,String name,String details) {
		this.type = type;
		this.name = name;
		this.details = details;
	}
}
 
public class Runner {
	public static void main(String[] args) {
		Map<RuleType,List<Rule>> rules = new HashMap<>();
 
		List<Rule> loadedRules = Helper.loadRules(...);
		// there is more involved in loading, but I can't be bothered
		for(Rule rule : loadedRules) {
			List<Rule> addTo = rules.get(rule.type);
			if(addTo==null) {
				addTo = new ArrayList<>();
			}
			addTo.add(rule);
			rules.put(rule.type,addTo);
		}
 
		for(RuleType type : rules.keySet()) {
			System.out.println("Rules for: "+type.name());
			for(Rule rule : rules.get(type)) {
				System.out.println(rule.name+": "+rule.details);
			}
		}	
	}
}

And here is our input file (in xml for this example):

<rules>
	<rule>
		<type>TYPE_ONE</type>
		<name>Rule Name1</name>
		<details>Rule text 1</details>
	</rule>
	<rule>
		<type>TYPE_TWO</type>
		<name>Rule Name2</name>
		<details>Rule text 2</details>
	</rule>
</rules>

The code would load, organize, and then print the organized rules provided in the input file. Then, if we wanted to add another rule of type: TYPE_TWO, we just need to add it to the input file, and no code changes are needed.

<rules>
	<rule>
		<type>TYPE_ONE</type>
		<name>Rule Name1</name>
		<details>Rule text 1</details>
	</rule>
	<rule>
		<type>TYPE_TWO</type>
		<name>Rule Name2</name>
		<details>Rule text 2</details>
	</rule>
	<rule>
		<type>TYPE_TWO</type>
		<name>Rule Name3</name>
		<details>Rule text 3</details>
	</rule>
</rules>

If you hardcoded these rules, you would probably also hardcoded how you wanted to organize them. By that, I mean you probably wouldn't have given them types, but resolved them in the code, since the values are hardcoded. This would mean that you would then have to also rewrite how you wanted to handle each rule when you hardcode the new rules.
The above would work with hardcoded rules if you provided them with the RuleType values, but you probably wouldn't have considered that flexibility in your design steps if you hardcoded the rules (or, at least, I might not have initially). However, when you load the rules in from a file, you are FORCED to consider that sort of flexibility when you are designing.

You could even make the RuleTypes more abstract by just using Strings which are resolved from the input file instead of enums.
And that's way I mean by "coding generically".

[AlchemyDesign]

Ooh, fancy. Yeah, I was just going to do all the hardcoding by just adding the print methods for each rule and in the main simply organizing them by a list and then calling them via switch controls. I do like your way but I've done nothing in XML, though it does appear to be MUCH more convenient since I would only need to really write the loading and display code and then I could update the XML as I came to it or needed to...and would allow me to expand the program greatly. Any good online resources for learning XML?

Thanks for your reply.

[aussiemcgr]

I used XML in the example above because it is a common data format which is easy to read by humans. XML is a possible method of storing your data if you want to. Java has built-in APIs for reading/writing/parsing XML files. A good tutorial can be found here: Reading XML Data into a DOM (The Java™ Tutorials > Java API for XML Processing (JAXP) > Document Object Model)

However, you don't need to do this with XML. You can use any file format, even one you create. For example, you can have:

TYPE_ONE++++Rule Name1++++Rule text 1
TYPE_TWO++++Rule Name2++++Rule text 2
TYPE_TWO++++Rule Name3++++Rule text 3

This format would require more explanation, but it contains the same data. In the above input example, I have each rule on its own line, and I have the data separated with the delimiter: ++++. NOTE: I chose ++++ because you need to choose a delimiter which will not realistically appear in any of your data fields.
As you can see, not nearly as legible as the XML, but serves its purpose just the same.
As a comparison of the two:
Which is a smaller file size? The second one
Which is more structured? The XML one
Which is probably easier to code the reading mechanism for your program? The second one
Which is probably easier for you to edit manually? The XML one
Which is probably easier to notice mistakes and check? The XML one

At the end of the day, you need to assess the tradeoffs and determine which one you are more comfortable using.