A programming style question for you experts...

[scott_hollen]

Hello all --

I come from a functional programming background to trying to do a project in Qt/C++ -- 28 years worth of that background -- with the closest to OO being years of Ada and PL/SQL and using them in a simulated OO manner, so I'm curious about you how you experts out there approach your coding...Trying to learn Qt/C++/OO in a short time frame is proving to be, um, adventurous...

With PL/SQL you can encapsulate processing and data within procedural specs and bodies in a similar nature to classes...I'm used to main programs calling packages which do a LOT of the work and very little of the work themselves, but all the examples that I've been thru tend to split processing...For example:

I need to create a DB login screen and when the user logs in I need to verify credentials, and notify them if they can't log in...In something like PL/SQL all that processing, error and exception handling is hidden in the package -- where do ya'll commonly put that processing in Qt? I created a database management class to manage opening the DB, creating the tables (if it doesn't exist), and I'm basically wanting to put all the SQL processing there, but I'm interested to know where you put your error handling for that? In the mainmenu.cpp that accesses that class, or the class itself? Logically and stylistically, what do ya'll recommend? Generate error dialogs from the data management class or mainmenu? Does it really matter?


scott

[franz]

It is the GUI layer that asks for input and provides error dialogs to the outside world. Any worker objects should just try to work with the input and report failure to their gui layer caller. The database class should not be involved with GUI issues (neither input nor output). The main menu could be the place, although in a Qt based project the calling widget (when working with menus, probably the main window) should do user interaction.

[scott_hollen]

Huh -- lost my follow-up post...

Thanks for the reply -- you make the exact argument I was making with my co-worker on this very subject who actually has more experience with this style of programming...I've been in a world of Oracle forms for a number of years that has embedded application processing and it's a BEAR to deal with...Finally, the vendor is extracting that out into APIs, separating the user interface from the actual processing, which makes a helluva lot more sense...My co-worker was arguing that *anything* related to the DB transaction/processing should be encapsulated together...

thanks again!


scott

[squidge]

Your should refer your co-worker to the Model View Controller pattern.

http://en.wikipedia.org/wiki/Model%E...0%93Controller

After all, in a future version of the project, there could be multiple views, so the data must be kept completely seperate from it.