Having them as singletons is a warning flag for me already. So, are there any problems with the approach?
Several, but the god class being a singleton in this case is not one of them. As a thought experiment, imagine someone would edit that property file and the system would read the file in at runtime in different states, so you'd be up to some possibly very dynamic behaviour (mind you, not in the good sense of the word). Luckily, that seems not to be the case. Externalizing the statements doesn't make a lot of sense, and I think inlining them would be quite appropriate, that seems not to be the main pain point.
From the snippets you gave, even without knowing the exact usage of the Information class it is very clear, that this class doesn't provide any meaningful abstraction in itself (really, which parts of any software system are NOT in some sense "Information") and exposes a much too large API surface to the classes which are using it, a text book example for a violation of the interface segregation principle actually. Therefore an important step would be to identify the several interfaces that are hidden in your twohundred-something methods, extract them, make the Information class implement them and make the current users of Information gradually independend from it. I wouldn't touch Information further, except for adding which of the newly identified and created interfaces it already implements. When you have the interfaces, you will see if it actually were DAOs in disguise or if the underlying design was more of a row data gateway or an active record. Be it as it may, when you have the interfaces extracted reimplement them and consider this as an opportunity to re-inline the queries. And when you are done with this, the names of the methods would be a worthy aspect on which some to spend some time working on.
Good luck with cleaning the augean stables ;)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Several, but the god class being a singleton in this case is not one of them. As a thought experiment, imagine someone would edit that property file and the system would read the file in at runtime in different states, so you'd be up to some possibly very dynamic behaviour (mind you, not in the good sense of the word). Luckily, that seems not to be the case. Externalizing the statements doesn't make a lot of sense, and I think inlining them would be quite appropriate, that seems not to be the main pain point.
From the snippets you gave, even without knowing the exact usage of the Information class it is very clear, that this class doesn't provide any meaningful abstraction in itself (really, which parts of any software system are NOT in some sense "Information") and exposes a much too large API surface to the classes which are using it, a text book example for a violation of the interface segregation principle actually. Therefore an important step would be to identify the several interfaces that are hidden in your twohundred-something methods, extract them, make the Information class implement them and make the current users of Information gradually independend from it. I wouldn't touch Information further, except for adding which of the newly identified and created interfaces it already implements. When you have the interfaces, you will see if it actually were DAOs in disguise or if the underlying design was more of a row data gateway or an active record. Be it as it may, when you have the interfaces extracted reimplement them and consider this as an opportunity to re-inline the queries. And when you are done with this, the names of the methods would be a worthy aspect on which some to spend some time working on.
Good luck with cleaning the augean stables ;)