Re: Request help on interface design for data classes
On Dec 8, 1:38 pm, Victor Bazarov <v.baza...@comcast.invalid> wrote:
On 12/8/2011 12:36 PM, Jayden Shui wrote:
On Dec 8, 12:09 pm, Victor Bazarov<v.baza...@comcast.invalid> wrote:
On 12/8/2011 11:28 AM, Jayden Shui wrote:
I have classes which primarily collect and provide data information.
For example, the class Problem is used to define a physical problem t=
o
be modeled. The problem has background (such as air), sources (such a=
s
speakers at some positions), receivers (such as microphones at some
positions), and objects (such as walls, tables and chairs). I'd like
to compute the sound heard or recorded at the receivers.
My questions is how to build a good code for the class Problem? I hav=
e
a number of similar classes. I figured out several versions. Please
help me compare, give me your comments and suggestion, and your bette=
r
design for the class Problem?
// -------------- Version 1: detail all the interface functions.
----------------
class Problem
{
public:
void SetBackground();
Background const& GeBackground() const;
void AddSource(Souce const& source);
std::vector<Source> const& GetSourceVector(=
) const;
private:
Background mBg;
std::vector<Source> mSrcVector;
};
// --------- Version 2: use macro to hide the details and code is
small --------------
#define ACCESSOR(Type, Name) ...
#define VECTOR_ACCESSOR(Type, Name) ...
class Problem
{
ACCESSOR(Background, Background);
VECTOR_ACCESSOR(Source, Source);
};
// --------- Version 3: make the attribute reference public for users
------------
class Problem
{
public:
Background& BackgroundR();
std::vector<Source>& SourceVectorR();
private:
Background mBg;
std::vector<Source> mSrcVector;
};
I appreciate your help!
You're approaching your problem in the wrong way. Classes are desig=
ned
by what they do first (interfaces), and only then (based on what they
do) what they contain (implementation).
What does your "Problem" do? What do you expect to ask it? How d=
o you
initialize it? Does it keep a state at all?
The design of a class has to be done based on the code that *uses* tha=
t
class, not in a vacuum.
V
--
I do not respond to top-posted replies, please don't ask
Thank you so much.
Think nothing of it.
> I'd like the users to use the class Problem to
define their problems (background, sources, receivers, and so on).
"Define their problems" is too nebulous to have the meaning clear enough
to start designing a class for it. Be specific. You want the users =
of
that class to do what with a problem? Give it "a background" and
possibly get the background back from it? Then your "problem" is but a
mere storage for "a background" (whatever that is). Doesn't seem usefu=
l
much, to be honest. What would a "Problem" do beyond *storing* the
values for "a background", "sources" and "receivers"? A "Problem"
usually begs to be "solved". Who is going to "solve" it? What is a
"Problem" to do when it has all the information? Does it solve itself?
Does it get passed through some kind of "solver" external to the
problem? Can a "Problem" be solved differently based on some kind of
"precision" or "method" that you could supply to the "Problem"s "solve"
method?
Think about it a bit more.
Would you please give me an example of hint to how to define such
classes? I really appreciate it.
Get a good book on designing OO software. Such books have plenty of
examples. Even a simple C++ book would probably have some examples of
classes and their interfaces and implementations. Except that C++ book=
s
don't usually concentrate on doing the design the right way,
unfortunately. Try "Advanced C++" by James Coplien.
V
--
I do not respond to top-posted replies, please don't ask
Thank you. I have another class called Solver to solve the problem.
Basically in my software, the two classes: Problem and Solver, are of
the high-level. The class Problem used other lower-level classes such
as Background, Source, and so on. Background, Sources use other lower
classes such as points, directions, and so on. Similar for solver. Do
you feel this logic follow the OOD priciples?
Best regards,
Jayden