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?

  • 1
    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?
    – user40980
    Jul 21, 2015 at 13:20
  • 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)
    – Dan Savage
    Jul 21, 2015 at 13:29
  • Real Programmers can write FORTRAN in any language! (pbm.com/~lindahl/real.programmers.html)
    – Peter Wone
    Jan 28, 2016 at 4:17

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.

  • Given his comment there are actually half a dozen classes created.
    – user40980
    Jul 21, 2015 at 13:30

You can't make a Java program without objects. Everything you instantiate is an object. The static methods you call are called on instances of the Class object of their class.

But yes, it's generally a bad idea to use a single big class with just static methods. It gets terribly unwieldy really quickly.
Rather than avoid the issue of learning object orientation, making things worse for you in the future as your programs get bigger, make the effort now to wrap your head around it now that your creations are still small and easy to envision in your head.
Get some decent books, get someone to give you instruction preferably, don't think you can forever avoid the issue or solve it just by asking questions on some forum or watching youtube videos.

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.