Gå til innhold

Holgers lille NTNU-tråd | *Se første post for spørsmål om hybel*


HolgerL

Hvilket sted tilhører du?  

1 456 stemmer

  1. 1. Velg ett av alternativene

    • Dragvoll
      254
    • Gløshaugen
      1018
    • Annet
      202


Anbefalte innlegg

Videoannonse
Annonse

Hva er problemet med dette TDT4100? At det modelleres kjøretøy og restauranter i eksemplene?

Problemet er at objektorientering er ganske far-fetched før man har lært seg grunnleggende tenkemåte for problemløsning. Hvis du ikke har snøring på sammenheng mellom input og output av en funksjon, ikke skjønner forskjellen på et array og en lenket liste, eller ikke klarer å stable sammen en løsning på enkle "skriv inn et tall, gjør noe med tall og skriv ut resultatet"-oppgaver, så er objektorientering helt bak mål. Spesielt det siste eksempelet der er noe som krever trening i problemløsning. Rett og slett trening i det å få et problem, stokke rundt på verktøyene du har og lage en løsning av det. Det eneste proggefaget jeg har hatt som har en slik tilnærming er algdat, hvor programmeringen bare er et verktøy. Både TDT4100 og TDT4102 kjører hardt på å gå gjennom en hel haug av mer eller mindre nyttig syntaks i henholdsvis Java og C++, men lite om hvordan dette faktisk brukes i en større sammenheng, eller diskusjon rundt hvordan dette kunne vært gjort enklere/vanskeligere med andre metoder. Eksemplene som gis er små fjaseeksempler hvor den store fordelen med konstruksjonen ikke kommer frem i det hele tatt.

 

TDT4102 har riktignok en litt mykere tilnærming siden det kjører vanlig prosedyreorientert programmering først. Men alle detaljene i C++ (minnehåndtering, blablabla) gjør at det likevel blir et eneste stort kav for de som ikke skjønner programmering. Når objektorienteringen i tillegg smeller deg i trynet på slutten av semesteret sitter du rimelig godt i det. For de som kan programmering fra før av er det dritlett, men for resten (og de er det mange av) er det helt umulig. Derfor er det kjipt å bruke TDT4100/TDT4102 som introfag for programmering. ITGK skal riktignok få alle opp på et minimumsnivå, men det viser seg at kunnskapene etter ITGK ikke er gode nok (studass-erfaring fra både TDT4105 og TDT4102). Også ITGK har nemlig i overkant stort fokus på syntaks, og mindre fokus på selve problemløsningen.

Endret av endrebjo
  • Liker 3
Lenke til kommentar
Gjest Bruker-182691

kode kode kode kode kaffe kode kode kode kode

 

Flaut å si det, men jeg aner ikke hvordan jeg løser problemet..

public class LineEditor {
    
    //oppretter to variables?
    public String text;
    public int insertionIndex;
    
    //lager en metode? som setter variabel verdi utifra parameterne
    public LineEditor(String text, int i){
        this.text = text;
        insertionIndex = i;
    }
    
    //"flytter" meg en indexverdi til venstre dersom den er > 0
    public void left(){
        if (insertionIndex > 0) {insertionIndex -= 1;}
    }

    //"flytter" meg til høyre dersom den ikke møter ingenting.
    public void right(){
        if (text != "") {insertionIndex += 1;}
    }

    //får ikke dette til å virke...
    public void deleteLeft(){
        char[] chars = text.toCharArray();
        chars[insertionIndex-1] = ' ';
        text = new String(chars);
    }

    public void deleteRight(){
        char[] chars = text.toCharArray();
        chars[insertionIndex+1] = ' ';
        text = new String(chars);
    }
    //forstår ikke hva oppgaven spør om, hurra!
    public void insertString(String s){

    }
    
    //kaller hovedfunksjonen, forstår ikke helt hva jeg gjør..
    public static void main(String[] args) {
        LineEditor l = new LineEditor("yolo", 0);
        l.deleteRight();
        //printer ut @XXXXXXXXX slik som den er nå..
        System.out.println(l);
    }
}

Endret av Bruker-182691
Lenke til kommentar

Hvorfor bygger en ikke videre på det objektorienterte språket en del av studentene allerede kan fra ITGK?

Med mindre man har tenkt å gå helt bort ifra Java, må de uansett lære det på et eller annet tidspunkt. Java er dessuten mer rent objektorientert enn Python, og passer bedre i et fag som strengt tatt heter "Objektorientert programmering".

Lenke til kommentar

Med mindre man har tenkt å gå helt bort ifra Java, må de uansett lære det på et eller annet tidspunkt. Java er dessuten mer rent objektorientert enn Python, og passer bedre i et fag som strengt tatt heter "Objektorientert programmering".

Hva er det med Java som er mer rent objektorientert? At man absolutt må lage en eksplisitt klasse for å kjøre et program?

Lenke til kommentar

Hva er det med Java som er mer rent objektorientert? At man absolutt må lage en eksplisitt klasse for å kjøre et program?

Ikke bare, men det bidrar. Java style oop er ganske røtent, forøvrig. Det at java ikke egentlig støtter noe annet enn denne idéen objektorientering gjør det på sett og vis "renere" objektorientert, uten at det nødvendigvis er positivt. Endret av Lycantrophe
Lenke til kommentar

Java har for det første encapsulation, mens i Python må du tvinge deg selv til å ikke aksessere et objekts interne variabler (dersom du ønsker encapsulation).

 

Edit: Det er også et poeng at Java i stor grad tvinger deg til å skrive objektorientert kode, mens Python i like stor grad er et prosedyreorientert programmeringsspråk som det er objektorientert.

Endret av operg
Lenke til kommentar

Java har for det første encapsulation, mens i Python må du tvinge deg selv til å ikke aksessere et objekts interne variabler (dersom du ønsker encapsulation).

Dette stemmer, og er en latterlig dårlig feature i python imo.

 

Edit: Det er også et poeng at Java i stor grad tvinger deg til å skrive objektorientert kode, mens Python i like stor grad er et prosedyreorientert programmeringsspråk som det er objektorientert.

Og funksjonelt. Man kan også skrive (nogenlunde) prosedyrisk java, men det er verbost og tungvindt og ekkelt.

 

(Akkurat som objektorientert java, med andre ord. :--------------D)

  • Liker 2
Lenke til kommentar

Java har for det første encapsulation, mens i Python må du tvinge deg selv til å ikke aksessere et objekts interne variabler (dersom du ønsker encapsulation).

 

Heter det ikke at det er din egen feil dersom du aksesserer et objekts interne variabler direkte der det skulle vært ungått? Bare fordi en har muligheten trenger en jo ikke bruke den.

Lenke til kommentar
// masse syntaks

 

Det der var heftige greier i forhold til det som har vært på de første tre øvingene i TDT4102, som fortsatt ligner mye på programmeringen i ITGK. Gjelder kritikken din begge variantene av faget i like stor grad, Lycantrophe?

Endret av Grønnsyre
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...