The Big Programming Thread - Page 688

Database.Media.add<Media>(newMusic);

On December 06 2015 04:52 travis wrote:
Thanks eddie, I needed to type cast it that makes sense

the actual syntax was Database.Media.add((Media(newMusic); though

Media newMovie = new Movies(...);
Database.Media.add(newMovie);
Media newMusic = new Music(...);
Daatabase.Media.add(newMusic);

class A{}
class B extends A{}

...

ArrayList<A> l = new ArrayList<>();
B b = new B();        
l.add(b);

class A{}
class B extends A{}

...

ArrayList<A> l = new ArrayList<>();
B b = new B();        
l.add(b);

On December 06 2015 05:18 WolfintheSheep wrote:

Show nested quote +

On December 06 2015 05:13 Blitzkrieg0 wrote:

On December 06 2015 05:09 WolfintheSheep wrote:

On December 06 2015 04:36 Acrofales wrote:

On December 06 2015 04:25 WolfintheSheep wrote:
It's still not a bad idea to use setters. Really, the entire point of having getters and setters is to control how values go in and out of the class, so you only have to look in one place if things need to change or if things go wrong.

Realistically, for smaller projects, you don't need them because you know roughly what everything is going to do. Eventually, though, you'll come to situations where you're not in control of everything, and the scope of your project extends beyond your initial expectations, so it's good to have the framework in place so you don't have to do major code rewrites every time.

(Of course, C# is so much nicer for getters and setters..."public string Word { get; set; }"...)

Yeah sure. I still prefer final and setting them directly in the constructor It just better captures what those variables are all about imho. Of course, you have to think about your project first. For instance if you store "age" in a variable, then you'd better have a way to change that age every year. However, if you store "birthdate", you can just compute the age, and birthdate is immutable.

You'd also better be bloody sure you know at construction time what the value of those variables is, otherwise birthdate will be 0 (or null depending on long or object storage) forever. But if those are requirements, a final variable is great (and by definition doesn't need a setter).

Birth date is a great example, because imagine what happens with data entry mistakes, or "faked" data . Nothing wrong with final variables, but the requirements are more than just "I know this will only be set once from now until forever", but also "I can guarantee that the first time it's set will be 100% correct". And any time that requires direct user input is absolute terrible for the latter.

On December 06 2015 04:43 Blitzkrieg0 wrote:

On December 06 2015 04:39 Acrofales wrote:

On December 06 2015 04:32 Blitzkrieg0 wrote:

On December 06 2015 04:19 travis wrote:
What about using setters in a constructor?

For purposes of this specific project I am doing, I won't need to ever set those values once they have been constructed, so I feel like I don't really need to use setters (though getters are needed).

Is there a point to using setters in a constructor ?

The point of a setter is that another class can't access the private field. The constructor can change the private field in the class because it is part of the class. Using the setter in the constructor doesn't make sense for this reason.

Partially, and the debate still rages. But it is often argued that using the setter from within the class is also best, because it better controls the flow. By going to "setFoo" and finding everything that references it, you will know EVERYWHERE that could possibly be fucking with the value of foo. If you allow class methods to set foo without calling setFoo, then it's harder to debug (you now have to find everywhere within the class that sets foo, and everywhere outside the class that calls setFoo).

In any other method sure, but in the constructor? Using the setter in the constructor just feels stupid to me.

Imagine that you have any kind of validation in the setter. Like, checking that a number is non-negative, for something simple.

You could check at every single point where the value is set, or you could have a single validation in the Setter, and call it every time.

Putting validation code in your setter would be bad practice I think. You should have a validation method and a setter method.

Not...really?

I mean, the whole point of a Setter is encapsulating how the variable is changed. Sure, have a validation method, but what's the point of having a Setter to control the input if you're going to have your logic outside of it?

public void setExample(Value value) throws Exception {
    // do error checking
    this.value = value;
}

public void setExample(Value value) throws Exception {
    this.value = value;
}

// some other class

try {
    validator.check(form);
    Example.setExample(value);
} catch (Exception e) {
    // do something
}

On December 06 2015 03:26 travis wrote:
Thanks guys

followup question, for some of you that have used arraylists a bunch

my arraylist holds objects, and the objects have like, 2 ints and 3 strings

Is there an easier way to print a string of all the fields (ints and strings in every element) than to make a loop go through each element, and manually add every int and string of each element into one long string and then print the string

or is that what I need to do?
I was hoping there would be like, a method that would do that for me
I saw toString and tried that but it just returns the reference of the element of the arraylist instead of the actual fields of the element of the arraylist

so where I want something like "Tim 5 The Matrix Interstellar Joe 10 Independence Day", instead I am getting "mediaRentalManager.Customer@4e50df2emediaRentalManager.Customer@1d81eb93mediaRentalManager.Customer@7291c18f"


So, do I need to do this the long way I described?

movies.stream().map(Movie::toString())collect(Collectors.joining(" ");

public abstract class BaseClass {
    protected Integer firstInt;
    protected Integer secondInt;
    protected String firstString;
    protected String secondString;
    protected String thirdString;

    /* getters and setters for the above */

    public String getDataAsString() {
        return new StringJoiner(" ")
            .add(this.firstInt.toString())
            .add(this.secondInt.toString())
            .add(this.firstString)
            .add(this.secondString)
            .add(this.thirdString)
            .toString();
    }
}

class Animal {
    public String talk() {
        return "Animal";
    }
}

class Cat extends Animal {
    public String talk() {
        return "Meow!";
    }
}

class Dog extends Animal {
    public String talk() {
        return "Woof!";
    }
}