Interesting articles! I think the first part of the first article immediately introduces an anti-pattern - forcing the user to make an instance of a class just

Interesting articles! I think the first part of the first article immediately introduces an anti-pattern - forcing the user to make an instance of a class just to be able to call a pure function. It's just unnecessary noise, either make them static methods, group them in an object literal, or import the module as a namespace. Adding the "pattern" as a mutable public field is a bit sketchy, and would make it show up in intellisense, but hopefully nobody will access/modify it. Making the pattern as a `const` at module scope solves that problem but you handwave away that approach saying it "pollute the symbol space for intellisense", which isn't true (non-exported items aren't available outside the module). The next section on validation is a good example of another anti-pattern. The example of: public get isUserValid(): boolean is not a good way of doing it, because it relies on hopes and prayers that the user of the class remembers to call this. A better signature would be: function isUser(input: unknown): input is User Notice the key difference - you can't get an instance of User without it being valid. There shouldn't be a notion of "yeah I have a User, but I don't know if it's a valid User". Your way allows people to operate with User, blissfully unaware of whether it is valid or not, hoping that they might notice the right method to call. Instead: Parse, Don't Validate [1] Note that to do this correctly, you have to either: 1. Separate data and functions 2. If you must use a class, then hide the constructor and provide a static constructor with a return type that indicates the function can fail [1] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va... _________ Part 2 was an interesting exercise in how the popular OOP patterns from the GoF book vastly overcomplicated code, negatively impact readability, and make following the code feel like Mario (the princess is in another castle) No need for inheritance, abstract base classes, of any of that complexity, all of that could be done with: type ShippingCalculator = () => number const shippingCalculators = { USPS: calculateUSPS, UPS: calculateUPS, FedEx: calculateFedEx, DHL: calculateDHL, } as const satisfies Record<ShippingMethod, ShippingCalculator> Intellisense works fine of course, and code navigation (via F12) is straightforward and easy to navigate.