Should your configuration class be a friend of the class(es) it's configuring?

[GregFreeman]

I have a configuration class that loads a configuration and creates a bunch of channels. I'm having a hard time deciding if accessors like "write physical channel" should be community scoped, so the configuration VIs can write to them, but nothing else can. Or, should I just make these things public? It seems community scope would be the safest option, especially for members that shouldn't be changed once reconfiguration is done, but I'm curious if there are any drawbacks to this design, or things I should take into account when deciding community vs public.

Edited September 26, 2013 by for(imstuck)

[ShaunR]

 or things I should take into account when deciding community vs public.

I've just been bitten by this and had to convert community scoped functions to public..

[GregFreeman]

Thanks, I think we are going to go the JSON route, especially since those VIs are now built into LabVIEW 2013.

[PaulL]

Thanks, I think we are going to go the JSON route, especially since those VIs are now built into LabVIEW 2013.

So, does this answer your original question?  You are using JSON for serialization?  Does that relate to the configuration class accessor methods scope, or is this a separate question?

 

I'm not a fan of community scope in general (haven't had a use case where it really added anything--maybe they make sense for the XControl use case they targeted, but I don't create XControls; lack of inheriting the relationship is in practice inconvenient for other use cases; community scope was dropped in C++, after all), so I would make these methods public myself, but as a disclaimer, I don't actually store the configuration in objects, but as typedefined clusters (clusters have front panels, which helps when makes it easier to create a configuration editor;  there is no nonaccessor functionality anyway, so clusters suit the needs well; also for historical performance reasons).  Cluster access is public.  That works in our environment, but may not be suitable for code that one distributes widely.

[GregFreeman]

Paul, you must be super confused. My response was supposed to be to another thread.

 

I agree with your configuration idea, and I pretty much do this too. But, my configuration class has methods that take it's configuration data and generate objects that will hold that data (maybe herein lies the problem). Let me give an example of what I'm doing and I'm more than open to other ways of doing things.

 

So, in my software there is a typedef cluster of all my channel configuration info. This cluster is held inside the channel configuration class. Now, I have a method in that same channel configuration class that is "generate channels" which takes all that config info and builds an array of channel classes and returns it, giving necessary info from its typedef'd cluster to each channel class that is created. In my application, the only class setting certain parts of the channel (such as which physical channel a specific instance of a channel class is using) should be the configuration class. If a channel class has been created and given its physical channel name by the configuration class, it should not be able to be updated anywhere else in the application.

 

Does that help clarify?

[ShaunR]

Paul, you must be super confused. My response was supposed to be to another thread.

I don't think it was Paul who was confused. Look at your post above his

[PaulL]

Paul, you must be super confused. My response was supposed to be to another thread.

OK.  Lol.

 

I think I understand what your configuration class does.  What we do is slightly different.  We store the configuration in typedef'd clusters.  Each class that uses that information keeps a copy of the cluster in its private data and reads the data from file on each initialization (during a state transition defined as part of the application--not really object initialization, although one can look at it that way).  Then each class that needs the data has it ready for use.  This makes it easy to reuse configuration items.  It does not prevent a calls that contains a copy of the cluster from modifying its copy of the cluster data, but I don't think we need to do that.

 

Now what you are calling a configuration class is, it seems to me, actually a layer above that, that performs some action with the configuration data.  This I would not call a configuration class (I'd pick something descriptive of the channels or application), but that's probably not the key point.  In any case, it seems the Channel class (yet another class) is the one you are not sure should have public methods.  Or do you mean the ChannelConfiguration.generateChannels() method, that in turn has access to the Channel class methods?

 

OK, I guess I don't quite understand the class relationships and purposes you intend yet, after all.  Can you clarify?  (I'd love to see a diagram, of course.)

 

Paul

[GregFreeman]

I don't think it was Paul who was confused. Look at your post above his

I know, I meant I think he must have been confused due to my post that was completely irrelevant in this thread   . Too many LAVA tabs open at once!

 

 

 Or do you mean the ChannelConfiguration.generateChannels() method, that in turn has access to the Channel class methods?

 

Paul

 Can't post a diagram right now, but yes, I think this sums it up and you're understanding what I'm doing (whether this method is right or wrong I don't know yet!). The channel class has a write accessor. When the configuration class method "generateChannels" is called, it should look at its configuration info typedef, and generate all the channels, setting the channel's properties. What I don't want is somewhere else in my application, someone coming along and dropping that accessor and updating certain private data in the channel class.  

 

For example, I don't care if they update a channel's waveform. What I do care about is if they change the channel name or physical channel it respresents!

Edited October 11, 2013 by for(imstuck)

[PaulL]

Hmm..., well, I guess I would make the accessor methods in question public and address the question by setting up the architecture (e.g., by composition--note that I use by value objects only), but that isn't guaranteed to be safe.  (For your application, what is the likelihood of misuse happening?)

 

Maybe package scope would be helpful in this case, if LabVIEW supported it, but I think it would depend on which classes use the ChannelClass objects.

 

Well, one other option would be to use composition, such that the Configuration class is a member of the Channel class private data.  Then a call to Channel.configure() [or init()] or whatever, could be public, but it would always return the desired answer, since it would depend on data within itself.  I don't know if that will work for your application.

[GregFreeman]

Paul, the likelihood of misuse is pretty small. Most of my coworkers are CLAs who are very competent programmers, but at the same time, OOP is slowly being propagated throughout the company and is a relatively new concept to many of them (myself included, but some much more-so than others.). I have been lucky enough to get more projects than most where I can really practice with it, so I have been driving much of the transition effort. That said, my primary concern is that it's quite easy for someone with limited OO experience to abuse getters/setters, so if I can enforce how and where they are used, it may cause less potential headaches in the long run. I'm trying to see into the future for possible issues (always a tough thing to do!). The above situation may not even be a problem, but I still think it is something worth considering.

Edited October 21, 2013 by for(imstuck)