Using objects to construct nearly the same objects

Question

I am getting worried I have some terrible design pattern here in JS/Node.js/MongoDB. It seems to that to create an object, I need an object that looks like that object. This includes data that comes from the user or data that comes from the database. It is just a lot of duplication, but I have not figured another way around it.

Quick example

// Application user object
class User {
    // Right away, my constructor almost literally takes itself as params
    // The alternative being many setters
    constructor({
        username = '',
        password = '',
        email = ''
    }){
        this.username = username;
        this.password = password;
        this.email = email;
    }
}

// Form data from REST API
const formdata = {
    username: 'bob',
    password: '123',
    email: '[email protected]'
}

// Create the user in the app
const user = new User(formdata);

// Add to the db
insertIntoDb(user);

// Get from the db
const dbdata = getFromDb(userid);

// Turn into object
const user = new User(dbdata);

Maybe I am overthinking things. But my User class barely does anything to begin with. Is it acceptable if this class is just a definition of an object (kind of like a c struct) so developers know what its properties should be? This is mostly the point I think. Since JS is so loose, you could set object properties to whatever you want or read properties that don't even exist (which I usually solve by adding getters).

But I get this headache when I realize that most, if not all, of these user properties are just for persistence. Should this be part of a persistence layer only?

Answer 1

I would write the class the same way. Using an object is the normal way to simulate named parameters. Nothing wrong with this. What you gain with your solution is the following:

• Your user objects don't just have a particular shape, but are also instanceof User.
  • If only a particular shape is needed, consider using TypeScript and declare an interface.
• You have a clear place to add consistency checks, for example to ensure that the fields contain strings. Early checks make systems easier to debug.
• You can verify that your user object won't contain unexpected fields.

Of course, these advantages may or may not matter. I think these are valuable when your object is part of your domain model and when there is business logic that depends on the object behaving a certain way (e.g. having fields that contain values of a particular type). You mention minimal business logic with an isAdmin() method, though it's not clear whether this should be modelled as part of this object.

If there is no substantial business logic (CRUD app) or when this object is really only used to pass user information to/from the database, then I'd skip it. Instead of attaching checks to the object, we could attach them to operations on the data – a procedural instead of an object-oriented view. So you might have a function db.updateUser({...}) that takes an object and then validates that it matches the database schema. In the context of schemaless databases like MongoDB, it could also be sensible to perform some validation when loading an object from the database.

Answer 2

It appears to me there are two different questions here:

1. How to avoid the boilerplate code in the constructor?
2. Is it a sound approach to start by designing an object in a struct-like fashion (and extend this later by adding methods)?

The answer to your first question ist the same I gave to your former question here: use Object.assign and the constructor becomes almost trivial.

To your second question: there are surely some people here in the community who would question this because it goes against their idealistic point of view "what OO should be". But I am a pragmatician, and I can tell you from first-hand experience that this is a perfectly viable approach to construct well maintainable, suffiently object-oriented software. If you need a User object with mostly data members and a few member functions, you can start with a class similar to the "DTO user" and refactor step-by-step, adding some business logic and maybe the required degree of encapsulation, if that's your design goal.