# Which will be better declaration go to with TypeScript? [closed]

This is a simple question, but during my migration to TypeScript, I'm seeing that in many cases my code could take these two directions... which one could be a better direction to go with: class.ts or interface.ts?

class.ts

export class ActionSet {
constructor(private name: string) {}

get ACTION(): string {
return this.name;
}

get PENDING(): string {
return ${this.name}_PENDING; } get FULFILLED(): string { return ${this.name}_FULFILLED;
}

get REJECTED(): string {
return ${this.name}_REJECTED; } } export function createActionSet(name: string): ActionSet { return new ActionSet(name); }  interface.ts export interface IActionSet { ACTION: string; PENDING: string; FULFILLED: string; REJECTED: string; } export function createActionSet(name: string): IActionSet { return { ACTION: name, PENDING: ${name}_PENDING,
FULFILLED: ${name}_FULFILLED, REJECTED: ${name}_REJECTED
};
}


Due to ActionSet is not being used in many places, will it be worth to create a class for it? or is this implementation an overkill?

## closed as off-topic by Dannnno, Malachi♦May 10 '18 at 14:01

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "Lacks concrete context: Code Review requires concrete code from a project, with sufficient context for reviewers to understand how that code is used. Pseudocode, stub code, hypothetical code, obfuscated code, and generic best practices are outside the scope of this site." – Dannnno, Malachi
If this question can be reworded to fit the rules in the help center, please edit the question.

• Also do not crosspost please. – πάντα ῥεῖ May 10 '18 at 10:46
• Welcome to Code Review! This question is incomplete. To help reviewers give you better answers, please add sufficient context to your question. The more you tell us about what your code does and what the purpose of doing that is, the easier it will be for reviewers to help you. Questions should include a description of what the code does – Dannnno May 10 '18 at 13:41

Your question is a bit too abstract. Both ways are okay in different scenarios. You may even have a mixture of two patterns in the same code base... Sorry, but yes, my answer is "it depends".

I think, the key here is the intent and the way it's conveyed via code. If ActionSet's behavior is rigid, and "known in advance", you may want to declare it as a class (as in first example). This will make sure that even when an instance is created NOT by using createActionSet() it still obeys the same behavior rules.

If however, your entity is not rigid and you don't know all its possible usages in advance, it's probably better to start with an interface and a set of factory functions (as in second example).

Since the context of the question is not really known, I hesitate to go beyond this explanation and recommend a particular one.

In my practice interfaces have always been "handier", more refactorable, and easier to deal with. I do pick them as defaults today and rarely go to classes. This, however, is mostly true to DTO-alike classes ("dummy" classes with little to no behavior whatsoever). I find it helpful to separate the data transfer entities from the data processing entities, but it (again) could be due to the client-server-comm saturated nature of my applications.

• Thanks a lot for your reply, I completely agree with it. Due to the nature of the rest of my codebase, in this case, and basing on your reply, defining as interface makes sense as this abstraction in the example is indicating me, part of the response too. – iarroyo May 10 '18 at 13:47