javascript関数記載の使い分け

Question

javascriptの関数の記載方法について、
プログラムの正しさ、管理のしやすさ、メモリ等のクライアント負荷等の観点で
どれが適切か教えてください。

現在の記載、悩みは以下です。
＜インスタンス変数が不要な場合＞ 現在：グローバル関数として記載
インスタンス化によるメモリ浪費を防ぐため、不要なものはグローバル関数にしています。
管理上は関数の種類によって分けたいが、関数名等の工夫くらいしかわかりません。
（utli.calcA();としたいがutil_calcA();での区別）

//インスタンス変数が不要な場合
function a(){
 処理;
}

＜インスタンス変数が必要な場合＞ 現在：new演算を使ってインスタンス化（形式1）
インスタンス変数が必要な場合はnew演算を使っている。
形式2とどちらが良いか、他の記載が良いか

//インスタンス変数保持が必要な場合
//形式1
function class1(){
 this.amount;
}
class1.prototype={
 funcA: function(){処理}
}
var instance1=new class1();

//形式2
var instance2=function class2(){
 this.amount;
}
class2.prototype={
 funcB: function(){処理}
}

Comments

[think49]

「インスタンス化によるメモリ浪費を防ぐため、不要なものはグローバル関数にしています」が理解できなかったので補足をお願いします。

Answer 1

ガベージコレクション

メモリに関してはガベージコレクション(どこからも参照されなくなったら開放される)の仕組みを理解して上手く管理する必要があります。
グローバル変数を使用するとページを閉じるまでメモリが開放されず、他の変数との衝突が起きるリスクがある為、出来る限りグローバル名前空間を使用しないことを推奨します。
また、クロージャの扱いには気をつけてください。

• javascriptのクロージャでメモリリークが起こる場合(19932)｜teratail

'use strict';
(function () {
  function sum (a, b) {
    return Number(a) + Number(b);
    // a, b はガベージコレクションによって回収される
  }
  function multi (a, b) {
    return a * b;
    // a, b はガベージコレクションによって回収される
  }
  function sub (a, b) {
    return Number(a) - b;
    // a, b はガベージコレクションによって回収される
  }

  function main () {
    console.log(sum(1, 2));   // 3
    console.log(sub(1, 2));   // -1
    console.log(multi(1, 2)); // 2
  }

  main();
  // sum, multi, sub, main はクロージャで参照を保持するのでガベージコレクションでは回収されない(ページが閉じられるまでメモリを消費し続ける)
}());

prototype パターン

メモリ消費の観点では「prototype パターン」と「this パターン」で比較される事が多いようです。

• prototypeに関数を定義する価値は？(18137)｜teratail

'use strict';
function Hoge1 () {}  // prototype パターン
Object.defineProperty(Hoge1.prototype, 'foo', {  // prototype 拡張なので new Hoge1 する度にメモリを消費せず、メモリ消費が this パターンよりも少ない
  writable: true,
  enumerable: false,
  configurable: true,
  value: function foo () { console.log('Hoge1'); }
});

function Hoge2 () { // this パターン
  Object.defineProperty(this, 'foo', { // this 値に定義するので new Hoge2 する度に foo を生成してメモリを消費する
    writable: true,
    enumerable: false,
    configurable: true,
    value: function foo () { console.log('Hoge2'); }
  });
}

new Hoge1().foo();  // Hoge1
new Hoge2().foo();  // Hoge2

Re: ゲストユーザー さん

Answer 2

正しさについて

CoffeeScriptは本当に駄目なのか？
http://qiita.com/raccy/items/fae9fc5923d78112d935

CoffeeScript は JavaScript の危険な部分を無くそうと、下記のような工夫をしている。

プログラムの正しさという観点では上記の記事が参考になるかと思います。
という訳で早速CoffeeScriptの公式サイトで確認
Try CoffeeScriptのタブをクリックすれば対話シェルっぽい奴が出てきて動的にコンパイル結果を表示してくれます。

JavaScriptはAjaxの登場辺りで爆発的に人気が出てから、
最速のスクリプト言語に上り詰める程最適化の進んだ言語ですので、
明らかな浪費や無駄なループを回さない限りメモリや処理速度で困る事はないかと思います。

追記

関数定義は同一スコープ内では下で宣言して上で読み込める等の仕様で、
Badパーツにされてたかと思います。
ですので、CoffeeScriptではよほどなケース（Classのコンストラクタ等）以外では定義することが出来ず、下記一択となります。

# CoffeeScript
a = ->
  # 処理

# JavaScript
var a;
a = function() {
  // 処理
};

クラスやインスタンス的なものもCoffeeなら下記一択です。
一応JS的に懇切丁寧に書く事も可能です。

# CoffeeScript
class class1
  constructor: (@name)->
  amount: null
instance1 = new class1()

# JavaScript
var class1, instance1;
class1 = (function() {
  function class1(name) {
    this.name = name;
  }
  class1.prototype.amount = null;
  return class1;
})();
instance1 = new class1();

回答

インスタンス化によるメモリ浪費を防ぐため、不要なものはグローバル関数にしています。

これは逆では？
ガベージコレクションに乗せて殺す為にクロージャーに包んでローカルで宣言したほうが良さそうです。

JavaScriptにおけるメモリの浪費を避けるコーディング
http://utage.headwaters.co.jp/blog/?p=1116

「JavaScript ガベージコレクション」等で検索すると色々記事が出てくるので、シビアに追求するなら読んで見ると良いかと思います。

Answer 3

こちらの記述が参考になるかと思います。
http://postd.cc/javascript-best-practices-part-1/

グローバル変数で定義した連想配列の中に各関数を入れることで、
グローバル関数を1つに抑えるアプローチもあります。

var PROJECT = PROJECT || {};

PROJECT.class1 = function(){
 this.init();
};

PROJECT.class1.prototype = {
 init: function(){...},
 bindEvent: function(){...}
};

PROJECT.class2 = function(){
 this.init();
};

PROJECT.class2.prototype = {
 init: function(){...},
 bindEvent: function(){...}
};

// PROJECT内のSAMPLEキー内に連想配列を用意。
// もし、別箇所で既に設定されている場合、それを引き継ぐ。
PROJECT.SAMPLE = PROJECT.SAMPLE || {}; 

PROJECT.SAMPLE.class1 = function(){
 this.init();
};

PROJECT.SAMPLE.class1.prototype = {
 init: function(){...},
 bindEvent: function(){...}
};

Answer 4

これだけの情報ではなんともいえませんが、
効率なんて数十万も数百万もインスタンスを作ったりするのでなければ過度に気にする必要はありません。
あなたにとって書きやすい書き方が最も正しいです。