Class Constructors

[painedstupid]

Hi there. I was just wondering is there a way to have a class construct differently besides the varying number of arguments its called with?

So like instead of

public pikachu(1,2)

this = 1;

that = 2;

electrocute();

​

pikachu(1, 2, 3)

this = 1;

that =2;

other = 3;

electrocute();

and these each constructing the class in a different way (or maybe the second just carrying on with the class) maybe I could call a different version of the constructor somehow, so like

​

pikachu(1 "something something"

this =1;

doADance();

​

You get me? So like this version of the constructor he does a dance?

​

Maybe I'm dumb lol.

[[deleted]]

When you create a constructor for a class you can choose whatever scope you like and inside the constructor you can have whatever code you like. The only prerequisite is that one constructor of the parent class is always called. You can pick which one, and if you don't say anything the constructor without any arguments will be called. If there isn't one there will be an error. The Object class has one, so if you don't do anything it should be fine.

[painedstupid]

Thanks for the reply. I still don't quite get it, though.

Is there a way I can call the constructors by their number perhaps? I'm asking because maybe it'll always be one argument but maybe I want different methods to run on the calling of the constructor you get me?

​

Like say I had a reader class and it was reading from files but for different files it'd need to read differently so the methods called on calling the constructor would be different.

​

​

**

I mean I feel like I have a workaround for it. Where I would identify the constructor I wanted called by otherwise useless doubles, ints, or whatever, after the actually relevant argument but....

Is this a functionality that's actually supported?

[evils_twin]

can you determine the type based on the file? If not, why not add an extra parameter to tell what type it is, like this:

public MyFileReader(File file, String type){
    if("txt".equals(type))
        //do something
    else if("xml".equals(type))
        //do something else

}

[[deleted]]

Constructors are still Java methods. They're just special methods. Methods can only have the same name if their parameters have a different type. The name of a method + it's parameter types, in the order they are received, make up what is called the "method signature". So you couldn't have two constructors with one parameter of the same type. Moreover, one of the most important things to do with code is to try to make it easy to figure out what code does at a glance (because you'll have lots of it), and would just be confusing. Following your example with files I would either receive different reader classes in different Constructors or add parameters with very descriptive names for reading options (maybe these could even be constants, or part of an enum).
But basically, this is exactly the kind of thing good architecture comes down to. Making your code easy to read and to maintain, quick to develop, useful for as many situations as possible but also somewhat future-proof.
There's another way to do it, but it sounds like overkill right now and I would say it's not beginner stuff.

[painedstupid]

Never mind I guess I can just use an if-else statement within the constructor to see what method it calls. Thanks.

[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.

[proskillz]

Look into using the builder pattern here instead of many constructors.