優れたプログラムとは (2)

 前回の続きです。

○モジュール設計

 優れたプログラムは、極めて慎重にモジュール設計がなされています。機能ごとに分けられたコンポーネントや適切に階層化されたレイヤーは、なるべく互いに関係性を持たないように区切られています。

 例えば、上位に位置する層はOSやRDBMSに直接アクセスすることはありませんし、逆に下位層がユーザーインターフェイスの変更に影響を受けることはありません。重要なのは、そのモジュールをいかに外部を意識しないように作るか、ということです。

 参照する側の事情に左右されない独立性・汎用性が、設計のカギとなることでしょう。オブジェクト指向言語においては、これら論理構造上の区分けは、クラスの階層やJavaのpackageなどでより明示化された実装が可能となります。

○疎結合性を阻害するスコープの問題

 プログラム品質を決定づける大きな要因の一つがスコープです。スコープが広がれば広がるほどプログラム品質は低下します。もしスコープが当該モジュール外に出ている要素が存在していたり、他モジュールと密接なインターフェイスを持っている場合、このモジュール内でのプログラム修正は慎重に行わなければなりません。他モジュールへの影響を考慮しなければならず、厳密にソフトウェアの品質を保つのであれば、影響箇所すべてを再テストする必要があります。

 あらゆる要素のスコープは可読性を損なわない範囲で可能な限り狭めるべきであり、モジュール間の関係性をなるべく減らすことがプログラム品質を保ち、テスト工数を圧縮する重要なポイントであると私は考えます。スコープ拡大の元凶であるpublic staticは、可読性の向上以外に使用用途はほぼないといっていいと思います(逆説的に聞こえたかもしれませんが、public staticにはラベリング、ユーティリティやプロセス一意であることの明示化という可読性向上の用途があります)。

 またスコープはその要素への実際のアクセスに関係なく、範囲が広がるだけで疎結合性を低下させます。その要素へのアクセスを適切に遮断しておかないと、いつその要素の状態・振る舞いを変化させるコードの修正が行われるか分かりません。これは設計者の意図しない結合度の増加を招く原因となり、修正者がコードに手を加えるたびにソフトウェア全体の品質を徐々に劣化させてしまう危険性を孕んでしまいます。特にコードの修正・追加が頻繁に発生する保守工程における結合度では、このような実際の参照関係を元にした指標値よりも、スコープ範囲を考慮した潜在的な結合度の方が重要な指標となるでしょう。

○疎結合性と可読性

 疎結合性を実現する上で注意すべきことは、疎結合を意識するあまりソースコードの可読性を損ねてしまう可能性が出てくることです。極端な例ですが、例えばすべての引数をバイナリ型で受け取ってしまえばいろんな仕様変更にも耐えられるよね、というような意見にどれだけの人が賛同できるでしょうか。

 前回ではプログラミング言語の進化は疎結合性・再利用性の追求だと述べました。実際、近年のプログラミング言語には、非常に強力な疎結合性を兼ね備えた言語仕様がいくつか見受けられます。これは疎結合性がプログラム品質の観点から十分に議論・分析が行われてきた結果であり、プログラム開発の目指すべき目標を考えれば言語仕様の正当な進化であるといえると思います。しかしその一方で明快な指標を持ちにくいソースコードの可読性については、幾分進歩が遅れているのではないかという危惧を持っています。例えばJavaScriptの動的にメンバを追加できる言語仕様は、可読性の観点から若干の問題を孕んでいるといえるかもしれません。

 疎結合性と可読性。

 このバランスこそが優れたプログラムを作成する上で極めて重要なポイントだと私は考えます。

 次回に続きます。

前の記事| 全コラム一覧へ

コメント

επιστημη 2012年12月12日 (水) 11:38

もーちょい深いところでは、"粒度と一貫性"が出てきそうに思います。
「プロジェクトひとり」ならそうでもないのですが、複数の
設計者/実装者が多数になると粒度とスタイルがどうしてもバラつき、
結果的に疎結合性/可読性を落としがちになるかな、と。

玄米茶 2012年12月12日 (水) 23:37

おっしゃる通りだと思います。

本文では漠然とした話しかできませんでしたが、粒度の話は可読性の問題を具体的にあらわすことのできる非常に重要な観点だと思います。

次の回では「基底クラスなどの論理階層上の低位モジュールの設計は(本来)上流工程従事者がやるべき」というような話をしようと思ってるんですが、粒度の問題はまさにこれに当てはまりますね。
全体を見渡すことのできる上流工程従事者にしか粒度を考慮した設計はできないわけですから。

次の回でこの話を使わせてもらうかもしれません。
コメントありがとうございました。

επιστημη 2012年12月13日 (木) 08:06

基底クラスもそうだけど、ライブラリ/ユーティリティに相当するあたりもいい感じで制御しとかんとコード・クローンが蔓延したり。

みながわけんじ 2012年12月13日 (木) 14:03

最近では、逆に、メンバー変数へのアクセスをなくし、staticメソッドにすることが推奨されているそうです。私は読んだことはないですが、Readable Code という本には、

「クラスのメンバへのアクセスを制限するもう一つの方法は、メソッドを出来るだけstatic にすることだ」

と書かれているそうです。

http://sanematsu.wordpress.com/2012/08/13/readable-code/

επιστημη 2012年12月13日 (木) 16:46

ごめんなさい、わからんかった。↑の「逆に...」とは何に対して、ですか?

みながわ 2012年12月13日 (木) 19:45

玄米茶さんはpublic staticはスコープを広げる、との意見であるが、その逆という意味です。ただし、玄米茶さんはpublic static変数のことを言っているのかpublic staticメソッドのことを言っているのか不明なので、なんともいえません。私も「逆に」を入れるべきか、入れないべきか迷いました。

もし玄米茶さんがスコープをせまくするのが良いプログラムだとすれば、static public変数を極力少なくするだけでなく、メンバー変数もクラス内に限定されたグローバル共有変数なので、極力少なくされたほうがよろしいです。

http://blogs.wankuma.com/rti/archive/2011/07/18/201127.aspx

その結果、ここに書かれているように、staticにしてもかまわないメソッドが多数できることになります。要するにライブラリ関数のようなメソッドばっかりになる。
そんなことができるのかと疑問に思うかもしれません。

非オブジェクト指向言語の場合は、引数が多くなったりポインタを使うのが面倒で、横着なことにグローバル変数を使ってしまうことがありましたが、オブジェクト指向言語はインスタンスをメソッドの引数やリターン値に使えるので、メソッド内部でグローバル的な変数やメンバー変数の利用を避けることができるので、意外にもstatic publicメソッドを使って、スコープが究極に狭いプログラムを作ることができるんです。

