How Generic are Your Modules?

[ryan_sheppard]

How Generic are Your Modules?

When creating your DQMH modules, how generic do you make them? I was recently creating a database module and realized that the module was no longer just a generic database module, but a module specific to a certain database. 

What I wanted my module to do is:

• Open connection to database.
• Store reference to that database.
• Broadcast that reference.
• Close reference to that database.

What my module has also started to do is:

• Read in columns from a specific database.
• Read specific values from that database
• Broadcast those values.

I will also be connecting to and reading values from a different database, but now I feel like I will not be able to use the database module for that task without making major changes. But I find myself questioning myself whether I should write specific modules, or write more generic modules? If I write generic modules for everything, I could see myself having hundreds of modules!

My all encompassing question is how many modules do your applications usually contain on average, and how specific to the application are they? 

After writing this, I realize this is more of software design question and not only applicable to DQMH, but hopefully you could share some basic ideas on your module design.

Ryan Sheppard

[Darren]

One approach I could see working well here would be to have a Database Module that defines the operations (requests) you wish to accomplish with any database. Then each database would be represented by a class, and you would instantiate the appropriate database class in your database module (either through static definition or a factory pattern). Then you can put database-specific functionality in override methods of each class.

[drjdpowell]

A database module is a poor example. Databases are sophisticated things designed for concurrent access, with advanced features like transactions.  Putting any kind of generic module in front of it is reinventing the wheel (badly).

Re your question, l use Messenger Library rather than DQMH modules, but I would say those created for an application are specific, not general.  I typically have about 5 to 10 in a complex app.  I have some generic modules, but these perform quite low-level tasks, like handling TCP communication, and are generally things one doesn't need to think about.

[ryan_sheppard]

---

@drjdpowell wrote:

A database module is a poor example. Databases are sophisticated things designed for concurrent access, with advanced features like transactions.  Putting any kind of generic module in front of it is reinventing the wheel (badly).

Re your question, l use Messenger Library rather than DQMH modules, but I would say those created for an application are specific, not general.  I typically have about 5 to 10 in a complex app.  I have some generic modules, but these perform quite low-level tasks, like handling TCP communication, and are generally things one doesn't need to think about.

I probably should have used a better descriptor for the database module, it's strictly a database communication module using the database connectivity toolkit. Once I have a connection to the database I will only be reading values from the database. Nothing overly sophisticated (I hope). 

So if your modules are specific, do you find that they are reusable across applications? Or even within the same application? I am looking to write modules that are extensible across multiple applications. And what I have observed so far, DQMH modules can be great for this.

[ryan_sheppard]

---

@Darren wrote:

One approach I could see working well here would be to have a Database Module that defines the operations (requests) you wish to accomplish with any database. Then each database would be represented by a class, and you would instantiate the appropriate database class in your database module (either through static definition or a factory pattern). Then you can put database-specific functionality in override methods of each class.

---

I have yet to dip in LVOOP, so currently I am attempting to create a solution only using DQMH modules. My thought is to have a Cloneable database communication module that creates the connection to the specified database. Which would allow multiple connections at one time.

The cloneable module would broadcast the database reference to a database specific module, which would use that to perform database specific functions. The singleton module would then request the cloneable to close the database connection when done with the database. The functionality of the database specific modules will be fairly simple, at this moment I will read in values from the database.

Once I start I may it is necessary to use LVOOP, but my gut tells me I can do this with just DQMH modules. 

[drjdpowell]

---

@ryan_sheppard wrote:

. My thought is to have a Cloneable database communication module that creates the connection to the specified database. Which would allow multiple connections at one time.

The cloneable module would broadcast the database reference to a database specific module, which would use that to perform database specific functions. The singleton module would then request the cloneable to close the database connection when done with the database. The functionality of the database specific modules will be fairly simple, at this moment I will read in values from the database.

---

It's a database.  It allows multiple connections.  It has a sophisticated language called SQL and easy yet powerful transactions.  It can allow multiple readers at the same time.  The only value in putting a "module" in front of it is if you can add something to what a database can already do far better than you can.  

A much better example would be a piece of hardware that is not very sophisticated.  Something with slow communication all by command-response, say.  Then you can write Module to mediate control of that hardware that really can add significant value.

[ryan_sheppard]

---

@drjdpowell wrote:

---

@ryan_sheppard wrote:

. My thought is to have a Cloneable database communication module that creates the connection to the specified database. Which would allow multiple connections at one time.

The cloneable module would broadcast the database reference to a database specific module, which would use that to perform database specific functions. The singleton module would then request the cloneable to close the database connection when done with the database. The functionality of the database specific modules will be fairly simple, at this moment I will read in values from the database.

---

It's a database.  It allows multiple connections.  It has a sophisticated language called SQL and easy yet powerful transactions.  It can allow multiple readers at the same time.  The only value in putting a "module" in front of it is if you can add something to what a database can already do far better than you can.  

A much better example would be a piece of hardware that is not very sophisticated.  Something with slow communication all by command-response, say.  Then you can write Module to mediate control of that hardware that really can add significant value.

---

It sounds like I do not have a correct understanding of the use of DQMH modules. I am not trying to add functionality to a database, I am trying to add functionality to my application which allows me to communicate with a database. My modules have high level functionality while it sounds like what you are talking about is more low level functionality. Correct me if I am wrong.

[drjdpowell]

---

@ryan_sheppard wrote:
I am trying to add functionality to my application which allows me to communicate with a database. 

---

You already have that in your Database Connectivity Toolkit.  Use it in your Modules that actually do stuff.  Use a separate DB connection in each Module.  Don't make a central "Database Module" unless there is a good reason.   To answer your original question, that good reason will likely to an application-specific reason, not a generic one.

[drjdpowell]

---

@ryan_sheppard wrote: 

The cloneable module would broadcast the database reference to a database specific module, which would use that to perform database specific functions. . 

---

The most important advice I can give is never share references except those that serve as "addresses".  The connection information of your Database is such an address, but the connection reference is not.  As it controls both Transactions and active statements, it is really a connection "session" rather than an "address".  Any "session" should be controlled by a single Module.  Most hardware is designed to only support one "session", so there you should have a single Module controlling that hardware, but databases are designed to support multiple sessions.

I've seen, more than once, programmers take a multi-session thing and immediately throw it into some kind of singleton so they can "share" a single reference, thinking this is of some kind of value.  At best this does nothing, and at worst it introduces a source of race conditions.

[FabiolaDelaCueva]

---

It sounds like I do not have a correct understanding of the use of DQMH modules. I am not trying to add functionality to a database, I am trying to add functionality to my application which allows me to communicate with a database. My modules have high level functionality while it sounds like what you are talking about is more low level functionality. Correct me if I am wrong.

---

You do have a good understanding of DQMH modules. They have high level functionality.

To answer your original question, figure out what is the generic part of your module, implement that and make it a DQMH template module (so it gets listed with singleton and cloneable) and then make DQMH modules based on those templates and make them more specific to each application.

This also applies to high level headless DQMH modules.

From the top of my head and without much thought... A common thing in a lot of database apps is the table display of the queries result.

Your module could have a query request that expects a string and broadcasts a table and/or displays it on a table on the DQMH front panel.

I am a judge for FTC at the FIRST Robotics World Championships, I have to run... Done with lunch, I will expand on this later.