Return to Answer

If Java is All You Know, Dabble in Something With a Non-C-Based Syntax

There Are No Size Limits, Only Problem Domains

The biggest problem I have with all the Java codebases I've seen is an overabundance of class files. First of all SOLID is just a confusing reiteration of what you should already know about OOP. A class should handle a specific set of related problems. Not one problem with one method. That's just taking bad old chaining func-spaghetti C code only with the addition of all the pointless class syntax to boot. There is no size or method limit. If it makes sense to add something to an already long function or class or constructor, it makes sense. Take jQuery. It's an entire library-length toolset in a single function and there is nothing wrong with that. Whether we still need jQuery is up to reasonable debate but in terms of design, you can learn a hell of a lot about how to write effective JavaScript by understanding how JQ is architected for minimal memory usage/performance impact through slick use of closures and the prototype property.

If Java is All You Know, Dabble in Something With a Non-C-Based Syntax

function ObjectConstructor(){
    //No need for an init method.
    //Just pass in params and do stuff inside for instantiation behavior

    var privateAndPersistent = true;

    //I like to take advantage of function hoisting for a nice concise interface listing
    this.publicAndPointlessEncapsulationMurderingGetterSetter
    = publicAndPointlessEncapsulationMurderingGetterSetter;
    //Don't do this. And yes it's just as silly in Java and C#. It's bad OOP.

    function publicAndPointlessEncapsulationMurderingGetterSetter(arg){
        if(arg === undefined){
            return privateAndPersistent;
        }
        privateAndPersistent = arg;
    }

}

ObjectConstructor.staticLikeNonInstanceProperty = true;

var instance = new ObjectConstructor();//Convention is to  capitalize constructors

I never touch the stuff. Crockford's given some good things to the community but JSLint crosses the line into stylistic preferences and suggesting certain elements of JavaScript are bad parts for no particularly good reason, IMO. Definitely ignore that one thing about regEx and negation classes followed by * or +. Wildcards perform more poorly and you can easily limit the repetition with {}. Also, ignore anything he says about function constructors. You can easily wrap them in a factory func if the new keyword bothers you. CSSLint is even worse on the bad advice front.

function ObjectConstructor(){
    //No need for an init method.
    //Just pass in params and do stuff inside for instantiation behavior

    var privateAndPersistent = true;

    //I like to take advantage of function hoisting for a nice concise interface listing
    this.publicAndPointlessEncapsulationMurderingGetterSetter
    = publicAndPointlessEncapsulationMurderingGetterSetter;
    //Seriously though Java/C# folks, stop with the pointless getter/setters already

    function publicAndPointlessEncapsulationMurderingGetterSetter(arg){
        if(arg === undefined){
            return privateAndPersistent;
        }
        privateAndPersistent = arg;
    }

}

ObjectConstructor.staticLikeNonInstanceProperty = true;

var instance = new ObjectConstructor();//Convention is to  capitalize constructors

I never touch the stuff. Crockford's given some good things to the community but JSLint crosses the line into stylistic preferences and suggesting certain elements of JavaScript are bad parts for no particularly good reason, IMO. Definitely ignore that one thing about regEx and negation classes followed by * or +. Wildcards perform more poorly and you can easily limit the repetition with {}. Also, ignore anything he says about function constructors. You can easily wrap them in a factory func if the new keyword bothers you. CSSLint (not Crockford's) is even worse on the bad advice front. Always take people who do a lot of speaking engagements with a grain of salt. Sometimes I swear they're just looking to establish authority or generate new material.

Again, see modern browser tools. But also, why is it such a bummer to run the program again? Reload is something a client-side web dev typically hits every few minutes because it costs you absolutely nothing to do it. There's no comipThis is again, another point that app structure can be helpful with but it is one down-side tradeoff of JS that you have to run your own validation when enforcing contracts is critical. IMO, it's well worth the benefits.

Yeah that's bad. Don't do that. Name your functions kids. It's easier to trace things as well. You can define, evaluate (required to assign), and assign a simple trivial function in-line with:

And again, you must unlearn what you have learned with this run-time concern you have. (it's a common one I've seen with a lot of Java/C# devs) If seeing errors in run-time still bothers you 2 years later, I want you to sit down and spam reload in a browser until it sinks in. There is no compile-time and run-time divide (well not a visible one anyway - JS is run on a JIT now). It's not only okay to discover bugs at run-time, it's hugely beneficial to so cheaply and easily spam reload and discover bugs at every stopping point you get to.

Again, see modern browser tools. But also, why is it such a bummer to run the program again? Reload is something a client-side web dev typically hits every few minutes because it costs you absolutely nothing to do it. This is again, another point that app structure can be helpful with but it is one down-side tradeoff of JS that you have to run your own validation when enforcing contracts is critical (something I only do at endpoints exposed to other things my codebase doesn't control). IMO, the tradeoff is well worth the benefits.

Yeah that's bad on anything non-trivial. Don't do that. Name your functions kids. It's easier to trace things as well. You can define, evaluate (required to assign), and assign a simple trivial function in-line with:

And again, you must unlearn what you have learned with this run-time concern you have. (it's a common one I've seen with a lot of Java/C# devs) If seeing errors in run-time still bothers you 2 years later, I want you to sit down and spam reload in a browser until it sinks in. There is no compile-time/run-time divide (well not a visible one anyway - JS is run on a JIT now). It's not only okay to discover bugs at run-time, it's hugely beneficial to so cheaply and easily spam reload and discover bugs at every stopping point you get to.