TypeScript is a popular choice for programmers accustomed to other languages with static typing, such as C# and Java.
\nTypeScript’s type system offers many of the same benefits, such as better code completion, earlier detection of errors, and clearer communication between parts of your program.\nWhile TypeScript provides many familiar features for these developers, it’s worth stepping back to see how JavaScript (and therefore TypeScript) differ from traditional OOP languages.\nUnderstanding these differences will help you write better JavaScript code, and avoid common pitfalls that programmers who go straight from C#/Java to TypeScript may fall in to.
\nIf you’re familiar with JavaScript already but are primarily a Java or C# programmer, this introductory page can help explain some of the common misconceptions and pitfalls you might be susceptible to.\nSome of the ways that TypeScript models types are quite different from Java or C#, and it’s important to keep these in mind when learning TypeScript.
\nIf you’re a Java or C# programmer that is new to JavaScript in general, we recommend learning a little bit of JavaScript without types first to understand JavaScript’s runtime behaviors.\nBecause TypeScript doesn’t change how your code runs, you’ll still have to learn how JavaScript works in order to write code that actually does something!
\nIt’s important to remember that TypeScript uses the same runtime as JavaScript, so any resources about how to accomplish specific runtime behavior (converting a string to a number, displaying an alert, writing a file to disk, etc.) will always apply equally well to TypeScript programs.\nDon’t limit yourself to TypeScript-specific resources!
\nC# and Java are what we might call mandatory OOP languages.\nIn these languages, the class is the basic unit of code organization, and also the basic container of all data and behavior at runtime.\nForcing all functionality and data to be held in classes can be a good domain model for some problems, but not every domain needs to be represented this way.
\nIn JavaScript, functions can live anywhere, and data can be passed around freely without being inside a pre-defined class or struct.\nThis flexibility is extremely powerful.\n“Free” functions (those not associated with a class) working over data without an implied OOP hierarchy tends to be the preferred model for writing programs in JavaScript.
Additionally, certain constructs from C# and Java such as singletons and static classes are unnecessary in TypeScript.
\nThat said, you can still use classes if you like!\nSome problems are well-suited to being solved by a traditional OOP hierarchy, and TypeScript’s support for JavaScript classes will make these models even more powerful.\nTypeScript supports many common patterns such as implementing interfaces, inheritance, and static methods.
\nWe’ll cover classes later in this guide.
\nTypeScript’s understanding of a type is actually quite different from C# or Java’s.\nLet’s explore some differences.
\nIn C# or Java, any given value or object has one exact type - either null, a primitive, or a known class type.\nWe can call methods like value.GetType() or value.getClass() to query the exact type at runtime.\nThe definition of this type will reside in a class somewhere with some name, and we can’t use two classes with similar shapes in lieu of each other unless there’s an explicit inheritance relationship or commonly-implemented interface.
These aspects describe a reified, nominal type system.\nThe types we wrote in the code are present at runtime, and the types are related via their declarations, not their structures.
\nIn C# or Java, it’s meaningful to think of a one-to-one correspondence between runtime types and their compile-time declarations.
\nIn TypeScript, it’s better to think of a type as a set of values that share something in common.\nBecause types are just sets, a particular value can belong to many sets at the same time.
\nOnce you start thinking of types as sets, certain operations become very natural.\nFor example, in C#, it’s awkward to pass around a value that is either a string or int, because there isn’t a single type that represents this sort of value.
In TypeScript, this becomes very natural once you realize that every type is just a set.\nHow do you describe a value that either belongs in the string set or the number set?\nIt simply belongs to the union of those sets: string | number.
TypeScript provides a number of mechanisms to work with types in a set-theoretic way, and you’ll find them more intuitive if you think of types as sets.
\nIn TypeScript, objects are not of a single exact type.\nFor example, if we construct an object that satisfies an interface, we can use that object where that interface is expected even though there was no declarative relationship between the two.
\n\ntsinterface Pointlike interface Pointlike\n x:(property) Pointlike.x: number number;\n y:(property) Pointlike.y: number number;\n}\ninterface Named interface Named\n name:(property) Named.name: string string;\n}\n\nfunction printPoint(function printPoint(point: Pointlike): voidpoint:(parameter) point: Pointlike Pointlike)interface Pointlike {\n console.var console: Consolelog((method) Console.log(message?: any, ...optionalParams: any[]): void\"x = \" + point.(parameter) point: Pointlikex (property) Pointlike.x: number+ \", y = \" + point.(parameter) point: Pointlikey)(property) Pointlike.y: number\n}\n\nfunction printName(function printName(x: Named): voidx:(parameter) x: Named Named)interface Named {\n console.var console: Consolelog((method) Console.log(message?: any, ...optionalParams: any[]): void\"Hello, \" + x.(parameter) x: Namedname)(property) Named.name: string\n}\n\nconst obj const obj: { x: number; y: number; name: string; }= {\n x:(property) x: number0,\n y:(property) y: number0,\n name:(property) name: string\"Origin\"\n};\n\nprintPoint(function printPoint(point: Pointlike): voidobj)const obj: { x: number; y: number; name: string; }\nprintName(function printName(x: Named): voidobj)const obj: { x: number; y: number; name: string; }
TypeScript’s type system is structural, not nominal: We can use obj as a Pointlike because it has x and y properties that are both numbers.\nThe relationships between types are determined by the properties they contain, not whether they were declared with some particular relationship.
TypeScript’s type system is also not reified: There’s nothing at runtime that will tell us that obj is Pointlike.\nIn fact, the Pointlike type is not present in any form at runtime.
Going back to the idea of types as sets, we can think of obj as being a member of both the Pointlike set of values and the Named set of values.
OOP programmers are often surprised by two particular aspects of structural typing.
\nThe first is that the empty type seems to defy expectation:
\n\ntsclass Empty class Empty{}\n\nfunction fn(function fn(arg: Empty): voidarg:(parameter) arg: Empty Empty)class Empty {\n // do something?\n}\n\n// No error, but this isn't an 'Empty' ?\nfn(function fn(arg: Empty): void{ k:(property) k: number10 });
TypeScript determines if the call to fn here is valid by seeing if the provided argument is a valid Empty.\nIt does so by examining the structure of { k: 10 } and class Empty { }.\nWe can see that { k: 10 } has all of the properties that Empty does, because Empty has no properties.\nTherefore, this is a valid call!
This may seem surprising, but it’s ultimately a very similar to relationship to one enforced in nominal OOP languages.\nA subclass cannot remove a property of its base class, because doing so would destroy the natural subtype relationship between the derived class and its base.\nStructural type systems simply identify this relationship implicitly by describing subtypes in terms of having properties of compatible types.
\nAnother frequent source of surprise comes with identical types:
\n\ntsclass Car {\n drive() {\n // hit the gas\n }\n}\nclass Golfer {\n drive() {\n // hit the ball far\n }\n}\n\n// No error?\nlet w: Car = new Golfer();
Again, this isn’t an error because the structures of these classes are the same.\nWhile this may seem like a potential source of confusion, in practice, identical classes that shouldn’t be related are not common.
\nWe’ll learn more about how classes relate to each other in the Classes chapter.
\nOOP programmers are accustomed to being able to query the type of any value, even a generic one:
\n\ncsharp// C#\nstatic void PrintType<T>() {\n Console.WriteLine(typeof(T).Name);\n}
Because TypeScript’s type system is fully erased, information about e.g. the instantiation of a generic type parameter is not available at runtime.
\nJavaScript does have some limited primitives like typeof and instanceof, but remember that these operators are still working on the values as they exist in the type-erased output code.\nFor example, typeof (new Car()) will be \"object\", not Car or \"Car\".
This is an overview, from here you should read through the handbook or explore the Playground examples
","headings":[{"value":"Co-learning JavaScript","depth":2},{"value":"Rethinking the Class","depth":2},{"value":"Free Functions and Data","depth":3},{"value":"Static Classes","depth":3},{"value":"OOP in TypeScript","depth":2},{"value":"Rethinking Types","depth":2},{"value":"Nominal Reified Type Systems","depth":3},{"value":"Types as Sets","depth":3},{"value":"Erased Structrual Types","depth":3},{"value":"Consequences of Structural Typing","depth":3},{"value":"Empty Types","depth":4},{"value":"Identical Types","depth":4},{"value":"Reflection","depth":3}],"frontmatter":{"permalink":"/docs/handbook/typescript-in-5-minutes-oop.html","title":"TypeScript for Java/C# Programmers"}}},"pageContext":{"slug":"/docs/handbook/typescript-in-5-minutes-oop.html","isOldHandbook":true}}}