Hur delar man fält i Java som är ej statiska? - JavaFX

Är du säker på att det inte är något annat som är fel?
Testa att dela upp koden i fler rader och se var du får NullPointer

i B så skapa en A, därefter på ny rad getTable() osv. Kolla med if-satser att objekten inte är null.

Ah, ye olde NullPointerException* … Felet är väl just "bara" att du inte initierat tableView i A. (Kul liv när typsystemet inte uttrycker det. Kotlin är vad Java borde ha varit.)

Att det har en massa bra saker som Java saknar (exempelvis funktioner, på riktigt) och saknar en massa dåliga saker som Java har (till exempel överdrivet mycket boilerplate-kod och ständiga NullPointerExceptions) – allt detta samtidigt som det är designat för att interoperera sömlöst med Java.

?

Det räcker med assembly.

Om vi ska snacka programmeringsspråk kan jag säga att något av det bästa man kan göra som programmerare är att lära sig ett purely functional språk som Haskell eller Elm. Både Java och C är (åtminstone så som de i regel används) vad jag skulle kalla smärtsamt imperativa (vilket inte betyder att åtminstone det sistnämnda fyller ett viktigt syfte), och det är i regel inte fördelaktigt att bara kunna tänka imperativt (baserat på omfattande egna erfarenheter av programmering under cirka tio års tid). Typsystemen i Java och C är dessutom tämligen rudimentära.

@heretic16: Du har som sagt inte initierat tableView, så new A().getTable() kommer så klart returnera null eftersom det är det värdet som tableView har. Du måste stoppa in [cmd]tableView = new TableView()[/url] någonstans för att det ska fungera, lämpligtvis i konstruktorn för A.

Fast det där är ju statiskt, eller?

Skickades från m.sweclockers.com

Inte helt säker på vilka språk du syftar på med "detta", men Haskell har ett av världens mest avancerade typsystem och Elm är kanske det mest väldesignade språket för webbappar som finns (för att inte tala om currying by default och immutability, som båda har, och som i mina ögon är två egenskaper som ligger långt ifrån "leksaksnivå"). I synnerhet Haskell är i princip ren matematik.

Kan faktiskt inte förstå vilka likheter du ser med Python, som jag håller med om förtjänar det av dig givna epitetet.

En för mig okänd klassificering, måste jag erkänna. Kan du ge exempel på sådana?

Jag ser att du använder static lite här och var. Försök undvika det: static är "anti-OOP", och du behöver inte ha det för någon av dina lösningar. Det verkar därtill som om du inte förstår varför du egentligen använder det, vilket är en indikator på att du med stor sannolikhet använder det fel.

Jag skulle gå så långt som att säga att static utan "final"-modifierare inte bara är onödigt utan också farligt. Ur ett kodperspektiv då, inte för din hälsa (såvida du inte bygger mjukvara för tunga maskiner; då är det farligt för bägge delar.)

OK. Marknaden är ju i regel trög med den typen av förändringar, men den funktionella snöbollen är i rullning.

Ursäkta mig, men om du faktiskt programmerar för kunder så förstår jag att han inte ville köra java... Du verkar ju lägga flera trådar per dag med vad kan se ganska elementära frågor och har en inställning till alla språk utom java som inte kan liknas nånting annat än extrem fanboyism och inte objektivt eller lösningsorienterat (som är den inställning programmerare brukar ha när de angriper ett projekt).

Jag som beställare av system... skiter fullständigt i tid eller pris (eller ja till en viss gräns då), utan det är funktion, stabilitet och säkerhet som är det viktiga, det blir även oftast billigast i längden. Har fått intrycket av att du ska föröka utveckla produkter för industriella-system, låter imo som du är ute på galet djupt vatten...

Static är inte fusk, men det kan användas fel. I ditt exempel blir det fel så snart "klass PlotWindow" används på mer än ett ställe eftersom den andra instansen som skapas kommer skriva över TableViewen. Du kommer alltså inte kunna ha två "PlotWindow"-komponenter igång samtidigt.

Det är inget fel med static, men det gäller att man förstår dess syfte inom OOP. Här är några exempel (med väldigt primitiv affärslogik) på när static är både lämpligt och det enda lämpliga:

import java.util.regex.Pattern;

public class Person {
    private static final int MAX_AGE = 125;
    private static final Pattern NAME_REGEX = Pattern.compile("\\w+");
    private static final String DEFAULT_NAME = "John Smith";

    private final int age;
    private final String name;

    public Person(String name, int age) {
        this.age = Math.max(0, Math.min(MAX_AGE, age));
        this.name = isValidName(name) ? name : DEFAULT_NAME;
    }

    public static boolean isValidName(String name) {
        return NAME_REGEX.matcher(name).matches();
    }
}

age och name kan inte vara static, för vi vill kunna modellera att varje person har en egen ålder och ett eget namn. Men MAX_AGE, NAME_REGEX, DEFAULT_NAME och isValidName är uppenbart static, för de är endast relaterade till klassen Person, inte till någon instans.

Jag tror och hoppas att OOP är på en nedåtgående trend. Det finns säkert områden där det verkligen är bra, men det finns också väldigt många där det antingen missbrukas eller där koden blir alltför komplex att förstå (inte minst på grund av statefulness) även om allt görs "rätt" (enligt OOP).

Så är det absolut, och det blir tydligt inte minst i just OOP-kod, där state tyvärr ofta missbrukas ad absurdum.

Standardsättet är att man vid skapandet av ett nytt objekt skickar med andra komponenter som objektet behöver för att kunna fylla sin funktion (detta kallas dependency injection.).

Exempel:

public class PlotWindow {
  final private TableView tableView;

  public PlotWindow(TableView tableView) {
    this.tableView = tableView;
  }
}

Det går även att skriva sin klass så att beroenden kan sättas i efterhand, men det är inte lika "snyggt"; det är lätt att på något ställe i sin kod glömma skriva plotWindow.setTableView(tableView); och sedan blir det null-fel när programmet kör och plotWindow försöker arbeta med sin TableView.

Dessvärre blir processen för JavaFX krångligare eftersom vyer laddas in dynamiskt från FXML-filer. En snabb googling visar att många använder sig av Springs dependency injection-ramverk, men det verkar snabbt bli överkurs tyvärr :\