Sign in to follow this  

Mdoule interface design problem

This topic is 4820 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a graphics module, and in the current OGL implementation of it i use STL to store scenes, layers, polygons et.c. However i want the interface to be pure C++ without dependecies of things like STL and GFX vertex buffers:

// graphics interface

class Ipolygon
 {
  public:
  VIFRV m_rotate_poly(Matrix *a_matrix) { }
  // et.c.
 };

class Igraphics
 {
  public:
  VIFRV m_add_poly(Polygon_blueprint *a_poly_blueprint) { }

  enum {m_max_num_polys = 50};
  SUID m_num_polys;
  Ipolygon *m_polys[m_max_num_polys];
  // ...
 };

// Lame implementation

class Lame_polygon : public Ipolygon
 {
  public:
  VIFRV m_rotate_poly(Matrix *a_matrix);
  // et.c.
 };

class Lame_graphics : public Igraphics
 {
  protected:
  vector<Lame_polygon>::iterator m_poly_i;
  vector<Lame_polygon> m_poly_vector;
  public:
  VIFRV m_add_poly(Polygon_blueprint *a_poly_blueprint)
   {
    Lame_polygon new_poly(*a_poly_blueprint);
    m_poly_vector.push_back(new_poly);
    // et.c.
   }
 };


Now say that i want to mess with a polygon in the graphics module through the Ipolygon interface. What im doing right now is using what i call a bridge:

VIFRV Lame_graphics::m_rotate_poly(Matrix *a_matrix, SUID a_poly_id)
 {
  m_poly_i = m_poly_vector.begin() + a_poly_id;
  m_poly_i->m_rotate_poly(a_matrix);
 }

This has 2 drawbacks as i see it: #1: It is ugly #2: There is a small overhead cost, and this becomes a problem if the function is used alot. Now the question is: is this the right way to go or am i doing it incorrectly?

Share this post


Link to post
Share on other sites
A Bridge can remove all implementation details from the interface. I don't think there is a cleaner way in C++.

Regarding the "ugliness": Consider that you have not created ugliness, you have moved it from the interface to the implementation. An ugly implementation is preferred to an ugly interface, though there is a break-even point. That's why I rarely use the Bridge pattern to hide implementation details -- it's rarely worth it.

Share this post


Link to post
Share on other sites
I didn't say the Bridge pattern is bad -- just that in some cases the solution can be worse than the problem. In your case, I see three choices:

1. Allow implementation details in the interface.
2. Hide individual members behind references.
3. Hide all members behind a single reference (as in the Bridge pattern).

Share this post


Link to post
Share on other sites
Quote:
Original post by JohnBolton
I didn't say the Bridge pattern is bad -- just that in some cases the solution can be worse than the problem. In your case, I see three choices:

1. Allow implementation details in the interface.
2. Hide individual members behind references.
3. Hide all members behind a single reference (as in the Bridge pattern).


Okay, but then i think ill go for #3. But i don't fully
understand what you mean with #2, isn't that exactly like #3?

Share this post


Link to post
Share on other sites
Quote:
Original post by BBB
But i don't fully understand what you mean with #2, isn't that exactly like #3?


#1:
class Foo
{
Bar x;
Baz y;
};
#2:
class Bar;
class Baz;
class Foo
{
Bar * x;
Baz * y;
};
#3:
class Foo
{
class Impl;
Impl *pImpl;
};
class Foo::Impl
{
Bar x;
Baz y;
};

Share this post


Link to post
Share on other sites

This topic is 4820 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this