Sign in to follow this  
BBB

Mdoule interface design problem

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

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