Should an object that totally encapsulates functionality have a "Run" function?

[Jenna Olson]

Hi all-

I've never seen this particular issue addressed, but was wondering if
there's anything to support one way or another. Say I have a class:

class ManipulateData
{
public:
ManipulateData(const char* Path-To-Some-Text-File)
{ ... }

bool Run();
long DataCount();

... etc ...
};

What I'm wondering is if the Run() function is really necessary. If a class
so completely encapsulates a particular type of functionality that under C
it probably would have been written as a single function, with no further
setting of members, is it really necessary or proper to split the start into
both the constructor *and* the Run()? True the Run() returns a bool that
would presumably indicate success, but my thought is that because the bool
only indicates sucess or failure, and in the case failure might be for
multiple reasons, it would be better to put the object in a try/catch and if
the object cannot do what it's supposed to do, throw an exception and caught
by the function that instantiated the object.

I ask because I realize I've written code that says "ManipulateData
md("/tmp/blah.txt"); bool bOK(md.Run());" and it seems ... unnecessary.

Just curious what others thought,

Jenna

 

[Victor Bazarov]

I've never seen this particular issue addressed, but was wondering if
there's anything to support one way or another. Say I have a class:

class ManipulateData
{
public:
ManipulateData(const char* Path-To-Some-Text-File)
{ ... }

bool Run();
long DataCount();

... etc ...
};

What I'm wondering is if the Run() function is really necessary. If a class
so completely encapsulates a particular type of functionality that under C
it probably would have been written as a single function, with no further
setting of members, is it really necessary or proper to split the start into
both the constructor *and* the Run()?

Probably not.

True the Run() returns a bool that
would presumably indicate success, but my thought is that because the bool
only indicates sucess or failure, and in the case failure might be for
multiple reasons, it would be better to put the object in a try/catch and if
the object cannot do what it's supposed to do, throw an exception and caught
by the function that instantiated the object.

I ask because I realize I've written code that says "ManipulateData
md("/tmp/blah.txt"); bool bOK(md.Run());" and it seems ... unnecessary.

It is unnecessary. I think you should only consider doing it if
the file can be changed during the lifetime of your 'ManipulateData'
object and you might want to "re-manipulate" the data. Otherwise,
you could keep the functionality in the constructor and have it set
some internal flag, which you will query later:

ManipulateData md("/tmp/blah.txt");
if (md.isOK())
...

Victor

 

[Alf P. Steinbach]

I've never seen this particular issue addressed, but was wondering if
there's anything to support one way or another. Say I have a class:

class ManipulateData
{
public:
ManipulateData(const char* Path-To-Some-Text-File)
{ ... }

bool Run();
long DataCount();

... etc ...
};

What I'm wondering is if the Run() function is really necessary.

What you really should be wondering about is the dependency of
methods on each other. For example, is a call to DataCount valid
before calling Run, or after a failed call of Run? If not, then
DataCount should probably be a method on an object returned by Run,
enforcing that constraint.

Designing a class so that the order of method calls matter is
generally a bad idea, although in some cases there's no way around
(and there are well-known patterns that address these few cases).

But if Run is the only exposed functionality then it might make
sense to have this method. A functor class is one example, with
operator () playing the rôle of Run. As another example, Run might
be a virtual method.