Class design choices. class with static methods only and nested structs?

[thokra]

Hi folks!

I'm working on an Wavefront OBJ loader written entirely in C++ and try to figure out the best design choices for the involved classes.

Specifically, I'm currently thinking about the following designs:

1) nested structs in a class. consider the following:

class GeometricObject
{

public:
  enum polygon_type
  {
    TRIANGLE,
    QUAD
  };

  struct vector
  {
    float x, y, z;
  };

  struct face
  {
	polygon_type polyType;
	std::vector<int> vertexIndices;
	std::vector<int> normalIndices;
  };
};

What this class obviously does is define some data structures to describe points/vectors in 3D space and faces made of vertices and corresponding vertex normals. In addition there is a polygon type, either quads or triangles can be stored.

What do you think about the nested structs and the members of the structs? Is it wise to avoid a seperate class to describe simple floating point values, if their mere function is to bundle three float values and not provide any functionality? Since the number of vertex and normal indices can vary, is the overhead of choosing a std::vector justified in the struct face?

2) A class holding only static methods and no data meant as a conversion class.

My loader is supported by a class StringProcessor which handles conversion of strings to numbers and vice versa, trimming a.s.o., to avoid the necessity to use a bigger library like Boost just because I need some helper functions (have you seen the dependencies of boost::lexical_cast?!).

The aim is a class containing only static methods and templates designed for specific tasks. Copying and explicit construction are disabled. I've read one should avoid defining a class if there is no data and there are no methods to be encapsulated, but simply defining methods on the namespace level seems to break any OOP considerations.

What do you think?

Thank you all!

[jsmith]

Whether you choose to nest the types publicly or keep them separate is purely a matter of taste. There is no functional difference to the programmer, other than that nesting them
means more typing.

I think it is useful to create the vector struct, though I'd be hesitant to name it that, particularly if you plan to move the type out of the class. I can easily see a vector object
having a magnitude() method, operator==, operator!=, etc.

Regarding #2: what you are describing is a namespace with functions in it, and that is
how I would code it (namespace instead of struct). Your concern about the "non-OOP"
nature is the typical response, however OO experts will all agree that a good OO design
does not mean that everything is an object. It is perfectly fine to have free functions.

[thokra]

First of all, thank you for your quick response! I'll leave the class as it is for now. Concerning the struct vector I agree. If you want a full fledged implementation you'll probably implement normalization, operators for copying, scaling, adding, comparison, dot product etc. In the case of the GeometricObject it seems fine, since OpenGL, which the loader is intended to work with, takes most of its geometry data as simple C-arrays which can be composed easily with the struct members.

I'll also follow your advice and define my helper methods on the namespace level. Thaks again!