フレームワーク技術の観点からすると、public staticメソッドはポリモーフィズムによるオーバーライドができないので、アプリケーション・カスタマイズには不向きですね。

επιστημη 2012年12月13日 (木) 21:44

あー、なるほど。

オブジェクト指向が流行りはじめた頃、"software-IC"と例えられてました。
機能単位をオブジェクトの形でまとめると、その中でどんなにややこしいこと
やっていようが利用者は気にすることなく、ICのピンを電線で繋げばモノ作れる。
で、ピンを繋ぐのはstatic publicでええやんか。ってなノリですかしら。

インスタンス・メソッド(non-static)が定義できるからこそ、
クラス・メソッド(static)の繋ぎ合わせで書けるわけで、
「インスタンス・メソッドなんか要らないよ」にはならんですけどね。

επιστημη 2012年12月14日 (金) 03:41

...いかんいかん、わかった"つもり"になってた。

グローバル変数は:
誰でも/どこからでも/どんな順序ででもアクセスできる。
→ スコープ広すぎ。危険。
→ 極力減らそう。最終的にはなくしてしまおう。

てのは理解できるのですが、まったく同じロジックで:

public static メソッドは
誰でも/どこからでも/どんな順序ででも呼び出せる。
→ スコープ広すぎ。危険。
→ 極力減らそう。最終的にはmainひとつにしてしまおう。

と「ならない」のはナゼなんでしょか?

みながわけんじ 2012年12月14日 (金) 17:29

基本的には、staticであろうが、なかろうが、publicなら、どこからでも呼び出せるわけです。

スコープの狭いことに執着するプログラマーはpublc staticメソッドはメンバー関数にアクセスしない(確かできない)し、public static変数も読み出ししかしません。良いプログラマーはそうです。ダメプログラマーはスレッドセーフなどの原則がわからないので、public staticメソッドでpublic static変数に書き込みをしてしまいます。結果として不安定な動作をするプログラムができてしまいます。

staticでないpublic メソッドは、インスタンスごとに違う状態をメンバー変数に持ってますから、スレッドセーフの原則がわからないプログラマーでも安定した動作をするプログラムを作ることができます。

public staticはライブラリ関数と同じなので、作ったり使ったりすると便利なのです。たぶん日本のプログラマーは欧米と比べるとレベルが低すぎるのでスレッドセーフの原則もわからない人が多いからだと思います。public staticメソッドは欧米のサンプルコードでも多く見かけます。

それだけ、日本のIT業界はガラパゴス化している。日本の高校までの教育レベルは世界一だと思いますが、学校の勉強ができるからといって職業としてITをやっていけるかというと問題であるし、受験英語しかできない。グローバルコミュニケーションができない。

通りすがり 2012年12月14日 (金) 18:33

> staticでないpublic メソッドは、インスタンスごとに違う状態をメンバー変数に持ってますから、スレッドセーフの原則がわからないプログラマーでも安定した動作をするプログラムを作ることができます。

メンバ変数も、スレッドセーフの原則がわからないプログラマにかかると、とても危険なことになり得ます。

例えば、ここなんかを参照して下さい。
『[実装編]スレッドセーフにすることを忘れてはいけない』
http://itpro.nikkeibp.co.jp/article/COLUMN/20070820/279950/

通りすがり44 2012年12月14日 (金) 19:32

みながわさんを見てると、野球を3年ぐらいやっただけの人が、イチローにバッティング論を説いてるような印象を受けますね。イチローが誰だか知らないで言ってる。
これじゃあ、おおふじさんも、擁護のしようがないわな。

自分のコラムやブログではコメント受け付けてないくせに、コミュニケーションができてないとか、どの口が言ってるの?

staticとか疎結合の意味わかってますか?

あとそれから、オブジェクト指向がテーマでも、きちんと書けば炎上なんかしませんよ。
炎上するのは、コラムのテーマではなく、コラムニストの人格に問題があるんですから。

玄米茶さんの書いてるのは、しごく真っ当なことなので炎上しようがないでしょう。

επιστημη 2012年12月14日 (金) 20:44

> たぶん日本のプログラマーは欧米と比べるとレベルが低すぎるので
> スレッドセーフの原則もわからない人が多いからだと思います。

理由になってないんじゃないかなぁ。
シングルスレッドであってもスコープ云々には関係ないし。

僕が思うに、たくさんの処理がprivate/protectedに追い出されることにより、
残ったpublic staticが制御/管理可能な程度に少なく(かつシンプル)になり、
「スコープ広いけど危険は少ない」が実現できるってことじゃないかと。

Soda 2012年12月14日 (金) 21:35

>みながわけんじさん
>「クラスのメンバへのアクセスを制限するもう一つの方法は、メソッドを出来るだけstatic にすることだ」

static宣言により、static以外のメンバは使えなくなるので、利用範囲を制限しているってのは正しいのですがー
staticにすることとpublic staticにすることは違うわけで、別次元の話を1つにしているように見えますね。

>オブジェクト指向言語はインスタンスをメソッドの引数やリターン値に使えるので

地味に意味がわからないんだけど、それって、オブジェクト指向言語じゃなくても似たようなことはできるんじゃ?
そして、

>意外にもstatic publicメソッドを使って、スコープが究極に狭いプログラムを作ることができるんです。

