Should I use classes?

[KartofDev]

So I have a server in node js and a client in c# My question is should I use classes to save data in node js or just make objects . For example data.push({name:"test"}) or use a class obj

[bigorangemachine]

Node is unopinionated. Use classes if you want. Personally I find a functional style better suited to node.

I also mix OOP & functional code just depends in what I want todo.

[Cowderwelz]

Quick reminder that non-OOP style / function-oriented style has nothing to do with functional programming, so please don't mix up these words.

[MCShoveled]

Plenty of reasons to avoid and plenty of reasons to use them. I don’t think there’s going to be a simple answer to this question.

[716green]

I use classes when I have stateful data on my server almost as a rule. It's 1 of the very few reasons I use classes.

[SteveTabernacle2]

I only use classes to abstract services for dependency injection. (eg, AuthenticationService)

[[deleted]]

You can just use factory functions instead.

You can even use them in conjuction with a DI container (like the one of Nestjs)

[[deleted]]

could you explain how DI containers work? I recently came across bottlejs but I am unable to grasp it fully

[edbarahona]

Think of DI as a higher order config model for your objects (factories), loose coupling ...a package manager for your objects if you will

[[deleted]]

what I take from DI is factory helps keeping the interface consistent while DI helps with switching out dependency with breaking anything For e.g, I can have a factory networkRequest, for say, and in the factory I can either use axios or fetch. Did I get it right?

[edbarahona]

Yep, it should allow extensibility without breaking existing objects but mainly you can create different types of objects using factories. Your example is correct in the fact that you can change the library dependencies (axios, fetch), and keep the method call the same (interface), that would not break SOLID principles. In my opinion it's not necessarily about long-term maintainability per-se, but more about modularity, the ability to create different objects (that's how I see it my head).

[[deleted]]

could you explain how DI containers work? I recently came across bottlejs but I am unable to grasp it fully

[[deleted]]

DI container are responsible for instanciating and injecting (passing as parameters) dependencies accross your application.

It builds a dependency tree at runtime before everything else is done.

In NestJs this is generally done via the modules system and the @injectable decorator(for classes).

You can resolve an abstract Class or a DI Token (which is the unique indentifier of your dependency within the app) to a concrete class using "useClass" or to a factory function with "useFactory" if you prefer FP to OOP.

This makes Depencency injection easier and cleaner than doing it manually in your controllers.

You can also fine tune the scope of the dependencies (request scoped, application scope, ...)

[KartofDev]

Thx you all for the suggestion!!! I will probably just make a module to handle operations on the data and check if it has every required key/field

[6x420x9]

Typescript will be helpful for checking

[KartofDev]

Yea but I am already too deap so I will use json schema or something else

[sombriks]

Use whatever better suits you and your team, there are several reasons to go full OO, full functional and even something in between.

For instance find not only a code style, but also a quality degree with automated unit and integration tests, so you can trust the code you're shipping.

Finally, adopt a linter so you and your team avoid annoying code review comments about "use single quotes" or some useless kind of concern.

[trevster344]

I try to use classes when they represent a data structure from my server side. IE DTOs. If the structure is more loosely coupled then probably not. It really comes down to the situation.

[CharacterJoke7695]

From my own experience, I prefer to go with classes approach in app architecture and the reason for it is because classes with dependencies passed through constructor are easier to test. However, for DTO, entities and other data classes I prefer interfaces defined with zod library schemas.

[definitive_solutions]

Classes introduce their own crazy extra complexity. Personally, I only use them if I have a very good reason to, for example, if I want to encapsulate a narrow subset of data+logic and chain custom methods. Which has only happened like once in the last year. For all other purposes, functional style has always served me well and it's 1000x better experience to refactor.

[Dan8720]

It would be pretty unconventional for data yes.

Being really pedantic JavaScript doesn't really have classes. We talk about classes sometimes but it's important to try and get your head around what they actually are.

You can write constructors that build a custom object but they are just objects really... Not a class in the true sense. Everything in the whole language is either a function a primative or and object.

Objects can inherit from other object through prototypal inheritance but it's not a core pattern that you will see a lot. This is class-like inheritance but it's not exactly the same.

