I am learning Typescript and was reading their documentation.
Rethinking the Class
C# and Java are what we might call mandatory OOP languages. In these languages, the class is the basic
unit of code organization, and also the basic container of all data and behavior at runtime.
Forcing 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.Free Functions and Data
In JavaScript, functions can live anywhere, and data can be passed around freely without being inside a
pre-defined class or struct. This flexibility is extremely powerful. “Free” functions
(those not associated with a class) working over data without an implied OOP
hierarchy tend to be the preferred model for writing programs in JavaScript.
Having programmed in C for years, this reminds me that functions were always accessible (global scope); I just needed to include the header file. Also, functions could be declared in any file, which made searching for the code fun. (With today’s editors, that’s not a problem.)
OOP languages brought structure/organization to coding, but Typescript seems to be leaning back to the ‘good old days.’
Am I interpreting this correctly? I am learning Typescript out of my frustration with JavaScript. (Mistype a character, and your JavaScript program goes haywire, and you’re clueless about why.)
Thank you
3
OOP languages brought structure/organization to coding, but Typescript seems to be leaning back to the ‘good old days.’
No. The point being made is more subtle: In C# and Java, the unit of organisation is the class. In particular, visibility of identifiers is controlled with respect to the class: private members are visible to the class, protected members to the class and its subclasses, and public members to all classes.
In TypeScript, the unit of organisation is the module (“the source file”), not the class. In particular, visibility of identifiers is controlled with respect to the module, with non-exported identifiers being visible only within the module, and exported identifiers visible anywhere.
That is, in C# and Java, classes are the means of organisation. In TypeScript and JavaScript, the means of organisation are unrelated to classes.
There is nothing wrong with having a module that exports a function rather than a class. In particular, it is entirely ok to write:
export function formatNumber(n: number) {
// code to format a number for display
}
you don’t have to write
export class NumberFormatter {
formatNumber(n: number) {
// code to format a number for display
}
}
Java is an object oriented programming language. It expects you to organize your program using objects that have state, behaviour, and encapsulation.
JavaScript is a multi-paradigm programming language. It supports an object oriented style very similar to Java, but it also supports a functional or procedural style. You can choose whichever style best fits the problem at hand. And many people coming from OOP languages are surprised how rarely OOP turns out to be the best fit.