Converting C++ Procedural Program Into Object Oriented

Question

I’ve been told to convert a procedural C++ program into an object-oriented one, using the principles of polymorphism, encapsulation and inheritance.

The standard C++ program accepts data values and filter values from the user. It then multiplies these values together using a simple algorithm and prints the output to the screen. The standard program is shown below.

I have made a start by deciding to use a class for 'TheFilter' and a class for 'TheData' each with their own 'enterdata()', 'displaydata()' and constructor member functions.

The problem I am having is with part of the criteria set, "main() should do no more than create the first object". I am having difficulty getting my head around this as all examples of OOP code I have ever seen generate objects within main().

The only current solution I could come up with to obey this is to create a 3rd class (FilteredData - see below) which would instantiate the other classes objects 'OriginalData', 'Filter' and 'FilteredData' upon being instantiated itself. However this is troubling me as would it not take away from the concept of encapsulation as it would result in having a class with members which are other classes objects?

If anyone has any suggestions at all into how this could be avoided and best obey the principles of encapsulation I would be very grateful!

I hate to admit defeat, but I’ve never programmed using an object-oriented approach and I’ve only been studying C++ for a couple of months. Please help!

#include <iostream>
using namespace std;

class TheData 
{
public:
    TheData(double* = 0, unsigned long = 0, bool = false); //constructor function
    ~TheData();

    void EnterData(TheData& OriginalData);              
    void DisplayData(TheData OriginalData, TheData FilteredData) const;


private:
    double* Values;                     
    unsigned long Length;                       
    bool Valid;

}

class TheFilter
{
public:
    TheFilter(double* = 0, unsigned long = 0, bool = false); //constructor function
    ~TheFilter();

    void EnterData(TheData& OriginalData);              
    void DisplayData(TheData OriginalData, TheData FilteredData) const;
    int ApplyFilter();

private:
    double* Values;                     
    unsigned long Length;                       
    bool Valid;

}

class 
{
public:
    FilteredData();    // constructor function that somehow instantiates an object for the filter and the data???
    void DisplayData();
private:
    TheData data
    TheFilter filter
    double * filteredData
}


int main()
{
    FilteredData Object1;
}  

Answer 1

The problem I am having is with part of the criteria set, "main() should do no more than create the first object", I am having difficulty getting my head around this as all examples of OOP code I have ever seen generate objects within main(). The only current solution I could come up with to obey this is to create a 3rd class (FilteredData - see below) which would instantiate the other classes objects 'OriginalData', 'Filter' and 'FilteredData' upon being instantiated itself. However this is troubling me as would it not take away from the concept of encapsulation as it would result in having a class with members which are other classes objects?

The criterion you cite is potentially problematic, but not necessarily for the reason you think. As a general rule, a constructor should not do work beyond initializing the object on which it is invoked. If main() cannot invoke at least one method on the object after initializing it then that requires the constructor to exhibit additional behavior (i.e. triggering the main work of the program), which is poor form. Even if all that is needed is for the object to be registered in some way with a GUI framework, that's still work that the constructor should not be responsible for performing.

On the other hand, there is nothing at all inherently wrong with class members that are objects, pointers or references to objects, or containers for objects. That's in fact extremely common, and good form often requires it. It does not inherently compromise encapsulation. In fact, it can do the opposite by affording even more encapsulation than otherwise there would be.

Overall, you have reached the correct conclusion that you require a class representing the overall program, with main() doing nothing but instantiating that class and setting it to work. That's a fairly common pattern. If the details you've come up with don't sit well with you, however, then there may be good reason for that. I'm inclined to agree that a class representing a composition of data and filter -- though entirely plausible in itself -- doesn't seem the correct representation for the overall program, or its main window, or whatever it is that you actually need.