Answered Best approach (oo Question)

[Rod Anderson]

10.2A Linux
(New to OO)

I have a working class that audit's information being sent to an external 'c' program (not really relevant). The problem is I need to shared the instance of the class between two programs (program A calls B several times).

To accomplish this I created and static variable for the class that instantiates the class as NEW and an internal static method which program A and B just use (if I'm saying that right). I really don't think I want or need the entire class to be static.

Assuming I'm doing it wrong what is the proper way to handle this situation?

Thanks in advance,

Rod

 

[GregTomkins]

The "external C program" might be relevant; how do you communicate with it and assuming you use a socket or similar, do you keep it open permanently or open & close it for each operation?

Besides static, you could read up on singleton, though both are generally frowned upon (especially singleton).

 

[Rod Anderson]

I'm currently testing running the 'c' program persistently. The communication is via an input/output memptr. The memptr is set back to zero after every use.

 

[GregTomkins]

This is from Java (I don't know Progress OO to any meaningful extent), but I think the same concepts apply:

One of thousands of posts about why static is bad:
http://java.dzone.com/articles/why-static-bad-and-how-avoid

One of millions about why singletons (statics evil cousin) are bad:
http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons

Assuming the cost of establishing communication to your C program is measurable, the purist approach would be to maintain a pool of 'C program communicator objects', and grab one each time you needed one. That would require writing a Progress pooling mechanism (in Java land, these are common and many FOSS implementations exist), which would be non-trivial, so personally, I'd likely just make it static and move on, but I'm at the opposite end of the spectrum from 'purist'.

Possibly Important: there are issues with statics in Progress that I don't have experience with, IIRC, something to do with DB access being a bad idea (not applicable to you from the sounds of it) and their resources never being freed (might be slightly applicable to you). People on here who know about Progress OO (Tamhas, TomB, RHD) often mention them, so hopefully they will fill you in.

 

[Rod Anderson]

Thanks again Greg,

I think I'm going to move on. This is for the scientific lab and not production in the field so while it will stay in memory it works and the overhead seams to be low (no db connectivity as well (only temp-table)).

Rod

 

[RealHeavyDude]

There are always exceptions to a rule. There comes a time when a puristic approach following a rule will lead you nowhere - or will make you things more complicated than they need be. While I generally don't use static or the singleton pattern, there are some use cases where I do use the singleton pattern or even static on purpose. Singletons mostly for connection pooling to single threaded services. Public static variables the same way as I use constants in Java. I like them better than using include files for variables.

But then again - I hate relogious flame wars as experience has shown me time and time again that there might be a valid use case for anything that is bad practice in general and that you should avoid. But not at any cost, like me using a share lock on purpose to implement batch processing where only one job of a given type should be running ( any attempt to run a second instance of the same job fails because it can't get the exclusive lock and when the only instance of the job crashes for whatever reason the database will clean the lock ).

Heavy Regards, RealHeavyDude.