Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #5461 > unrolled thread

How to name class which will read and write configuration to file

Back to article view | Back to comp.programming

Contents

  How to name class which will read and write configuration to file pavelkastornii@gmail.com - 2015-05-26 14:39 -0700
    Re: How to name class which will read and write configuration to file August Karlstrom <fusionfile@gmail.com> - 2015-05-27 16:02 +0200
      Re: How to name class which will read and write configuration to file Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2015-05-27 22:13 -0700
        Re: How to name class which will read and write configuration to file August Karlstrom <fusionfile@gmail.com> - 2015-05-28 08:32 +0200
          Re: How to name class which will read and write configuration to file Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2015-05-28 09:23 -0700
            Re: How to name class which will read and write configuration to file August Karlstrom <fusionfile@gmail.com> - 2015-05-28 21:25 +0200
              Re: How to name class which will read and write configuration to file Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2015-05-28 21:28 -0700

#5461 — How to name class which will read and write configuration to file

I have a Configuration class and conf.xml file which contains configuration data. I am thinking about naming class, that will read data from xml-> java and write data java-> xml. ConfigProvider is not good way as it suitable onlt for xml->java. ConfigReaderWriter is a better, but maybe someone will suggest another variants?

[toc] | [next] | [standalone]

#5462

On 2015-05-26 23:39, pavelkastornii@gmail.com wrote:
> I have a Configuration class and conf.xml file which contains
> configuration data. I am thinking about naming class, that will read
> data from xml-> java and write data java-> xml. ConfigProvider is not
> good way as it suitable onlt for xml->java. ConfigReaderWriter is a
> better, but maybe someone will suggest another variants?
>

Why not simply add the read and write methods to the Configuration class?


-- August

[toc] | [prev] | [next] | [standalone]

#5464

On 5/27/15 7:02 AM, August Karlstrom wrote:
> On 2015-05-26 23:39, pavelkastornii@gmail.com wrote:
>> I have a Configuration class and conf.xml file which contains
>> configuration data. I am thinking about naming class, that will read
>> data from xml-> java and write data java-> xml. ConfigProvider is not
>> good way as it suitable onlt for xml->java. ConfigReaderWriter is a
>> better, but maybe someone will suggest another variants?
>>
>
> Why not simply add the read and write methods to the Configuration class?
That is a terrible idea if this is a long-lived project.  What happens 
when they want to support yml too? Or json? Or something else.  Then 
your Configuration class has so many responsibilities that it is a mess...

If you need to write the data to a file, I would have an interface 
"ConfigurationWriter" with the "XmlConfigurationWriter" implementation.

I would have a separate interface "ConfigurationReader" with the 
"XmlConfigurationReader" implementation.


I would also suggest that the interfaces don't know about a specific 
file, but have an argument passed to the load/save method which is the 
stream to read from/write to.  (For example, InputStream/OutputStream in 
Java)

Hope this helps,
Daniel.

[toc] | [prev] | [next] | [standalone]

#5465

On 2015-05-28 07:13, Daniel Pitts wrote:
> On 5/27/15 7:02 AM, August Karlstrom wrote:
>> On 2015-05-26 23:39, pavelkastornii@gmail.com wrote:
>>> I have a Configuration class and conf.xml file which contains
>>> configuration data. I am thinking about naming class, that will read
>>> data from xml-> java and write data java-> xml. ConfigProvider is not
>>> good way as it suitable onlt for xml->java. ConfigReaderWriter is a
>>> better, but maybe someone will suggest another variants?
>>>
>>
>> Why not simply add the read and write methods to the Configuration class?
> That is a terrible idea if this is a long-lived project.  What happens
> when they want to support yml too? Or json? Or something else.

If you try to anticipate every possible future change to the 
requirements your application will indeed be very complex. In this 
(unlikely) case I would rather let a separate tool handle the conversion 
to XML.

http://www.manageability.org/blog/stuff/over-abstraction-java-achilles-heel/view


-- August

[toc] | [prev] | [next] | [standalone]

#5469

On 5/27/15 11:32 PM, August Karlstrom wrote:
> On 2015-05-28 07:13, Daniel Pitts wrote:
>> On 5/27/15 7:02 AM, August Karlstrom wrote:
>>> On 2015-05-26 23:39, pavelkastornii@gmail.com wrote:
>>>> I have a Configuration class and conf.xml file which contains
>>>> configuration data. I am thinking about naming class, that will read
>>>> data from xml-> java and write data java-> xml. ConfigProvider is not
>>>> good way as it suitable onlt for xml->java. ConfigReaderWriter is a
>>>> better, but maybe someone will suggest another variants?
>>>>
>>>
>>> Why not simply add the read and write methods to the Configuration
>>> class?
>> That is a terrible idea if this is a long-lived project.  What happens
>> when they want to support yml too? Or json? Or something else.
>
> If you try to anticipate every possible future change to the
> requirements your application will indeed be very complex. In this
> (unlikely) case I would rather let a separate tool handle the conversion
> to XML.
It really depends on the type of product you are creating, including the 
expected lifetime and user-base.

However, the "S.O.L.I.D" principles are often helpful regardless of what 
your system ultimately aims to be.

In particular, the "Single Responsibility Principle" seems relevant 
here.  A class that represents a Configuration, shouldn't also represent 
a ConfigurationLoader and ConfigurationSaver.

[toc] | [prev] | [next] | [standalone]

#5471

On 2015-05-28 18:23, Daniel Pitts wrote:
> In particular, the "Single Responsibility Principle" seems relevant
> here.  A class that represents a Configuration, shouldn't also represent
> a ConfigurationLoader and ConfigurationSaver.

To me this makes as much sense as saying that a class that represents a 
stack shouldn't also represent a stack pusher and a stack popper. As I 
see it the configuration class doesn't *represent* a loader or a saver - 
the methods `load' and `save' are just operations on the configuration.


-- August

[toc] | [prev] | [next] | [standalone]

#5472

On 5/28/15 12:25 PM, August Karlstrom wrote:
> On 2015-05-28 18:23, Daniel Pitts wrote:
>> In particular, the "Single Responsibility Principle" seems relevant
>> here.  A class that represents a Configuration, shouldn't also represent
>> a ConfigurationLoader and ConfigurationSaver.
>
> To me this makes as much sense as saying that a class that represents a
> stack shouldn't also represent a stack pusher and a stack popper.
The property of "being able to push and pop items" is a defining feature 
of a Stack abstraction.  Would you call it a Stack if you couldn't push, 
or pop? I'm going to assume not.

Now, would you call a Configuration class a Configuration if it couldn't 
read itself from a file or write itself out? I'd venture to say you would.

> As I
> see it the configuration class doesn't *represent* a loader or a saver -
> the methods `load' and `save' are just operations on the configuration.

Having the "Loader" and "Saver" operations be handled by distinct 
classes helps in several ways.  Not the least of which is that it 
provides a more flexible design.  It also reduces "clutter" in the 
Configuration class.

If the loading process is complex enough, you could have a bunch of 
private helper methods to go along with the load.  Now you've got many 
lines of code in the Configuration class that isn't related to "being a 
Configuration"

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web