Problem z przypisaniem wartości do zmiennej za pomocą settera

Question

class Plik{
    private String odczytanyPlik;

    public void odczytPliku()throws IOException{
        Scanner in = new Scanner(Paths.get("D:\\TestOdczytu.txt"));
        ArrayList<String> tekst = new ArrayList<>(5);

        while(in.hasNextLine()){
            tekst.add(in.nextLine());
        }

        String n = tekst.toString();
        setOdczytanyPlik(n);
    }

    public void setOdczytanyPlik(String msg){
        odczytanyPlik = msg;
    }

    public String getOdczytanyPlik(){
        return odczytanyPlik;
    }
}

 

Próbuje sobie działać na plikach i mam taką klasę, w której odczytuje dane z pliku txt i zapisuje do ArrayList, które następnie chce dać jako String i wywołać za pomocą gettera. Jak próbuje to zrobić to wyświetla się jedynie null, co robię źle?

Answer 1

Jak wygląda main, tworzysz obiekt/ 

Null jest- bo utworzona tablica jest wypełniona null...

 String n = tekst.toString();

tak napisana wartość "n" jest NULL stąd nulle są wkładane do tablicy. 

jak zaimplementowałeś toString :)? że konwertujesz " obiekt array na string"

bez własnej implementacji powinieneś użyć bazoweg dla klasy Array 

String str = Arrays.toString(arr);

Comments

Ale tam nie ma pustej tablicy. Jest tylko nowo zainicjalizowany obiekt ArrayList

---

to teraz powiedz mi czym inicjowane są obiekty typu array[ KLASY ARRAY LIST]  na Stosie Javy ...

---

O czym ty pierdzielisz?

Tam nie ma żadnej tablicy. On tworzy obiekt ArrayList o inicjalnej długości 5.

---

https://stackoverflow.com/questions/13097512/arraylist-initializing-as-null

REFERENCYJNE OBIEKTY MAJĄ WARTOŚCI NULL :)

---

Nie wiem co miał udowodnić ten przykład ze stackoverflow. Bo tam gość ustawił sobie breakpointa i nie wiedział dlaczego jedną listę ma zainicjalizowaną a drugą nie.

Natomiast w tym wątku autor inicjalizuje listę i ma ją pustą. Nawet, żeby do niej wrzucił same nulle (przed czym go to sprawdzenie w pętli i tak zabezpieczy) to i tak mu nie poleci NullPointerException tylko dostanie [null, null, ...]. Błąd jest tak jak zauważył Mateusz - gdzieś wcześniej. Tyle, że autor nie wrzucił stacktrace'a to nie da się określić gdzie a jedynie można go nakierować, żeby sobie na debugu odpalił aplikację i przeanalizował, ewentualnie jakieś logowanie wrzucił na początku metody, żeby sprawdzić czy rzeczywiście tam null nie leci.

Answer 2

A czy wywołujesz metodę odczytPliku przed wypisaniem elementów? U mnie wszystko działa: 

 

import java.io.IOException;
import java.nio.file.Paths;
import java.util.ArrayList;
import java.util.Scanner;

public class Plik {

    private static String odczytanyPlik;

    public void odczytPliku()throws IOException{

        Scanner in = new Scanner(Paths.get("C:\\message.txt"));
        ArrayList<String> tekst = new ArrayList<>();

        while(in.hasNextLine()){
            tekst.add(in.nextLine());
        }

        String n = tekst.toString();
        setOdczytanyPlik(n);
    }

    private void setOdczytanyPlik(String msg){
        odczytanyPlik = msg;
    }

    private String getOdczytanyPlik(){
        return odczytanyPlik;
    }

    public static void main(String[] args) {

        Plik plik = new Plik();
        try {
            plik.odczytPliku();
        } catch (IOException e) {
            e.printStackTrace();
        }
        System.out.println(plik.getOdczytanyPlik());
    }
}

Comments

 private String getOdczytanyPlik(){
        return odczytanyPlik;
    }

metody get/set nie powinny ( wręcz nie mogą być prywatne ) łamie to tzw zasady Hermetyzacji. Gdyż metody te służą aby korzystać z nich "dla ogółu' a czyniąc je prywatnymi dostęp z poza klasy jest niemożliwy, czyli ich sens traci znaczenie.e 

Maksymalna dopuszczalność: to czasem PRIVATE- wtedy spełnia to warunki dziedziczenia więc z jednej strony jest okej, z drugiej dostępność jest dla klas w PACZCE :) 

JEDNAK NADAL SENS GETERA/SETERA staje się wtedy redundancją 

---

Zastosowałem podpowiedzi Inteliijj, a nawet nie spojrzałem, co IDE zmieniło (sugeruje zmianę tych metod na prywatne :)).

---

Spoko piszę dla potomnych jak ot mówią :D