What do you do when you notice that an app has a lot of classes, but the classes are not really intantiable objects but rather a grouping of common functions?
Example:
Class Point
{
calculatePoints(something) {}
calculatePointsAnotherWay(something) {}
}
If it's allowed by the language, I'd make them free (nonmember) functions. If they don't belong in a class, they belong outside it.
Put them in a separate namespace if you want to group them.
In C# or Java, this isn't possible, of course, so I'd probably put them in a separate static class.
From what little experience I've had, and working from the limited information in the question, it seems that there is nothing you should do in this case. It is perfectly legitimate to have a static object (non-instantiable) that contains only common functions and subroutines.
Make the methods static and and the class too (if you can), rename the classes if misnamed (Point is a very bad name for that class, for example), and then move or regroup the methods if it's appropriate.
My guess is that your concern is with the names of the classes though. If there are a lot of these classes around then need to be succinctly named and should abide by the Single Responsiblity Principle instead of just being generic method groupings.
From what I've read, grouping related functions is apparently a valid use of a class in the OOP world.
I'd look at the functions to see how they are using instantiable objects. If a function:
then that function is a candidate for becoming a method on the class of its argument. This kind of coding is sometimes a clue that the programmer who created the original type or the programmer who wrote the "external" function (or both) may still be thinking in imperative/procedural style, rather than OO style.
Probably the code was written in a procedural style, which is not bad in itself. I would first try to make sure that all the methods are relatively small, not more than 50 lines. If there are large methods I'd split them to smaller methods. This way I would ensure I have good procedural design. Again, procedural programming is not a bad thing if done right.
Then I'll look for methods that have more than 5 parameters and try to create classes based on the parameters. Then I would do what I call C to C++ transition: bundle together these "parameter" classes with the methods that operate on them, so the OO style will start to emerge.
As you've titled the question as OO. I guess you want to know how to structure that as OO code.
Currently, as you describe it, the author has written procedural code, but just happens to have used an object oriented language.
If you've got code like this all over the place and want it in a more pure OO form, you need to do some hard studying on what OO is, and how to use its features in your design.
This is more than I could fit into an answer here. I think a book or 10 for a bit of reading ought to get you on the right track.
This one might be a good start: http://www.amazon.com/Object-Oriented-Modeling-Design-James-Rumbaugh/dp/0136298419
It sounds like you could name the class PointUtilities, and make the functions static.
Well, it seems that the usual way in frameworks (e.g. java.lang.Math in Java API, System.Math in .NET Framework Class Library) is to group these methods in a static/final/sealed class and make the methods statis/final/sealed.
And yes - this is a procedural approach.
On the other hand, if you read tons of books (just kidding), probably you could make it more object-oriented...
In my opinion, I have nothing against this opinion where it is appropriate - maybe it's easier to finally admit that the world is not purely object-oriented. :)