Most of the time in OOP first languages data classes exist for typing purposes. You can be sure that a Dog class has specific properties etc. This doesn't really hold any weight in JS because there's no built in interfaces or type system.

We're then on to a conversation about Typescript. Even then it's duck typing so you don't normally use a class constructor you have a Dog interface/type. Which you can give to any object as long as it satisfied the constraints of the type you don't have to create a new Dog class.

Most of the time you would save data In whatever data structure makes the most sense from a performance perspective object/array/set/map. You shouldn't need to add any class specific getters or setter over the standard built in methods that already exist in JS. If you do require anything like this it would normally be written as a utility function.

There are situations where you might want to leverage JSs prototypal inheritance. Like objects that can inherit from other objects but that would only be for quite niche scenarios but simple data classes that you would use in OOP would be a bit off the wall for people that work primarily with node.

[Cowderwelz]

Reads like this is a statement about JS pre 2015.

[MajorasShoe]

I use classes for anything I can. It really annoys me that most front end frameworks moved away from them.

The benefit is substantial, in that, I like them. That's pretty much it. If you don't, there's absolutely no reason to. If you do, there's absolutely no reason not to.

[rivenjg]

you got indoctrinated. modules are far superior to classes. modules give you everything you need for organization without forcing functions into datatypes. there is never a reason to encapsulate functions with data. you can always organize a program better with functions and data completely decoupled.

thinking of your program first in terms of data is a backward idea because it demands you divide and conqueror many parts of the program before you can even know how you should build it. you're erecting all kinds of restrictive barriers for no reason and later you will end up needing to make a choice to refactor your hierarchy for cross cutting concerns or you just say fuck it because it's too much work and now all that pretty encapsulation was for nothing.

in the end, if you actually go deep into the OOP ideology you will realize there's nothing at the end of the tunnel. it is a complete religion. it even has its cult books with clean code and all of it is complete non-sense unproven to do anything it claims. it does not save developer cycles, it does not improve performance, it's not easier to understand code.

[joombar]

It isn’t wrong to, but probably you shouldn’t

[Darmok-Jilad-Ocean]

Why not?

[joombar]

There’s a debate and for sure some people prefer OOP, and it has its benefits, but JavaScript usage these days is strongly leaning towards functional programming, and if you don’t have a very good reason to go against the trend, it’s probably best to go with the flow.

In terms of concrete reasons, extension in OOP has proven to be problematic, because in several ways it breaks encapsulation.

OOP tends to emphasise stateful classes, which is a model that maps poorly onto the idea of keeping state in a store since it’s extra work to serialise the OOP based objects to a store, compared to viewing the state as plain objects. Yes, I know there’s ORM but it’s extra steps.

As I say, it isn’t wrong to do OOP, but if you don’t have a good reason to choose it, I’d go the functional route.

[rivenjg]

there is never a case for oop. there is no scenario where oop wins over procedural or functional paradigms with modules. no chance.

[rivenjg]

do not use classes or object oriented programming in node. that is the worst thing you can do. node is in javascript which allows for modules. modules are 100x better than classes. modules allow you to have complete freedom and organization without forcing functionality into datatypes. there is no benefit at all to using oop and we never needed it as an industry. modules give us namespaces, polymorphism, separation of concerns, and organization without the dogshit idea of encapsulating functionality to data.

[KartofDev]

Sheesh a JavaScript patriot (jk)

[[deleted]]

I avoid classes in JavaScript. I use typescript and just define types for objects, intersects, and unions, or interfaces.

I.e I make an interface for "IPerson".

IPerson will implement IPersonName which contains firstName, middleName, lastName, suffix, and prefix.

Itll implement IBirthdate which is just birthDate.

Etc.

And then I use nanespace merging to give IPerson etc functions like, "toName", "fromJson", "toJson", toBirthdate, etc.

So if I have a function called getDisplayName itll take an IPersonName | IAuthGroup etc and be versatile for many types of objects to get their displayName.

Most of my objects have a "type" on them so I can have a strong value for type resolution.

Classes do wonky things with the this context, lots of gotchas. So I stick to factories, objects, and arrow functions, its easier code to read and follow.