By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,473 Members | 3,229 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,473 IT Pros & Developers. It's quick & easy.

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

P: n/a
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
Jul 19 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
"Jenna Olson" <wa*******@comcast.net> wrote...
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
Jul 19 '05 #2

P: n/a
On Fri, 25 Jul 2003 12:31:18 GMT, "Jenna Olson" <wa*******@comcast.net> wrote:
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.

Jul 19 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.