Request help on interface design for data classes

Discussion in 'C++' started by Jayden Shui, Dec 8, 2011.

  1. Jayden Shui

    Jayden Shui Guest

    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
    Jayden Shui, Dec 8, 2011
    #1
    1. Advertising

  2. 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 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!


    You're approaching your problem in the wrong way. Classes are designed
    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 do 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* that
    class, not in a vacuum.

    V
    --
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Dec 8, 2011
    #2
    1. Advertising

  3. Jayden Shui

    Jayden Shui Guest

    On Dec 8, 12:09 pm, Victor Bazarov <> 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 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!

    >
    > You're approaching your problem in the wrong way.  Classes are designed
    > 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 do 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* that
    > class, not in a vacuum.
    >
    > V
    > --
    > I do not respond to top-posted replies, please don't ask


    Thank you so much. I'd like the users to use the class Problem to
    define their problems (background, sources, receivers, and so on).
    Would you please give me an example of hint to how to define such
    classes? I really appreciate it.

    Best regards,

    Jayden
    Jayden Shui, Dec 8, 2011
    #3
  4. On 12/8/2011 12:36 PM, Jayden Shui wrote:
    > On Dec 8, 12:09 pm, Victor Bazarov<> 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 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!

    >>
    >> You're approaching your problem in the wrong way. Classes are designed
    >> 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 do 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* that
    >> 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 useful
    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++ books
    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
    Victor Bazarov, Dec 8, 2011
    #4
  5. Jayden Shui

    Jorgen Grahn Guest

    On Thu, 2011-12-08, Victor Bazarov wrote:
    > On 12/8/2011 12:36 PM, 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 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.

    ....

    > 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".


    Perhaps the name "Problem" is the problem. I can imagine a design
    where "Problem" gets renamed "Sound Landscape" or "Environment for
    audio experiment" or "Room", and just describes the (constant) setting
    and its physics. Then the "Experiment" could be another object

    Experiment(landscape, speed_metal_through_two_speakers);

    Perhaps useful if you need to do 1000 isolated experiments in the same
    room. Not so useful if you do the same experiment in 1000 different
    rooms.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Dec 8, 2011
    #5
  6. Jayden Shui

    Jayden Shui Guest

    On Dec 8, 1:38 pm, Victor Bazarov <> wrote:
    > On 12/8/2011 12:36 PM, Jayden Shui wrote:
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > > On Dec 8, 12:09 pm, Victor Bazarov<>  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 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!

    >
    > >> You're approaching your problem in the wrong way.  Classes are designed
    > >> 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 do 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* that
    > >> 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 useful
    > 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++ books
    > 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
    Jayden Shui, Dec 8, 2011
    #6
  7. Jayden Shui

    Jayden Shui Guest

    On Dec 8, 3:12 pm, Jorgen Grahn <> wrote:
    > On Thu, 2011-12-08, Victor Bazarov wrote:
    > > On 12/8/2011 12:36 PM, 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 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.

    >
    > ...
    >
    > > 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".

    >
    > Perhaps the name "Problem" is the problem.  I can imagine a design
    > where "Problem" gets renamed "Sound Landscape" or "Environment for
    > audio experiment" or "Room", and just describes the (constant) setting
    > and its physics.  Then the "Experiment" could be another object
    >
    >   Experiment(landscape, speed_metal_through_two_speakers);
    >
    > Perhaps useful if you need to do 1000 isolated experiments in the same
    > room. Not so useful if you do the same experiment in 1000 different
    > rooms.
    >
    > /Jorgen
    >
    > --
    >   // Jorgen Grahn <grahn@  Oo  o.   .     .
    > \X/     snipabacken.se>   O  o   .


    Yes, choosing another name may be better. How do you think of the ways
    to access data or vectors in a class? Thanks.
    Jayden Shui, Dec 8, 2011
    #7
  8. On 12/8/2011 3:49 PM, Jayden Shui wrote:
    > [..]
    > 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?


    What logic?

    V
    --
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Dec 8, 2011
    #8
  9. Jayden Shui

    Christopher Guest

    On Dec 8, 10:28 am, Jayden Shui <> 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.
    Christopher, Dec 8, 2011
    #9
  10. Jayden Shui

    Jorgen Grahn Guest

    On Thu, 2011-12-08, Jayden Shui wrote:
    > On Dec 8, 3:12 pm, Jorgen Grahn <> wrote:
    >> On Thu, 2011-12-08, Victor Bazarov wrote:
    >> > On 12/8/2011 12:36 PM, 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 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.

    >>
    >> ...
    >>
    >> > 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".

    >>
    >> Perhaps the name "Problem" is the problem.  I can imagine a design
    >> where "Problem" gets renamed "Sound Landscape" or "Environment for
    >> audio experiment" or "Room", and just describes the (constant) setting
    >> and its physics.  Then the "Experiment" could be another object
    >>
    >>   Experiment(landscape, speed_metal_through_two_speakers);
    >>
    >> Perhaps useful if you need to do 1000 isolated experiments in the same
    >> room. Not so useful if you do the same experiment in 1000 different
    >> rooms.

    ....

    > Yes, choosing another name may be better. How do you think of the ways
    > to access data or vectors in a class? Thanks.


    I did not just suggest changing the name, but to also add
    "intelligence" or "behavior" to it. If a Landscape contains the
    physics, noone outside it needs to know about data or vectors (or
    higher abstractions like walls in different materials).

    But I don't know anything about the area (sound physics and the maths
    involved). I think you need that to make the right choice.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Dec 9, 2011
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Brian Birtle
    Replies:
    2
    Views:
    2,017
    John Saunders
    Oct 16, 2003
  2. Thomas Fjellstrom

    Data Storage, Interface and Design

    Thomas Fjellstrom, Jul 1, 2006, in forum: C++
    Replies:
    4
    Views:
    313
    Thomas Fjellstrom
    Jul 2, 2006
  3. Andrew
    Replies:
    1
    Views:
    346
    James Kanze
    Oct 20, 2007
  4. John Carter
    Replies:
    1
    Views:
    127
  5. Trevoke
    Replies:
    10
    Views:
    200
    Brian Candler
    Jul 22, 2009
Loading...

Share This Page