Skip to main content
added 5 characters in body
Source Link
Tulains Córdova
  • 39.5k
  • 13
  • 99
  • 155

I looks to me that you have two different problems. Problem A is easy to solve. But problem B is harder.

Problem A is to dynamically call a given strategy given a configString. That can be solved by creating a Map and pairing an instance of each parser with a string that identifies it. That way you just fetch from the Map the parser you need. If the parser is too costly to instantiate, you can put in the Map a builder for that parser instead. This solution assumes that the final user (or you) knows what type of configuration file is going to be parsed.

Obviously, to achieve total decoupling, a factory should set up the whole Map of parsers (or parser creatorsbuilder) and the client should have this Map passpassed to it. That way only the factory is hard coupled to the concrete parsers.

Problem B is that you want to automatically determine what kind of file (or istream) you are reading to use the appropiate parser, i.e., the final user (or you) will not select the file and tell the app the type of conf file.

A solution for problem B is to have all parsers in a vectorList and iterate through themit. When one parser fails to parse the stream, go to the next parser and so on. If a parser successfully parses the stream, end of story (you can report what parser you finally used if you add a name field to the parsers). If every parser fails then the file is not supported by any parser. You don't need to investigate inside the stream to guess the format, let the parsers try to parse it. One potential problem I see with this solution is that it is possible that two different parsers could interpret the same input format in different ways without failing. In that case the first parser that does will always do the work and it may not be the one you expected.

A log output could look like this:

Parsing: unknown_config_file
..not XML
..not JSON
..successfully parsed using "ini" parser.

or

Parsing: unknown_config_file
..not XML
..not JSON
..not ini
..unsuported config file.

I looks to me that you have two different problems. Problem A is easy to solve. But problem B is harder.

Problem A is to dynamically call a given strategy given a configString. That can be solved by creating a Map and pairing an instance of each parser with a string that identifies it. That way you just fetch from the Map the parser you need. If the parser is too costly to instantiate, you can put in the Map a builder for that parser instead. This solution assumes that the final user (or you) knows what type of configuration file is going to be parsed.

Obviously, to achieve total decoupling, a factory should set up the whole Map of parsers (or parser creators) and the client should have this Map pass to it. That way only the factory is hard coupled to the concrete parsers.

Problem B is that you want to automatically determine what kind of file (or istream) you are reading to use the appropiate parser, i.e., the final user (or you) will not select the file and tell the app the type of conf file.

A solution for problem B is to have all parsers in a vector and iterate through them. When one parser fails to parse the stream, go to the next parser and so on. If a parser successfully parses the stream, end of story (you can report what parser you used if you add a name field to the parsers). If every parser fails then the file is not supported by any parser. You don't need to investigate inside the stream to guess the format, let the parsers try to parse it. One potential problem I see with this solution is that it is possible that two different parsers could interpret the same input format in different ways without failing. In that case the first parser that does will always do the work and it may not be the one you expected.

A log output could look like this:

Parsing: unknown_config_file
..not XML
..not JSON
..successfully parsed using "ini" parser.

or

Parsing: unknown_config_file
..not XML
..not JSON
..not ini
..unsuported config file.

I looks to me that you have two different problems. Problem A is easy to solve. But problem B is harder.

Problem A is to dynamically call a given strategy given a configString. That can be solved by creating a Map and pairing an instance of each parser with a string that identifies it. That way you just fetch from the Map the parser you need. If the parser is too costly to instantiate, you can put in the Map a builder for that parser instead. This solution assumes that the final user (or you) knows what type of configuration file is going to be parsed.

Obviously, to achieve total decoupling, a factory should set up the whole Map of parsers (or parser builder) and the client should have this Map passed to it. That way only the factory is hard coupled to the concrete parsers.

Problem B is that you want to automatically determine what kind of file (or istream) you are reading to use the appropiate parser, i.e., the final user (or you) will not select the file and tell the app the type of conf file.

A solution for problem B is to have all parsers in a List and iterate through it. When one parser fails to parse the stream, go to the next parser and so on. If a parser successfully parses the stream, end of story (you can report what parser you finally used if you add a name field to the parsers). If every parser fails then the file is not supported by any parser. You don't need to investigate inside the stream to guess the format, let the parsers try to parse it. One potential problem I see with this solution is that it is possible that two different parsers could interpret the same input format in different ways without failing. In that case the first parser that does will always do the work and it may not be the one you expected.

A log output could look like this:

Parsing: unknown_config_file
..not XML
..not JSON
..successfully parsed using "ini" parser.

or

