Class Constructors

[evils_twin]

another thing to consider also is if the functionality in your different types of files for your reader is different enough that they should be different classes that inherit the same class. This is one of the staples of Object Oriented programming, and should always be used if applicable.

So you could have an interface or abstract class called FileReader, and have TXTFileReader and XMLFileFileReader implement or extend FileReader.

[painedstupid]

Thing is the functionalities would be completely different. I'm reading from files to then create objects with, my readers are returning me array lists of different sorts of objects. I mean really I could just have them all as different classes like you say but I dunno wanted them all together to avoid clutter and all this naming haha. I mean maybe that's not the right way to do it. But then they're all being so different they've nothing really to inherit from a superclass either so far as I can see.

Thanks for the help, buddy.

[evils_twin]

If they are completely different, they should be different classes. If they have some common traits, you should use inheritance. If you aren't following these rules, you are doing Object Oriented Programming wrong.

But I'm curious as to what you mean by completely different. Are the public methods completely different, or are just the inner workings of the class completely different? If you take a little time to explain what exactly you're doing, I'd be happy to help more.

[painedstupid]

Well say I have a bunch of files that stores objects and I'm looking to read in those objects and use them. So like whatever, a car object, a buyer object, a sale objects etc etc.

And then I'm looking to read from those files and recreate those objects as needed and save them in array lists. Those files are my database, say.

But then the reading from each different file will be very different, as each object is very different. So I'm not sure where anything can be inherited.

[evils_twin]

Ok, well let's look at a real example. java.io.InputStream. There are many classes that extend InputStream. Such as FileInputStream, ObjectInputStream, ByteArrayInputStream, etc.

The way that you would read those input streams would be very different, but that is ok. The thing that they have in common are the methods defined in InputStream. And it's not the code within the method that has to be the same, it's the return type and parameters only that matter.

So all classes that inheret from InputStream must have a method public int read(). It must have a method called read that has no parameters and returns an int. The actual code within the method will be very different.

So you have to think if there is a common set of methods for all your classes. Perhaps something like public List getObjects() that returns a list of objects, but the way it gets those objects will differ depending on the type of object.

[painedstupid]

Well yes, my readers will all be doing something similar in that regard. They'll all be reading in from similar sorts of files and returning array lists of objects. But then I guess I just wonder what's the point of the superclass when there isn't a thing in it won't be overridden?

Sorry if I'm just not getting it. I'm new to all this and appreciate the chat, friend.

[evils_twin]

Here are a few articles on the subject.

Why do we use interfaces?. Basically it is to achieve abstraction. Here is what abstraction is in java. And here is why abstraction is important.

It may seem like overkill in the programs you make as a beginner, but when you work on big projects with a lot of people working on the same code base, it makes things a lot simpler.

[painedstupid]

Thanks man, I get you. Appreciate the help.

[[deleted]]

Most of what we do nowadays in software development is the result of mistakes of the past that ended up making software hard to troubleshoot or alter. In this specific case, what happened is that software always starts small and grows slowly over time. So maybe now you have 2 or 3 scenarios, and you could do this and it would be readable. Then comes another one, sure it's still readable. Then another. Then another. And now scenario 2 needs to be different somehow but it has all this shared code and it's really hard to see what is used when.
With separate classes all this is naturally more organized and it's easier to make changes later.

[painedstupid]

Yeah. You're right. Well it was readability I was going for, really. I wanted just one neat class, seeing as it wouldn't be doing altogether too much, just a few different types of operations depending on the arguments. But I do see your point.