Creating a Java project without using any objects and just calling static methods on input?

I'm creating a program which takes a document, extracts it, and then moves this into a database. I've done most of this now and I've realised that I haven't made any instances of classes I've made (I have made instances of other thing such as buffered readers and arrays etc). Is this bad? I seem to just have classes which are a collection of related methods which are called statically to manipulate my data (which is stored as a string) until it is then added to a database. How would an experienced programmer go about this if my technique is considered naive or bad form?

What data structures are you using for the classes? Is it just things like String[] ? or do you have something that looks like a strut with public fields in a class?

I only have a class with my delimiters, a class where the broken down document is stored ( which each broken down part as a string) and then two other classes to input the document and search the document for delimiters. That's it really (not looking at the database part)

3 Answers 3

For this particular problem, it's not terrible. What you're doing is basically scripting an import process, which is a fairly straight-forward imperative problem. Java maybe isn't the best tool for that job, but it's fine.

An experienced programmer might create an intermediary data structure to represent the data going into the database to help should that ever come from a different source than the file. They might abstract away the file or database so you can have different import/output targets. But that might also be over-engineering depending on your environment and needs.

The point of object-orientation is not to count the user-defined classes and judge via "more == better".

Instantiating an object is useful if you really do have multiple things in your problem field that have identical behaviour but a distinct identity. You saw how that works with streams: one reads from one source, the next one from another; reading and writing streams are different but closely related, so it makes sense that they both inherit from the same class, etc. Those are all good reasons to use OOP idioms; it is better to write the logic for doing something once and then reuse it, and if the logic is bound up with instance-specific data (e.g. the source file name), then the logical way of bundling them is to create a class out of the data and the methods that work on it.

However, if your problem is so small that you don't repeat anything, i.e. if you really read a couple things from one place, perform one transformation and then write them to another place, there's little use in defining objects and classes to do that when it's really just a list of steps to be performed. (Separating the phases into smaller methods, even if each is called only once, is still a good idea, but that isn't strictly related to OOP - it's a good idea even in non-object languages.)

Briefly, don't beat yourself up about not having created your own class. Once you've met our first problem class where it does make sense to define a class with multiple instances, it becomes easier to judge when this makes sense and when it would just be window dressing for a fundamentally non-dynamic problem solution.