Class vs Routine in ObjectScript. What Do You Use And Why?

Another + for classes would be intellisense in studio. 

Although, I do like the public output variable list separation to input variable in mac files like so:

TEST (invar) [outvar] public {

}

Classes only.

Each method, that could be called from a terminal is documented with a sample call.

If I'm writing something that will  maybe run 2 or 3 times, and is less than 10 lines of code, I might use a .mac.  For anything more than that, I would use a class, as the time saved in setup is pretty negligible compared to the rest of the work done

You should not be able to do it if you want to pass only compiled objects.

I think it really depends on your coding preferences. There are benefits to writing using Objects (CLS) and benefits to writing in (MAC) and which you use may simply depend on what your coding preferences are.

Do you like to code using objects, then CLS is the way to go. Are you a procedural programmer, then (MAC) is the way to go.

Using CLS, you program using objects with properties and methods. You gain the benefit of being able to access your object data via three different mechanisms, direct global access, object access, or sql. You implement methods and typically your methods are logically organized into the classes that they pertain to. You gain inheritance, XML support, JSON support, and so much more.

All that said, if you come from a background of procedural programming and don't have a need or desire to work in objects, there's nothing wrong with using MAC routines.

Still can be so:

Class dc.test [ Abstract ]
{

ClassMethod Test(s = "#")
{
  w "Test_",s
}

ClassMethod mac() [ ProcedureBlock = 0 ]
{
sub1(s=1)
  w "sub1_",s
  q
sub2(s=2)
  w "sub2_",s
  q
procPrivate(s=3) {
  w "procPrivate_",s
}
procPublic(s=3) public {
  w "procPublic_",s
}
}

}

Result:

USER>d zTest^dc.test.1(1)
Test_1
USER>d sub1^dc.test.1
sub1_1
USER>d sub2^dc.test.1
sub2_2
USER>d sub1^dc.test.1(10)
sub1_10
USER>d sub2^dc.test.1(10)
sub2_10
USER>d procPrivate^dc.test.1(10)
 
D procPrivate^dc.test.1(10)
^

USER>d procPublic^dc.test.1(10)
procPublic_10
USER>

Another reason to opt for Objects over Routines is that Objects provide an automated documentation mechanism that Routines dont.  All elements of a class are documented in the class documentation and the developer can add their own text documentation as well

Also, Classes lend themselves much better to programmatic access and manipulation of their content (you can do this with routines too but it is harder to do so due to their unstructured nature).

For example, the server-side Source Control hooks we use can programmatically insert an RCS Keyword as a class parameter ("SrcVer") into any class which doesn't already have it defined.   This is extremely powerful because it allows source control to create an automatic 'watermark' in every class created for our internal applications which can be programmatically access or from terminal:

SSO>write ##class(AppS.WebClient).#SrcVer
$Id: //custom_ccrs/us/ISCX/SSO/BASE/cls/AppS/WebClient.xml#6 $

This would require much more plumbing to do automatically with a routine!

Routines are preferable if need to call routine from the other namespace.

Classes all the way.

I have yet to see a compelling argument to use routines the later versions of cache.

In practice, the majority of artefacts in our Caché instances are .int files.  We have used classes for mapping globals, .NET web development and writing stored procedures. It is nice to be able to call a classmethod from within a .NET application using a tool-generated proxy class. I detest code that jumps all over the place and Xecute statements within globals. Please stop coding this madness! Let's make the world a better place...

I confess some of the .NET software we have calls a classmethod which in turn calls a legacy .int routine with a Do statement and many subsequent Do statements. Not ideal but necessary if you want to avoid re-writing everything on a massive system. You can also use ClassExplorer with your classes and the "comment-style" self-documentation for classes is useful.  Much of the code we support uses the legacy line-based syntax and there is truly no replacement for well-structured, easy-to-read code. It just makes debugging less of a headache. I love line-spacing and curly braces - the simple things you take for granted in other programming languages. I also can't see anyone doing RESTful API development without classes.

Having human-readable, intuitively named class packages rather than hundreds of obscurely named .int routines and globals makes life so much easier. Having a class in a package in a BIO namespace called BIO.Request with CRUD methods reads much better than an interactive programme invoked by do ^REQ. I also like being able to export self-contained class packages rather than trying to work out what .int files and globals I need to export from memory.

I used both of routine and cls. But I did like for cls . We are appliying FHIR concept to class easily and  generated the structure of the data flow.