Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
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
add comment

1 Answer 1

up vote 8 down vote accepted

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.

share|improve this answer
    
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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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