CODEWITHSUNDEEP
javascriptfunctionlanguage-agnostic
Celeritas
Celeritas

Reputation: 15043

How to treat a function that is only used by one function

When a function that calls one or more other functions, and these functions being called are only ever used by the one calling function, how should the code be structure?

For example if you have funcB() and funcC() which are only ever called by funcA() should funcB() and funcC() be anonymous functions or nested functions or if they are part of a class should they simply be declared private or placed in inner class?

I'm currently working with JavaScript but have encountered the same situation while using other languages such as C++ and Java.

According to Wikipedia JavaScript does have nested functions though I've never seen it used?

Upvotes: 0

Views: 60

Answers (4)

Shanimal
Shanimal

Reputation: 11718

If funcB and funcC are created as a closure inside your class and you don't 'expose' these to the interface, then they can change (be removed, added, return different values, etc...) without worrying about how they've been implemented outside the Class.

Once they are exposed all bets are off and they might need to be unit tested, supported, etc. This is a well known rule.

A closure is simply a function declared within the scope where its going to be used.

Method A

function MyClass(){

    function funcA(i){
        funcB(i);
        funcC(i);
    }
    function funcB(i){
        //...
    }
    function funcC(i){
        //...
    }
    return {funcA:funcA}
}
va mc = new MyClass()
for(var i = 0;i<100000;i++){    
    mc.funcA(i);
}

Method B: 

function MyClass(){
    function funcA(){
        function funcB(){
        }
        function funcC(){
        }
        for(var i = 0;i<100000;i++){
            funcB();
            funcC();
        }
        // funcB, funcC are created before and then released after this
    }
    return {funcA:funcA}
}
va mc = new MyClass()
mc.funcA();

Method B might be less preferred when funcA is called many times because assignment is optimally expensive.

Method B might be preferred when considering memory. Although it's debatable since funcA and funcB are resident in both MyClass and MyClass.funcA.

Upvotes: 0

Noah C
Noah C

Reputation: 208

When I'm starting a project, I tend to avoid encapsulating functionality until things are getting stable.

As Dancrumb pointed out, function calls aren't free, so you might need some minor refactoring down the line. But when you're looking at code you haven't touched in months, that nice clean organization will be good for your mental health. And that's exponentially more true when you're working in a team :)

Upvotes: 1

Dancrumb
Dancrumb

Reputation: 27539

There are a number of approaches here.

Javascript supports anonymous functions that can be defined and assigned to a variable anywhere in your code.

Thus, you could write:

function foo() {
  var bar = function() { /* some code */ };

  bar();
}

And bar would not be available anywhere else. This might be useful for encapsulating functionality, but I don't think it's a very scalable model for development.

There's a school of thought that suggests that any function that is called only once could, in the future, be something worth calling more than once. In this case, you can create functions that are 'private':

var Foo = (function() {

  var Foo = function() {
    /* some constructor code */
  };

  var private = function() { /* a private function */ };

  Foo.prototype.public = function() {
    private();
    /* And some other stuff */
  };

  return Foo;

})();

var foo = new Foo();
foo.public(); /* Includes a call to the private method */

In this, your private method is truly private, so you don't have to expose inner workings to the world.

But really, that's more of a discussion of how to implement access modification. There's plenty of information out there to answer that question. The bigger, design question is whether to implement separate functions, or whether to just inline them.

My choice is generally to tuck cohesive pieces of function into... well, into functions. The cost of a function call is non-zero, but worry about that after the fact... if you identify that the function call is a performance bottleneck, then you can worry about whether you're calling too much and whether you should refactor your code to use fewer calls.

Until that time, write your functions, call them and revel in clear code. Just make sure you use good method names :)

Upvotes: 0

WW.
WW.

Reputation: 24281

If funcB() and funcC() do not conceptually make sense alongside funcA() then you should not make the public.

Traditional OOP would say you should make them private.

It's my opinion that nearly always there is another concept to which funcB() and funcC() belong. You should make them public methods on different class. Whatever holds funcA() holds a private instance of that class.

It's difficult to make a compelling case for this while talking abstractly about A, B and C. But I would say if they do not conceptually belong with funcA() then there is something else that they do conceptually belong to. If you agree with that premise and agree that composition is better than inheritance, the conclusion is to make them public on some other class.

Upvotes: 1

Related Questions