いやいや、static publicなんて、スコープとしては一番広いというか、大きいじゃないですか。
おそらく・・・
「なんに対してのスコープなのか?」というレベルでスコープという言葉の使い方が違うんだと思うのですが(^^;

>επιστημηさん
>と「ならない」のはナゼなんでしょか?

これは、データをどこが管理しているか?っていう視点で考えるのではないかと。
オブジェクト指向的には、データは用意したクラスが管理し、メソッドで操作するので、
メソッドのスコープが広いことで、データが操作できてしまうのがリスクですよね?

じゃーデータをクラスに持たないと考えたらどうなるか?
みながわけんじさんの理想を追求すると、public staticなメソッドしかないクラス・・・
C#なら、static classとして宣言するようなものですね。
つまり、ライブラリなので、スコープが広くても、どんな順番で呼んでもOKになるわけです。

この辺は、データをどう扱うのがいいのか?ってな話で、なにが正しいってのはないはずなんですよねぇ。
多種多様なデータを同じものとして扱いたい・・・
つまりデータは違うけどやることは同じって場面が多いほど、オブジェクト指向にメリットがでるじゃないですか。
その逆で、データは同じだけど、やることが沢山あるってな場合だと、オブジェクト指向の恩恵も少ないのかなと。

私は、クラスの主役は、メンバ変数がもつデータだと思うんですよねぇ。
だから、みながわけんじさんの

>メンバー変数もクラス内に限定されたグローバル共有変数なので、極力少なくされたほうがよろしいです。

この考え方は、クラスとしては、発想が逆に感じるんですよ。
データが先にあって、その操作にメソッドを用意するわけで、少なく出来るってのは、
設計が間違ってるというかー無駄なデータがあっただけだと(^^;

データのことを一番知ってるのは、そのデータ自身なわけでー
じゃーそいつに全部まかせてしまえーってのが、オブジェクトの真髄だと思うのですよ。
自己完結しているから、他と組み合わせしやすく、取り替えやすい。
おまけに上位互換も簡単に作れるんだから、ただのライブラリとして使うのはもったいない。

まぁ、扱ってるデータにもよるし、過去の遺産との関係もあるからー
実際問題として、現状で問題ないなら、それがその会社や人にとってはベストなんだろうなと。
そして、自分のベストが他人のベストとは限らないという単純な話・・・かな。

επιστημη 2012年12月14日 (金) 22:10

>> メンバー変数もクラス内に限定されたグローバル共有変数なので、
>> 極力少なくされたほうがよろしいです。
>
> この考え方は、クラスとしては、発想が逆に感じるんですよ。
> データが先にあって、その操作にメソッドを用意するわけで、少なく出来るってのは、
> 設計が間違ってるというかー無駄なデータがあっただけだと(^^;

いや、僕はコレに関してはすんなり呑み込めました。
「関係の深い変数がいくつかあるならそいつらまとめてクラスにしよぉ」
ってことならば。

int x; int y; int z; なんてのを
Point3D point; にまとめて減らせる。ちゅーことかと。
あるいは int size; int capacity; string* data; を
vector strings; とか。
メンバが抱えるデータの総量は変わらんけども気にせんならんことは減るわな。

通りすがり 2012年12月14日 (金) 23:43

なんというか、mutable/immutable、const/非const、副作用あり/なしあたりの話と、スコープの話と、static/非static、public/非publicあたりがごっちゃになってる気がします。

玄米茶 2012年12月15日 (土) 02:35

>public static変数のことを言っているのかpublic staticメソッドのことを言っているのか不明なので

public static修飾子のついたすべての要素のことを言いました。

>メンバー変数もクラス内に限定されたグローバル共有変数なので、極力少なくされたほうがよろしいです

Sodaさんの意見に共感できます。
そもそもメンバのインスタンスにアクセスする必要のないメソッドがそのクラスに属していることにあまり意味はありません。staticメソッドが増えるということは、みながわさん自身がおっしゃるようにライブラリ関数のようなものばかりになりますが、このような使い方はいわゆるbetter Cというやつですね。オブジェクト指向である意味は薄れます。小さなライブラリ群を開発する場合はこういう使い方でも構わないと思いますが、コラム本文でも言っているようにできれば工学的な見地で議論をしたいと思ってコラムを書きました。

>スレッドセーフなどの原則がわからないので、public staticメソッドでpublic static変数に書き込みをしてしまいます

スレッドセーフの話は、staticうんぬんよりも排他制御の話ですよね。
staticであろうとなかろうと排他制御が必要なところには必要ですよね。
通りすがりさんのご指摘が当を得ていると思います。

玄米茶 2012年12月15日 (土) 02:59

>インスタンスをメソッドの引数やリターン値に使えるので

みながわさんの意見で共感できるところはここでしょうか。
オブジェクト指向言語の本質はオブジェクトの受け渡しだと思います。
カプセル化やポリモーフィズムを適切に使用することで再利用性・疎結合性に繋がっていくと。
私は第一義的にポリモーフィズム等を挙げるようなオブジェクト指向の説明・教育には疑問を持っています。

επιστημη 2012年12月15日 (土) 07:28

>>インスタンスをメソッドの引数やリターン値に使えるので
>
> みながわさんの意見で共感できるところはここでしょうか。
> オブジェクト指向言語の本質はオブジェクトの受け渡しだと思います。

同意。ただ、「データのまとまりを受け渡し」であれば構造体で実現できるので、
キモとなるのは「データのまとまりを"メソッドごと"受け渡し」できるてとこかな。
ここでいうメソッドはもちろんnon-static、だからデータが"自立"できる。

> 私は第一義的にポリモーフィズム等を挙げるようなオブジェクト指向の説明・教育には疑問を持っています。

これまた同意。社内で講師を頼まれることがちょくちょくあり、僕は「ADT(抽象データ型)」から入ります。継承もポリモーフィズムもADTを支える脇役的位置づけで。

Soda 2012年12月15日 (土) 08:14

>επιστημηさん
>Point3D point; にまとめて減らせる。ちゅーことかと。

その発想は無かった、そういう発想もありますねぇ。
でも、スコープの話だったからー
必要なデータとしてみると減ってないので、スコープ的な意味では、あまり関係なさそう。

>玄米茶さん
>オブジェクト指向言語の本質はオブジェクトの受け渡しだと思います。

受け渡しだけなら、オブジェクト指向言語じゃなくてもできると思うんですよ。
むしろ、

>カプセル化やポリモーフィズムを適切に使用することで再利用性・疎結合性に繋がっていくと。

こっちの仕組みが言語レベルで入ってるってのが、うまみかなと。

>私は第一義的にポリモーフィズム等を挙げるようなオブジェクト指向の説明・教育には疑問を持っています。

プログラムコードにしてしまうと、ポリモーフィズムが一番明確に差がでるから・・・かな?
カプセル化は、自己責任という言葉で無効化されやすいし・・・
データの振る舞いについては、ライブラリ的な関数を使う場合と何が違うのかがわかりにくい・・・
まぁ、自分の場合はそうだったってだけですがw
構造体に関数が付けれてなにがおいしいのか、わからなかったってのがクラスの第一印象w
ポリモーフィズムにであって、価値観というか、データのおき場所の違いに目が向いたんですよ。

PS.
あぁ、確認段階でεπιστημηさんのコメントがーw
なるほど、「インスタンス」から「オブジェクト」に変わってたのかー
でも、関数ポインタとかもあるから、やっぱり受け渡しだけなら、できそうな気が・・・
イメージしているのが、CとC++なのがイカンのか?w

επιστημη 2012年12月15日 (土) 08:25

> でも、関数ポインタとかもあるから、やっぱり受け渡しだけなら、できそうな気が・・・

できますし、いっぺんやりました。
C++コンパイラがやってくれてることをぜーんぶ自前でごりごりと。
どえらくたいへんなのよ。やれるけど、やってられない。

みながわけんじ 2012年12月15日 (土) 13:40

>Sodaさん

>staticにすることとpublic staticにすることは違うわけで、別次元の話を1つ>にしているように見えますね。

だから、玄米茶さんは、「public staticがスコープを広げる元凶」と書いています。この理由がわからないし、public static 変数なのか、メソッドなのか明確に書いていないからです。意図>オブジェクト指向言語はインスタンスをメソッドの引数やリターン値に使えるので的に別次元に話を一つにしているわけでもないのです。

>オブジェクト指向言語はインスタンスをメソッドの引数やリターン値に使えるので
>地味に意味がわからないんだけど、それって、オブジェクト指向言語じゃなくても>似たようなことはできるんじゃ?

オブジェクト指向の最大の特徴です。非オブジェクト指向言語では、数値、ポインタ、文字列、配列、構造体のようなものにデータとして扱う対象が限定されていましたが、自由にクラスを設定できるようになりまいた。「オブジェクト指向言語じゃなくても似たようなことができる」ならば例を示さなければ、無効な意見です。

>いやいや、static publicなんて、スコープとしては一番広いというか、大きい>じゃないですか。
>おそらく・・・
>「なんに対してのスコープなのか?」というレベルでスコープという言葉の使い方>が違うんだと思うのですが(^^;

あの~、何回も言いますが、static public っていう場合、変数なのか、メソッドなのか判別できるように書いてください。単に語彙だけで意見を判断するのは愚かなことです。
メンバーやpublic static 変数を含まない、public staticメソッドは、そのメソッド内でスコープが限定されているので、玄米茶さんの言うところの良いプログラムに分類されいるということです。staticがあるうが、なかろうがpublicはどこからでのアクセスできる、これはすでに私はコメントしましたよね。Sodaさん人の意見をよく理解してコメントしてくれませんか?

>私は、クラスの主役は、メンバ変数がもつデータだと思うんですよねぇ。

Visual Studio で、フォームを作った場合、自動的にクラスが生成され、GUIコンポーネントはメンバー変数と同じ動作をします。
GUIコンポーネント画面はもちろん、これでかまいません。

メンバー変数を状態変数として扱う場合、たとえばシステムハングなどでサーバーを再起動すれば、その状態変数の値が消えてしまします。状態はDBに登録しないと消えてしまうので、その意味で、メンバー変数を状態変数と扱うのは不十分です。
簡単なゲームには使えますが、クリアに何日もかかるゲームには、すでに不向きです。スクウェア・エニックスの社長が「わが社の公用語はC言語」と言ったのが名言です、ゲーム会社でも公用語は非オブジェクト指向言語なのですね。

>まぁ、扱ってるデータにもよるし、過去の遺産との関係もあるからー
>実際問題として、現状で問題ないなら、それがその会社や人にとってはベストなん>だろうなと。
>そして、自分のベストが他人のベストとは限らないという単純な話・・・かな。

そういうことです。Sodaさんも自分のブログをリンクしていますが、もっと自分の仕事の内容や技術的に勉強されたことをアップしたらいいと思います。

マジなディスカッションになると、サイトをリンクしてコメントしないと、その人のバックグラウンドや知識がわからいので、コメントで議論に参加しても、意見の裏付けがないので無視されがちです(根拠が薄いコメントは相手にしても時間の無駄)。

みながわけんじ 2012年12月15日 (土) 13:53

追伸、Sodaさん

>プログラムコードにしてしまうと、ポリモーフィズムが一番明確に差がでるか>ら・・・かな?

理由を述べてください。論理的な理由がないと、その意見は意味がないです。

>構造体に関数が付けれてなにがおいしいのか、わからなかったってのがクラスの第>一印象w
>ポリモーフィズムにであって、価値観というか、データのおき場所の違いに目が向>いたんですよ。

ポリモに出会って価値観がどうか変わったのか具体的に記述してください。

マジな議論をしているので、へたに雰囲気や印象のみの意見は、これ以上は無視させていただきます。時間の無駄ですので。

通りすがり 2012年12月15日 (土) 15:27

スクエニはC++もC#も使ってると思いますよ。ソースはスクエニの募集要項。

それと、データの永続化の話と、プログラム実行中に参照されるデータの話は別物ですね。どんなゲームでも言語が何であろうと永続化先が何であろうと、メモリにロードする必要があります。
OOでは、やはりインスタンスのメンバ変数が主役であることの間違いありません。

επιστημη 2012年12月15日 (土) 15:43

みながわさん:
> public static 変数を含まない、public staticメソッドは、そのメソッド内でスコープが限定されているので、玄米茶さんの言うところの良いプログラムに分類されいるということです。

ごめんわからんです。「1:public staticメソッドはどこからでも呼べる」はいいとして、「2:そのメソッド内でスコープが限定されている」は如何なる意味ですか?
public static メソッドの中では使えるクラス/インスタンスが限られる? そんなことないけど。

みながわけんじ 2012年12月15日 (土) 17:23

スコープが狭いメソッド、あるいはメソッド内でスコープが限定されているメソッドとは、メンバー変数にアクセスしないメソッドです。

つまりメンバー変数にアクセスしないことで、クラス内の他のメソッドとの干渉がないので、スコープはメソッド内。もしメンバー変数にアクセスしてしまったら、スコープはクラス全体ということになります(publicメソッドを呼び出す場合は、もちろんクラス全体から可能ですが、どこでそのメソッドが使われているか今の開発環境ならば、簡単に検索できるので問題視する必要なし)。

結果的にそのようなメソッドは状態変数が不要なので、インスタンスなしのstaticメソッドとなります。
ですから、staticメソッドを作る場合は、メンバー変数を使わない、使うとしたら引数に使うようにする。スレッドセーフにするためにpublic static変数に書き込みを行わない(読み込みはOK)、などの(Readableなコードを書くための)暗黙の原則があります。

>スクエニはC++もC#も使ってると思いますよ。ソースはスクエニの募集要項。

募集要項なんてあてになりませんよ。C++できたら、Cもできます。制約を厳しくして、優秀な人材を逃すのは適作ではないという判断からだと思います。

december28 2012年12月15日 (土) 17:31

横から失礼します。
みながわさん>

ちょっと質問させてください。

>この理由がわからないし、public static 変数なのか、メソッドなのか明確に書いていないからです。

なんて書いているのに、

>public staticはライブラリ関数と同じなので、作ったり使ったりすると便利なのです。

などと平気で書いていますが、これは変数のことですか?メソッドのことですか?
ライブラリ関数と書いているので、まあメソッドのことでしょうけど。

public static メソッドは確かに便利です。しかし、その便利さは状態を扱えないために限定的なものでしかないでしょう。
たとえば、一般的な業務アプリケーションは、ユーザがログインして使用を開始し、ログアウトすることで使用を終えます。
複数のユーザが別の画面を開けば、ユーザの数だけ「状態」がメモリ上に存在するわけです。

さて、みながわさんは、

>メンバー変数を状態変数として扱う場合、たとえばシステムハングなどでサーバーを再起動すれば、その状態変数の値が消えてしまします。状態はDBに登録しないと消えてしまうので、その意味で、メンバー変数を状態変数と扱うのは不十分です。
>簡単なゲームには使えますが、クリアに何日もかかるゲームには、すでに不向きです。

とおっしゃってますが、ひょっとして、状態を全てDBに登録しているのでしょうか?

ここで言う「状態」とは、次のようなものです。
たとえば、あるWebアプリケーションシステムに、伝票入力画面があるとします。
この画面は、[入力画面] → [確認画面] → [完了画面] と遷移する仕様になっているとします。
あるユーザが、この画面を開き、交通費などを入力して、確認ボタンを押します。
勘定科目などがチェックされて、合計金額が計算されて、確認画面が表示されます。

ここでユーザが入力した「交通費」が「状態」です。
普通ならこれを、static ではないメンバ変数にセットして、セッションに格納するなどして、維持すると思います。
もちろん、この時点でサーバが落ちれば、この「状態」は消えてしまうことになります。
みながわさんは、それを防ぐために、DBに格納する、と、そうおっしゃっているのでしょうか?

みながわさんが普段手がけていらっしゃるのが、みながわさんの言う「簡単なゲーム」のようなシステムならば納得ですが、
私が普段やっているような、複数のユーザが同時にログインして使用するWebシステムでは、
「状態をDBに登録する」なんてことは、ちょっと常識外なので、質問させていただきました。

通りすがり 2012年12月15日 (土) 17:35

エピステーメーさん(コピペできない環境なので、正しく表記できなくてごめんなさい)。

私が説明することでもありませんが、それはpublic staticメソッドがメソッド内にstatic変数をもたず、クラス変数も参照しないものであれば、そのメソッドはそこで閉じているので、その内部と外部は粗結合であり、玄米茶さんの言う良いコードに該当するということだと思います。

ちなみに私は、それってCの単なる独立した関数と意味的に変わらないよねと思いますが。

通りすがり 2012年12月15日 (土) 17:42

おっと、コメントを書いていたらみながわさんがコメントしてましたね。

みながわさん。
実際にスクエニの募集要項を見ましたか?
FFやドラクエのプログラマー募集要項には、「ていねなクラス設計ができる方」なんて書かれてます。
また、検索すると、ドラクエXのゲーム部分はC++で書かれているという情報がヒットします。

通りすがり 2012年12月15日 (土) 17:50

連投すみません。

みながわさん、スレッドセーフにするには書き込み側だけ意識すれば良いというのは違います。書き込み処理の前の読み込みにはロックを掛ける必要がある場合があります。連続する二行の読み込み処理の場合も、ロックを掛ける必要がある場合がありますよ。

επιστημη 2012年12月15日 (土) 18:01

> ちなみに私は、それってCの単なる独立した関数と意味的に変わらないよねと思いますが。

うん。まさしくそのとおり。
スコープの広い変数にアクセスしない「行儀のよいCプログラム」と大差ないすね。

Soda 2012年12月15日 (土) 22:51

>みながわけんじさん
>だから、玄米茶さんは、「public staticがスコープを広げる元凶」と書いています。

たぶん、根本的なとこで話がかみ合ってないと思うのですがー
privateな変数や関数をstatic指定するのと、public static指定するのではスコープが違うでしょ?って話ですよ。
玄米茶さんはpublic staticというもっともスコープが広いものを例として出しただけですよね?
おそらくというか、publicの有無が一番大きな話でstaticが付くとさらに広くなるというだけじゃないかなぁ。

で、スコープってのは、どこから見えるのかって話なわけでー

>スコープが狭いメソッド、あるいはメソッド内でスコープが限定されているメソッドとは、メンバー変数にアクセスしないメソッドです。

たぶんというか、他の方が使われているスコープってのは、そのような限定されたものではなく、
クラスの内外も含めた話だと思うのですよ。

>「オブジェクト指向言語じゃなくても似たようなことができる」ならば例を示さなければ、無効な意見です。

例って、ただの構造体を引数にしたり、戻り値にしたりすることはできますよね?
それで十分じゃないですか?
構造体の中に関数ポインタを含めれば、クラスに近いでしょ?
受け渡すだけなら、できるんですよ。
インスタンスなんて、auto変数と大差ないわけでー少なくとも関数に対しての引数や戻り値は、
オブジェクト指向言語だろうが、非オブジェクト指向言語だろうが、大差ないってのが私の主張。
逆に何を特別だと思っているのかってのが疑問なわけです。

>あの~、何回も言いますが、static public っていう場合、変数なのか、メソッドなのか判別できるように書いてください。

書く必要がないんですよ、どっちもなんだから。

>staticがあるうが、なかろうがpublicはどこからでのアクセスできる、これはすでに私はコメントしましたよね。

そう書いてあるから、なおさらわからないって話ですよ。

「どこからでもアクセスできる=スコープが広い」

おそらく、スコープという言葉は、そのように解釈されるのが一般的であり、
玄米茶さんもそのような意図と使われていると読めます。
でも、みながわさんの使うスコープは、上で説明されている通り、他の人と違う意味で使われているから話が合わないって思うのですよ。
つまり、

みながわさんのスコープ = クラスから見ているクラス内の範囲
他の人のスコープ    = クラスの外から見える範囲

というように、見ている場所と方向が違うのではないか?ということです。
スコープという言葉の意味が同じでも、適応している場所が違えば、話が合わないってことです。

>Sodaさんも自分のブログをリンクしていますが、もっと自分の仕事の内容や技術的に勉強されたことをアップしたらいいと思います。

んー、私自身の話はあまり関係ないと思うんですよねぇ。
外部リンクで説明しないといけないほどの内容は無いと思いますし・・・
どんな人がコメントしているか?よりも、コメント自体に目を向けて欲しいなと思うわけでー
自分にとって特殊だと思える内容であれば、そう書きますし、そうでないなら、それは、私にとっては特殊ではないってことです。

>>プログラムコードにしてしまうと、ポリモーフィズムが一番明確に差がでるか>ら・・・かな?
>理由を述べてください。論理的な理由がないと、その意見は意味がないです。

ん?続けて書いてありますよね?消去法の結果ですよ。
非オブジェクト指向言語で記載した場合、一番類似したコードが書きにくいし、書けたとしてオブジェクト指向言語ほどスッキリ
かけないでしょ?

>ポリモに出会って価値観がどうか変わったのか具体的に記述してください。

本編とは関係ないし、ここで書くのはどうかと思うので、(^^;
http://d.hatena.ne.jp/Deppi/20121215
ただ、価値観って人によって違うから、具体的に書いてもあまりやくにたたないんじゃないかなーと思うのですが(^^;

>C++できたら、Cもできます。

それは成り立たない場合がありますよ。
少なくともクラスを使ってた人がC言語で同じようなコード書けるか?といえば相当疑問。
逆はYesなんですけどねぇ、どこの世界でも下位互換ってのは難しいんじゃないかと。

みながわけんじ 2012年12月16日 (日) 18:44

december28

>ここでユーザが入力した「交通費」が「状態」です。
>普通ならこれを、static ではないメンバ変数にセットして、セッションに格納す>るなどして、維持すると思います。

私の会社および取引がある業者では、これは普通でないです。あなたは当然、これが普通だと思っているので仕方がないですね。話がかみあわなくて当然です。

みながわけんじ 2012年12月16日 (日) 19:33

Sodaさん

関数ポインタなど、そでにコメントで出た話なので、あなたのコメントは、あくまでも世間一般的に言われていることを言っているだけなので、時間が無駄なので読む気がしません。

私の考えているスコープについてのコメントもよく読んでいませんね。

C++ができてCができない人のC++プログラムなんて、まったく信用できません。そういう人は、スキルがあると評価してはいけないでしょう。

あたたのブログを見てると炎上ブログの話ばっかりで、技術的なものが感じられません。そのような人コメントは、警戒されますよ。

みながわけんじ 2012年12月16日 (日) 19:39

通りすがりさん

http://www.jp.square-enix.com/recruit/fresh/recruit/information.html

スクエア・エニックスの 募集要項は具体的な言語などは記載されてませんでした。
プログラミングは下請け、フリーエンジニアに任せるということでしょうか?
実際にゲームアプリの開発をやっている人に意見を聞きたいところですが、そのような人は、@ITなんて読んでませんし、コメントなんて書かないでしょうね。誰かゲーム会社で働いている知り合いしってませんか?

keeper 2012年12月16日 (日) 21:00

興味深くROMってましたが、びっくりしたことがあったので質問です。

december28さん>
>ここでユーザが入力した「交通費」が「状態」です。
>普通ならこれを、static ではないメンバ変数にセットして、セッションに格納するなどして、維持すると思います。
>もちろん、この時点でサーバが落ちれば、この「状態」は消えてしまうことになります。
>みながわさんは、それを防ぐために、DBに格納する、と、そうおっしゃっているのでしょうか?

みながわさん>
>私の会社および取引がある業者では、これは普通でないです。
>あなたは当然、これが普通だと思っているので仕方がないですね。
>話がかみあわなくて当然です。


びっくりしたというのはここです。
確認ですが、みながわさんの会社や取引のある業者さんでは、ユーザが入力した「交通費」のような「状態」を、DBに格納しているんですか?
最終的にDBに登録するのはもちろんですが、その前の確定しない「状態」を、いちいちDBに登録しているということでしょうか?
ブラウザからリクエストを投げた情報は、そのままメモリ上で操作するのが普通なのではないでしょうか?
それをいちいちDBに格納するとおっしゃってるんでしょうか?

話がかみあわなくて、と言っているのは、何か勘違いされているのではないかと思います。
通りすがりさんが言っているように、「データの永続化の話と、プログラム実行中に参照されるデータの話は別物」なのを、混同されているのではないでしょうか?


Soda 2012年12月17日 (月) 00:53

>みながわけんじさん
>関数ポインタなど、そでにコメントで出た話なので、あなたのコメントは、あくまでも世間一般的に言われていることを言っているだけなので、時間が無駄なので読む気がしません。

いや・・・なんていうか・・・例を出せって言ったのは、みながわけんじさんですよね?
私は、特別なことを言ってるわけじゃないので、そういわれても困るのですが・・・

その・・・よくわからないのですが、例として適切ではないという意見でしょうか?
つーか、「世間一般的に言われている」ことと認識しているなら、なんで例を求められたのかわからんのですが・・・
それとも別の話と混ざってます?

>私の考えているスコープについてのコメントもよく読んでいませんね。

ここもよくわからないのですが・・・私がなにか誤読しているという主張ですよね?
元がpublicのメンバ変数や関数をpublic staticにすると、インスタンス以外からもアクセスできるようになってしまいスコープが広がるじゃないですか。
staticでスコープが狭くなるものと広くなるのもがあるって話ですよ?

>C++ができてCができない人のC++プログラムなんて、まったく信用できません。

最近じゃーC言語を覚えてからC++って流れじゃなくて、最初からC++って流れのほうが多いと思うのですよ。
C++固有の機能に慣れた人は、固有機能の代替ができないと、C言語でプログラムが書けないわけです。
代替ってのは、近似したコードであったり、根本的な構造の考え方の変化だったりイロイロですがー
似て非なる言語なので、主は根本的な構造の考え方の変化でしょう。
だから、C++では作れても、Cでは作れないってのは、結構あるパターンだと思うわけです。
C++で作れるスキルと、C言語で作れるスキルは別物って主張ですよ。

>あたたのブログを見てると炎上ブログの話ばっかりで、技術的なものが感じられません。

特に技術的なブログを目指してないので、当たり前ですが(^^;
それ、なにか関係あるんですか?
誰が書いているか?よりも(コメントが)何て書いてあるか?ってほうに重点を置いてみて欲しいなぁと思うのですが・・・

みながわけんじ 2012年12月17日 (月) 08:16

keeper さん

あなたの主張や書き方がごもっともです。
「最終的にDBに登録するのはもちろん」
と書いてあれば、私ももちろんOKです。

december28さん>
>[入力画面] → [確認画面] → [完了画面]
この書き方ではDBに登録しなで完了(終了)と思ってしまいます。

december28 2012年12月17日 (月) 09:16

みながわさん>
表面的な語彙だけではなく、内容をしっかり読んでいただけないでしょうか。
私が質問したかったのは、途中の状態をいちいちDBに登録しているのかどうかであって、最終的にDBに登録するのかどうかは、この際、関係ないのです。
もう一度、質問にお答えいただけないでしょうか?

通りすがり 2012年12月17日 (月) 10:46

みながわさん。

キャリア採用のページから、いろいろリンクをたどってみて下さい。
http://www.jp.square-enix.com/recruit/career/index.html

C++やC#プログラマを求めています。

BT 2012年12月18日 (火) 11:01

PS VITAはC#やVisualStudio
XboxやWindowsゲーム用はC++
PS3もC++
ゲーム用途はオブジェクト指向ですね。
Cも全く使ってない訳ではないみたいですが。

玄米茶 2012年12月18日 (火) 12:19

みながわさんの文章がどうも関数型言語のことを言っているように見えたので、その観点からの私の見解を述べますね。

関数型言語の関数は副作用を持たないという原則がありますが、純粋に副作用を持たないモジュールのみで開発が完結できるソフトウェアの領域というのはきわめて少ないと思います。
実際、関数型言語の中には副作用を許容する仕組みを取り入れたものもいくつかありますし、今はやり(?)のscalaは関数型言語の特徴ばかりが取りざたされますが、結局のところあれはオブジェクト指向言語であり、必ずしもscalaで作られたプログラムが関数だけで成り立っているわけではありません。

関数型言語の利点は、簡潔にコードが書けるということと副作用がないことの明示化であり、主に可読性の向上にあると思います。
プログラム中の副作用を必要としない部分を注意深く切り取り、モジュール化し、その部分のみを関数で記述する、という使われ方ではないかと私は推測しています。

また関数型言語の関数も(オブジェクト指向のインスタンスのように)きちんと変数にとるなどして、持ちまわることが基本になると思います。
そうすることで関数に施せる高度な仕組みを利用するからです。
public staticメソッドは、関数型言語の関数のように変数にとったり引数にとったりすることができませんし、カリー化などの高度な仕組みも持っていません。
単純な呼び出しの関係でしかないpublic staticメソッドは、実装依存という観点、またメソッド自身のスコープの広さから言って、結合度はそれほど低くはないと言えると思います。
結局のところ、副作用がないことの明示化という意味においてユーティリティや末端の処理などにしか活用できないと思います。
そしてこれは、コラム本文で「可読性向上のための用途がある」と述べた部分です。
決してpublic staticメソッドが疎結合性の観点から良いプログラムに分類されるとは思えません。

通りすがり 2012年12月18日 (火) 13:58

このコラムを初めて読んでから一週間ほどになりますが、「スコープ拡大の元凶であるpublic staticは」の意味がわからず依然としてモヤモヤしています。

「低い結合度」「高い凝集度」が良いのはほぼ自明だと思いますが、「public static」は結合度のどの部分に影響するものなんでしょうか?

クラス対クラス(あるいはインスタンス対インスタンス)が密に結合しているのは良くないし、同一クラスあるいは同一メソッド内に異なるレイヤーの処理が混在しているのも良くないというのはわかります。
それを解消するのに、OOのインターフェイスに対する実装とか、抽象と具象という概念が役立つというのもわかっています。

その上で質問したいんですが、public staticが結合度を阻害することを説明する例はありますか?

επιστημη 2012年12月18日 (火) 15:23

public static は他の public static をお構いなしに呼べるのでモジュールどうしの"糊"になり、
そのことが結合度を大きくしてしまいがちなんじゃないかと考えます。

みながわけんじ 2012年12月18日 (火) 15:52

http://ja.wikipedia.org/wiki/%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%97

によると、

「プログラミングでは、予期しない誤作動を避けるためにも、それぞれの作業段階で必要のない名前はできるだけ参照されないようにすることが望ましい(大域変数の危険性)」

ですから、スコープで危険性のあるのは、public static変数やメンバー変数の多用濫用であり、メソッドがpublicであるかは、それほど問題視されないというのが持論です。

メソッドは共有変数により干渉し複雑化する危険性があるという意味で、メソッド間の「糊」となるのは、共有変数です。

メソッド間の「糊」となるのはメソッドではありません。

そうでなければ、何故ライブラリ関数など安心して使えるのですか?

もちろん、すべて public staticで作れという意味ではありません。最近の開発ツールではフォームをつくるとクラスが自動的に生成されGUI画面のプログラムが簡単にできます。
あくまでも、スコープや「糊」とは何か?考えてみた自論です。

επιστημη 2012年12月18日 (火) 16:37

> メソッド間の「糊」となるのはメソッドではありません。

なぜ?

public class ModuleA {
public static void f() {
ModuleB.g();
ModuleC.h();
ModuleD.i();
}
}

ModuleA.f() を使うには ModuleB/C/D を連れてこにゃならんです。
これが「糊」じゃなかったら何なんでしょ。

通りすがり 2012年12月18日 (火) 17:16

επιστημηさん。

なるほど。私は、public staticと聞くと、SingletonのgetInstance()や、完全に独立したUtility Classを思い浮かべて、それ自身にはそれほど問題はないのではと思っていたんですが、確かに
> public class ModuleA
のようなコードがあちこちに散らばっている状況を考えると、これは確かに萎えますね。

通りすがり 2012年12月18日 (火) 17:18

みながわさん。

> 最近の開発ツールではフォームをつくるとクラスが自動的に生成されGUI画面のプログラムが簡単にできます。

この話が何度か出てきましたが、本コラムとどういう関連性があるんでしょう?

επιστημη 2012年12月18日 (火) 20:54

こっち↓についても僕の見解を述べておきます。

> メソッド間の「糊」となるのはメソッドではありません。
> そうでなければ、何故ライブラリ関数など安心して使えるのですか?

public class ModuleA {
public static void f() {
 Lib.g();
 Lib.h();
 Lib.i();
}
}

いくら呼んでも連れてくるのは Lib ひとつ。
しかも Lib が ModuleA/B/C/D を呼んではいない。
統制が取れてるのよね。

Soda 2012年12月19日 (水) 07:00

>通りすがりさん
>> public class ModuleA
>のようなコードがあちこちに散らばっている状況を考えると、これは確かに萎えますね。

ん?通りすがりさんが言ってるように、完全に独立したクラスというかー
ライブラリ関数のようなクラスなら、ある程度結合度が高くても、いいんじゃないかなぁ?
上のεπιστημηさんの例も、

>ModuleA.f() を使うには ModuleB/C/D を連れてこにゃならんです。

機能別に分類したライブラリモジュールならOKじゃない?
この場合、クラス名はライブラリ名程度の違いしかないと思うのですよ。
だから2つの例に明確な差があるかというと、無いようにも見えるんですよねぇ。

ModuleBの中でModuleAを使うなど、相互に呼び出しているような結合度だと、駄目だとは思いますが(^^;
public staticだと大抵のことはできちゃうからなぁ(^^;
仕様変更とかあった場合に、モジュールとして差し替えにくいってのもイマイチかな?
まぁ、差し替えするようなものをpublic staticにするのがNGだと思うから、その心配はないのでしょうが(^^;

みながわけんじ 2012年12月19日 (水) 08:05

>επιστημη 2012年12月18日 (火) 16:37
>> メソッド間の「糊」となるのはメソッドではありません。
>なぜ?
>public class ModuleA {
>public static void f() {
>ModuleB.g();
>ModuleC.h();
>ModuleD.i();
>}
>}
>ModuleA.f() を使うには ModuleB/C/D を連れてこにゃならんです。
>これが「糊」じゃなかったら何なんでしょ。

public static void f()
でなくても
staticでないメソッド public void f()
クラスないのローカルメソッド void f()
でも、まったく同様のことが言えるので、何故public static メソッドがスコープを広げる元凶となるのか?という議題についての理由になっていません。

επιστημη 2012年12月19日 (水) 08:38

↑わけわからん。

public class ModuleA {
 // static でないメソッド
 public void f() {
  ModuleA.g();
  ModuleB.h();
  ModuleC.i();
 }
}

そう、まったく同様にstaticでないメソッドからも
public static メソッドが呼べてしまいます。
public static メソッドを定義するからこんなことが起こるんです。

public class ModuleA {
 // static でないメソッド
 public void f() {
  this.g();
  this.h();
  this.i();
 }
...
}

これならModuleAで閉じてるもの。

επιστημη 2012年12月19日 (水) 08:47

> ModuleBの中でModuleAを使うなど、相互に呼び出しているような結合度だと、駄目だとは思いますが(^^;

僕が「おっかない」と感じているのはまさにソレ。
綺麗なDAGになってりゃいいけどね。

public static メソッド、僕は否定しません。
「スコープ広いから注意しようね/乱用は禁物よ」ってだけのこと。

ナッシュビル 2012年12月19日 (水) 08:48


みながわさん>
ちゃんと日本語読んでますか?

「プログラミングでは、予期しない誤作動を避けるためにも、それぞれの作業段階で必要のない名前はできるだけ参照されないようにすることが望ましい(大域変数の危険性)」

要するに、スコープはできるだけ狭くしろ、ということです。
理由がなければ、public は使うな、という意味ですよ。

>メソッドがpublicであるかは、それほど問題視されないというのが持論です。

みながわさんの持論ですね、あくまでも。
それは間違いです。
意味もなくメソッドをpublic にするのは大問題ですよ。

>メソッド間の「糊」となるのは、共有変数です。

つまり、static変数ということですか?
メソッド間でデータを受け渡しするのに、static変数を使うんでしょうか?
それは、ものすごく危険ですね。

>最近の開発ツールではフォームをつくるとクラスが自動的に生成されGUI画面のプログラムが簡単にできます。

それは、このコラムの話題と何の関係があるんでしょうか?そんなことを得意げにひけらかされても理解に苦しむのですが。

あと、december28さんの質問をスルーしているのは、答えに詰まっているからですか?

みながわけんじ 2012年12月19日 (水) 08:58

↑わけわからん

>そう、まったく同様にstaticでないメソッドからも
>public static メソッドが呼べてしまいます。

そうですが・・・

>public static メソッドを定義するからこんなことが起こるんです。

ここで、論理の飛躍があります。staticでないメソッドからもstaticでないpublicメソッドが呼び出せます。

public void f()
は、他のクラスからメソッドとしてよりだせますよね。

>これならModuleAで閉じてるもの。

閉じてないですよ。

ナッシュビル 2012年12月19日 (水) 09:01

みながわさん>
それから、みながわさんの投稿は誤字脱字、主語が何なのかはっきりしないものが多く、意味がつかみにくいことが多いです。そのことも混乱の一因となっていますね。
文章を書き慣れていないうちは、何度か読み返してみましょう。
社会人としての忠告です。

みながわけんじ 2012年12月19日 (水) 09:09

追伸

私の2012年12月19日 (水) 08:58投稿は、επιστημη さんの自論に対しての感想です。

他の方が割り込んできたので、「↑わけわからん」は誤解を受けます。

ナッシュビルさん
人のコメントに対しての回答義務は、コメント者やコラム筆者にはありませんので、ご了承ください。ノーギャラですので・・・

december28さんの課題については、よくあるプログラムの例なので、巷の本やインターネットの情報を調べれば、利用している開発環境での、推奨方法がいくつか乗っているので回答する必要はないと私は思っています。また玄米茶さんの本コラムの議題「スコープ」とは、あまり関係がありません。

A 2012年12月19日 (水) 09:36

@ITを読んでいると、よくεπιστημηさんが仲間を引き連れて(プロバイダを複数契約しているのかな)暴言や自画自賛を交えて、他の読者を攻撃している光景が向けられます。普通に一人で議論できないのでしょうか?不快です。
議論の内容についてはどっちもどっちです。互いに限られた知識の範囲内で持論を強固に主張しています。挑発行為がなければもっと議論が進むでしょう。
一応自分の意見を述べておきます。問題はスコープです。スコープの範囲を極力せばめるのが基本です。静的メソッドについてはメソッドの所属が問題です。型に属するのか、インスタンスに属するのかで考えるのが基本です。実装面ではstaticの有無には差がほとんどありません。暗黙のthisポインタがあるのかないのかだけです。そこまで気にすることではありません。些細なプログラミングテクニックでなく、設計面で考えるべきです。

投稿する

@IT Special 注目企業
@IT Special ラーニング

エンジニアライフ 最新の投稿コラム

@IT自分戦略研究所 新着記事

コラムニスト プロフィール

玄米茶
こんにちは。十数年のサラリーマン生活を経て、現在はフリー(個人事業主)でWebシステムの開発をやっています。ブログはこちら

2012年12月

            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

バックナンバー

月間バックナンバー

カテゴリー

検索

Powered by TypePad
- PR -
@IT Special 注目企業
インデックス

イベントカレンダー

アクセスランキング

もっと見る

@IT Special ラーニング