TypeScript - upobodaniam do Javy

Zająłem się nauką TypeScript. Mam złe doświadczenia z JS, nie umiem utrzymać kodu bez korzystania z programowania obiektowego. Kiedyś pisałem prostą grę, do czasu kiedy wszystko wręcz "zlało mi się w jedno". Od pewnego czasu poznaje Visual Studio Code, jest przyjemniejsze niż sądziłem. Dawniej używałem NetBeans'a niemal do wszystkiego. Zaproponowana technologia TS podoba mi się, odpowiedniki wygenerowanych plików JS są dla mnie mało czytelne - "straszne hieroglify". Przyznaje się, że staram sobie upodobnić JavaScript do Javy lub C#. Natrafiłem jednak na problem, nie umiem podzielić sobie klas na dwa pliki. Przy obecnym poziomie wiedzy nie jest mi to potrzebne ale przy tworzeniu większego projektu import klasy by się przydał.

Proszę o wskazówki, są dla mnie bardzo cenne i pomoc w rozwiązaniu problemu.

abstract class Animal {
    protected Aname: string;
    constructor(anyName: string) {
        this.Aname = anyName;
    }
    walk(distance: number) {
        console.log("This is a " + name + " and walking " + distance + " meters.");
    }
}
class Bird extends Animal {
    constructor(anyName: string) {
        super(anyName); 
    }
    fly(distance: number) {
        console.log("This is a " + this.Aname + " and flying " + distance + " meters.");
    }
}
let myBrid = new Bird("Dodo"); 
myBrid.fly(40);

A czytałeś w ogóle tą sekcję dokumentacji: https://www.typescriptlang.org/docs/handbook/modules.html ??

abstract class Animal {
    protected Aname: string;
    constructor(anyName: string) {
        this.Aname = anyName;
    }
    walk(distance: number) {
        console.log("This is a " + name + " and walking " + distance + " meters.");
    }
}

export default Animal;

import Animal from 'path/to/Animal';

class Bird extends Animal {
    constructor(anyName: string) {
        super(anyName); 
    }
    fly(distance: number) {
        console.log("This is a " + this.Aname + " and flying " + distance + " meters.");
    }
}

export default Bird;

import Bird from 'path/to/Bird';

let myBrid = new Bird("Dodo"); 
myBrid.fly(40);

Możesz też użyć przestrzeni nazw (wg mnie gorsza opcja w tym przypadku) -> https://www.typescriptlang.org/docs/handbook/namespaces.html

TypeScript jest bardzo fajnym językiem, pomimo tego, że jest to w zasadzie JS.
Sama nazwa TypeScript oznacza, że jest to type-safe. Czyli jak nadasz nazwę zmiennej lub funkcji i po dwukropku podasz nazwę typu zwracanego np. string, to masz pewność, że typ zwracany będzie stringiem. A w ES6 można było choćby odjąć liczbę od stringa. TypeScript pilnuje, żeby takich "jajec" nie robić. Dlatego jest taki przyjazny dla Javowców.
Poza tym to co napisał @Maciej Cąderek. Robisz klasę i ją eksportujesz, potem można wykorzystać ją w innych klasach, robiąc importy.

Czytałem ale wydało mi to się eksportowanie mało logiczne, co właściwie oznacza dla interpretera aplikacji? Robiłem pewne próby ale coś było nie tak, fakt nie tworzyłem też wcale obiektu. No i zastanowiło mnie czy stworzenie właśnie akurat klasy abstrakcyjnej i zastosowania dziedziczenia nie "przestraszy przetwarzacza" TS (nie znam fachowej nazwy). Nie znam reguł stosowania konstrukcji default TS to naprawdę fajny wynalazek, z przyjemnością wracam do front-edu. Świat przecież nie kończy się na Javie :P

Mam jeszcze pytanie, bo mnie to gryzie:

import Animal from 'path/to/Animal';
 
class Bird extends Animal {
    constructor(anyName: string) {
        super(anyName); 
    }
    fly(distance: number) {
        console.log("This is a " + this.Aname + " and flying " + distance + " meters.");
    }
}
 
export default Bird;

Czy this.Aname nie jest aby bezsensu? Jak to zastąpić ?
Dziękuje za pomoc.

Zająłem się nauką TypeScript. Mam złe doświadczenia z JS, nie umiem utrzymać kodu bez korzystania z programowania obiektowego.

Co ma piernik do wiatraka?

JS jest językiem obiektowym (i był nim od dawna). Po prostu jest to inny rodzaj obiektówki niż w Javie, bo:

• prostszy: oparty bezpośrednio na obiektach, bez użycia klas (chociaż od ES6 już można korzystać z klas, jak ktoś chce)
• mający duck typing zamiast statycznego typowania czy jawnych interfejsów.

Więc to, co piszesz nie ma za wiele sensu. TypeScript nie rozwiązuje problemu "braku obiektówki", ani nawet nie rozwiązuje problemu "brak klas" (do tego wystarczy pisać w ES6). To, co się da w TypeScript zrobić to po prostu zadeklarować jawnie typy czy interfejsy. Np. że dana metoda przyjmuje jako parametr liczbę, a inna stringa. I tutaj masz rację - to jest w pewnym sensie upodobnianiem do Javy - ale nie ma to za wiele związku z OOP. Bardziej z rozróżnieniem na statyczne i dynamiczne języki (JavaScript jest dynamiczne, TypeScript idzie w stronę statyczności, chociaż też nie będzie w pełni statyczny jak Java, bo by musiał przestać być kompatybilny z JSem).

Poza tym o ile OOP jest fajne (i nie trzeba do niego TypeScripta), to jeśli nie umiesz utrzymać kodu bez korzystania z programowania obiektowego. to znaczy, że za bardzo się uzależniasz od konkretnego modelu programowania. A warto czasem wyjść poza strefę komfortu. W JavaScript np. dużą rolę odgrywa często programowanie funkcyjne (nie jestem zwolennikiem pisania 100% funkcyjnie, bo się potem robi syf jak w Redux - ale jednak warto poznać dla własnego rozwoju). Warto też poznać programowanie obiektowe na obiektach, bez użycia klas(i te obiekty w JS są nawet używane do dziedziczenia - wtedy się nazywa je prototypami. Tyle, że akurat dziedziczenie też nie jest wcale potrzebne do obiektówki, ludzie tego nadużywają).

Przyznaje się, że staram sobie upodobnić JavaScript do Javy lub C#.

JavaScriptowcy, którzy będą poprawiać twój kod, będą cię za to hejtować ;)

Pangeon napisał(a):

Mam jeszcze pytanie, bo mnie to gryzie:

Kopiuj

import Animal from 'path/to/Animal';
 
class Bird extends Animal {
    constructor(anyName: string) {
        super(anyName); 
    }
    fly(distance: number) {
        console.log("This is a " + this.Aname + " and flying " + distance + " meters.");
    }
}
 
export default Bird;

Czy this.Aname nie jest aby bezsensu? Jak to zastąpić ?

Ogólnie przykłady z ptaszkami i krówkami sa bez sensu, żeby zastanawiać się czy to ma sens czy nie to musi to rozwiązywać jakiś problem.
Składniowo this.Aname jest poprawne, jeśli chcesz odwołać się do pola klasy to nie ma innej opcji (no oprócz gettera). Poza tym tylko nazwy klas w JS/TS piszemy wielką literą, metody i pola małą (to nie C#).

Dodatkowo jeśli konstruktor jedyne co robi to przekazuje argumenty wywołania do konstruktora rodzica to się go nie pisze.