Other than vertices, edges, faces and meshes, my geometry processing project/application has only about half a dozen other entities such as curves on surfaces. However the majority of my code is dedicated to geometry processing. Being a naive programmer when I started this project, I implemented the various geometry processing algorithms as methods of the few classes that I had. As a result, some of my classes are now very large because they implement geometry processing algorithms (and therefore span up to 5 *.cpp files) -- very bad. In some cases I also implemented the algorithms as classes in their own rights. As such I now have classes that are not really entities. I now have a problem with this because I now believe that classes should be instantiable entities, and their methods the things that they do. Yet following this rule has led to large files. At the same time deviating from it has led to classes that do not make sense as instantiable entities e.g. a Geodesic class.

Anyway I'm planning a redesign of this project and I'd appreciate advise on how to deign my classes. One of the options I've considered is to implement each algorithms as a collection of methods in a namespace. However as namespaces do not have instance variables, there will be lots of argument passing between the methods -- again not very nice.

  • Could also implement the facade design pattern when each package/namespace have to interact with each other, this way you can simplify the actual calls through an other layer of abstraction – JF Dion Aug 12 '11 at 12:38

I find that even with algorithm-centric problems, you can still find ways to separate responsibilities into separate classes. You might be a little bit too rigid in your thinking of what should be an object. If I had an algorithm I might have classes like FooCalculator and BarAccumulator and MyAlgorithmOrchestrator. As far as I'm concerned those are perfectly valid "instantiable entities". Just because they might not make sense as physical objects doesn't mean they don't make sense as algorithmic objects.

  • 1
    So I was being a purist then :) .Gotcha, OOP need not mirror the real world exactly. – Olumide Aug 12 '11 at 11:56
  • 1
    Exactly. :-) Good luck. – RationalGeek Aug 12 '11 at 12:14

As a result, some of my classes are now very large because they implement geometry processing algorithms (and therefore span up to 5 *.cpp files)

If it's C++, then you have the ability to directly implement free-standing functions like bevel, extrude, decimate, subdivide, etc.

  • Oh much thanks for the syntax highlighting edit! That looks way nicer. – user204677 Jan 30 '18 at 0:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.