Parsing: unknown_config_file
..not XML
..not JSON
..not ini
..unsuported config file.
added 3 characters in body
Source Link
Tulains Córdova
  • 39.5k
  • 13
  • 99
  • 155

I looks to me that you have two different problems. Problem A is easy to solve. But problem B is harder.

Problem A is to dynamically call a given strategy given a configString. That can be solved by creating a Map and pairing an instance of each parser with a string that identifies it. That way you just fetch from the Map the parser you need. If the parser is too costly to instantiate, you can put in the Map a builder for that parser instead. This solution assumes that the final user (or you) knows what type of configuration file is going to be parsed.

Obviously, to achieve total decoupling, a factory should set up the whole Map of parsers (or parser creators) and the client should have this Map pass to it. That way only the factory is hard coupled to the concrete parsers.

Problem B is that you want to automatically determine what kind of file (or istream) you are reading to use the appropiate parser, i.e., the final user (or you) will not select the file and tell the app the type of conf file.

A solution for problem B is to have all parsers in a vector and iterate through them. When one parser fails to parse the stream, go to the next parser and so on. If a parser successfully parses the stream, end of story (you can report what parser you used if you add a name field to the parsers). If every parser fails then the file is not supported by any parser. You don't need to investigate inside the stream to guess the format, let the parsers try to parse it. One potential problem I see with this solution is that it is possible that two different parsers could interpret the same input format in different ways without failing. In that case the first parser that does will always do the work and it may not be the one you expected.

A log outoutput could look like this:

Parsing: unknown_config_file
..not XML
..not JSON
..successfully parsed using "ini" parser.

or

Parsing: unknown_config_file
..not XML
..not JSON
..not ini
..unsuported config file.

I looks to me that you have two different problems. Problem A is easy to solve. But problem B is harder.

Problem A is to dynamically call a given strategy given a configString. That can be solved by creating a Map and pairing an instance of each parser with a string that identifies it. That way you just fetch from the Map the parser you need. If the parser is too costly to instantiate, you can put in the Map a builder for that parser instead. This solution assumes that the final user (or you) knows what type of configuration file is going to be parsed.

Obviously, to achieve total decoupling, a factory should set up the whole Map of parsers (or parser creators) and the client should have this Map pass to it. That way only the factory is hard coupled to the concrete parsers.

Problem B is that you want to automatically determine what kind of file (or istream) you are reading to use the appropiate parser, i.e., the final user (or you) will not select the file and tell the app the type of conf file.

A solution for problem B is to have all parsers in a vector and iterate through them. When one parser fails to parse the stream, go to the next parser and so on. If a parser successfully parses the stream, end of story (you can report what parser you used if you add a name field to the parsers). If every parser fails then the file is not supported by any parser. You don't need to investigate inside the stream to guess the format, let the parsers try to parse it. One potential problem I see with this solution is that it is possible that two different parsers could interpret the same input format in different ways without failing. In that case the first parser that does will always do the work and it may not be the one you expected.

A log out could look like this:

Parsing: unknown_config_file
..not XML
..not JSON
..successfully parsed using "ini" parser.

or

Parsing: unknown_config_file
..not XML
..not JSON
..not ini
..unsuported config file.

I looks to me that you have two different problems. Problem A is easy to solve. But problem B is harder.

Problem A is to dynamically call a given strategy given a configString. That can be solved by creating a Map and pairing an instance of each parser with a string that identifies it. That way you just fetch from the Map the parser you need. If the parser is too costly to instantiate, you can put in the Map a builder for that parser instead. This solution assumes that the final user (or you) knows what type of configuration file is going to be parsed.

Obviously, to achieve total decoupling, a factory should set up the whole Map of parsers (or parser creators) and the client should have this Map pass to it. That way only the factory is hard coupled to the concrete parsers.

Problem B is that you want to automatically determine what kind of file (or istream) you are reading to use the appropiate parser, i.e., the final user (or you) will not select the file and tell the app the type of conf file.

A solution for problem B is to have all parsers in a vector and iterate through them. When one parser fails to parse the stream, go to the next parser and so on. If a parser successfully parses the stream, end of story (you can report what parser you used if you add a name field to the parsers). If every parser fails then the file is not supported by any parser. You don't need to investigate inside the stream to guess the format, let the parsers try to parse it. One potential problem I see with this solution is that it is possible that two different parsers could interpret the same input format in different ways without failing. In that case the first parser that does will always do the work and it may not be the one you expected.

A log output could look like this:

Parsing: unknown_config_file
..not XML
..not JSON
..successfully parsed using "ini" parser.

or

