Re: Request help on interface design for data classes
On Dec 8, 10:28 am, Jayden Shui <jayden.s...@gmail.com> wrote:
Hi All,
I have classes which primarily collect and provide data information.
For example, the class Problem is used to define a physical problem to
be modeled. The problem has background (such as air), sources (such as
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 have
a number of similar classes. I figured out several versions. Please
help me compare, give me your comments and suggestion, and your better
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!
Jayden
The "problem" with your design is that you are not describing a
"problem" at all, nor a solution.
What you are desribing is a "Domain".
That isn't a bad thing. You always start off by examining the domain
of the problem and creating data structures for it. The next step is
to actually identify what the "problem" is and what algorithms could
be used to "solve" it.
If you are going to have mutliple problems and solutions...or in other
words, functions that act on the data, start off by listing those
functions and what they do, then see what they have in common if
anything.
Don't worry about containing everythin is the domain in one data
structure. When you get to listing things you might do with the data,
you might see that you don't need everything everytime.
For instance, maybe the only requirement of my software is to email an
grand total for the day to the manager.
I can simply run "orders" through a calculator and keep track of the
totals. I wouldn't need to be concerned with people, names, addresses,
phone numbers, states, zip codes, ethninticities, time of day, browser
they used, etc. I just want to know how much money I made.
Without listing some real requirements for your software, no one is
really going to be able to assist you with design.
Start with requirements, then define a domain, then define algorithms.