I am writing a C++ OpenCV-based computer vision program. The basic idea of the program could be described as follows:
-
Read an image from a camera.
-
Do some magic to the image.
-
Display the transformed image.
The implementation of the core logic of the program (step 2) falls into a sequential calling of OpenCV functions for image processing. It is something about 50 function calls. Some temporary image objects are created to store intermediate results, but, apart from that, no additional entities are created. The functions from step 2 are used only once.
I am confused about organising this type of code (which feels more like a script). I used to create several classes for each logical step of the image processing. Say, here I could create 3 classes like ImagePreprocessor
, ImageProcessor
, and ImagePostprocessor
, and split abovementioned 50 OpenCV calls and temorary images correspondingly between them. But it doesn't feel like a resonable OOP design. The classes would have no custom constructor, no other classes would be inhereted from them, because the classes would be nothing more than a way to sort the function calls, and not a part of some OOP design pattern.
The main()
function would still just create a single object of each class and call thier methods consequently:
image_preprocessor.do_magic(img);
image_processor.do_magic(img);
image_postprocessor.do_magic(img);
Which is, to my impression, essentially the same thing as callling 50 OpenCV functions one by one.
I start to question whether this type of code requiers an OOP design at all. After all, I can simply provide a function do_magic()
, or three functions preprocess()
, process()
, and postprocess()
. But, this approach doesn't feel like a good practice as well: it is still just a pile of function calls, separated into a different function.
I wonder, are there some common practices to organise this script-like kind of code? And what would be the way if this code is a part of a large OOP system?
Aucun commentaire:
Enregistrer un commentaire