Parsing: unknown_config_file
..not XML
..not JSON
..not ini
..unsuported config file.
deleted 51 characters in body
Source Link
Tulains Córdova
  • 39.5k
  • 13
  • 99
  • 155

I looks to me that you have two different problems. Problem A is easy to solve. But problem B is harder.

Problem A is to dynamically call a given strategy given a configString. That can be solved by creating a Map and pairing an instance of each parser with a string that identifies it. That way you just fetch from the Map the parser you need. If the parser is too costly to instantiate, you can put in the Map a builder for that parser instead. This solution assumes that the final user (or you) knows what type of configuration file is going to be parsed.

Obviously, to achieve total decoupling, a factory should set up the whole Map of parsers (or parser creators) and the client should have this Map pass to it. That way only the factory is hard coupled to the concrete parsers.

Problem B is that you want to automatically determine what kind of file (or istream) you are reading to use the appropiate parser, i.e., the final user (or you) will not select the file and tell the app the type of conf file.

A solution for problem B is to have all parsers in a vector and iterate through them. When one parser fails to parse the stream, go to the next parser and so on. If a parser successfully parses the stream, end of story (you can report what parser you used if you add a name field to the parsers). If every parser fails then the file is not supported by any parser. You don't need to investigate inside the stream to guess the format, let the parsers themselves fail (report that the stream is malformed ) ortry to parse it. One potential problem I see with this solution is that it is possible that two different parsers could interpret the same input format in different ways without failing. In that case the first parser that does will always do the work and it may not be the one you expected.

A log out could look like this:

Parsing: unknown_config_file
..not XML
..not JSON
..successfully parsed using "ini" parser.

or

Parsing: unknown_config_file
..not XML
..not JSON
..not ini
..unsuported config file.

I looks to me that you have two different problems. Problem A is easy to solve. But problem B is harder.

Problem A is to dynamically call a given strategy given a configString. That can be solved by creating a Map and pairing an instance of each parser with a string that identifies it. That way you just fetch from the Map the parser you need. If the parser is too costly to instantiate, you can put in the Map a builder for that parser instead. This solution assumes that the final user (or you) knows what type of configuration file is going to be parsed.

Obviously, to achieve total decoupling, a factory should set up the whole Map of parsers (or parser creators) and the client should have this Map pass to it. That way only the factory is hard coupled to the concrete parsers.

Problem B is that you want to automatically determine what kind of file (or istream) you are reading to use the appropiate parser, i.e., the final user (or you) will not select the file and tell the app the type of conf file.

A solution for problem B is to have all parsers in a vector and iterate through them. When one parser fails to parse the stream, go to the next parser and so on. If a parser successfully parses the stream, end of story (you can report what parser you used if you add a name field to the parsers). If every parser fails then the file is not supported by any parser. You don't need to investigate inside the stream to guess the format, let the parsers themselves fail (report that the stream is malformed ) or parse it. One potential problem I see with this solution is that it is possible that two different parsers could interpret the same input format in different ways without failing. In that case the first parser that does will always do the work and it may not be the one you expected.

I looks to me that you have two different problems. Problem A is easy to solve. But problem B is harder.

Problem A is to dynamically call a given strategy given a configString. That can be solved by creating a Map and pairing an instance of each parser with a string that identifies it. That way you just fetch from the Map the parser you need. If the parser is too costly to instantiate, you can put in the Map a builder for that parser instead. This solution assumes that the final user (or you) knows what type of configuration file is going to be parsed.

Obviously, to achieve total decoupling, a factory should set up the whole Map of parsers (or parser creators) and the client should have this Map pass to it. That way only the factory is hard coupled to the concrete parsers.

Problem B is that you want to automatically determine what kind of file (or istream) you are reading to use the appropiate parser, i.e., the final user (or you) will not select the file and tell the app the type of conf file.

A solution for problem B is to have all parsers in a vector and iterate through them. When one parser fails to parse the stream, go to the next parser and so on. If a parser successfully parses the stream, end of story (you can report what parser you used if you add a name field to the parsers). If every parser fails then the file is not supported by any parser. You don't need to investigate inside the stream to guess the format, let the parsers try to parse it. One potential problem I see with this solution is that it is possible that two different parsers could interpret the same input format in different ways without failing. In that case the first parser that does will always do the work and it may not be the one you expected.

A log out could look like this:

Parsing: unknown_config_file
..not XML
..not JSON
..successfully parsed using "ini" parser.

or

Parsing: unknown_config_file
..not XML
..not JSON
..not ini
..unsuported config file.
Source Link
Tulains Córdova
  • 39.5k
  • 13
  • 99
  • 155
Loading