前提

プロジェクト構造を客観視した際に、振る舞いごとのClassが少ない、またはほどんどないという現場のエンジニア。アーキテクチャの特性上の規則的なClass(view,viewmodel,model,controllerなど)はあるが、基本的にそこにすべてのソースを記述しているエンジニア。モジュールをクラスだと思ってしまっているエンジニア向け。

モジュールはモジュールであってクラスではない

プロジェクトのフォルダ構成を見てもらいたい。フォルダはアーキテクチャを知る手掛かりとしては重要な情報源となる。フォルダ構成の中に、toolやtoolsといったツールを指し示すような名称のものはないだろうか？

Windows95が発売されて、安価なPCが次々と世に出されていたころのプログラムは、モジュール指向一色だったと思う。とりあえずモジュール化しておこうか、とやたらと部品化していたような覚えがある。このモジュール化作業は、言ってみればナットとボルトのようなもので、その規格に合ったものは使用できるが、サイズが異なればまるで使い物にならない。そもそも、再利用しようなどという考え方すらなかった。なので、モジュールを使用する場合は、必然的にモジュールを拡張していくことが前提となる。必然的に、インスタンスを使用する形にはならず、いわゆる電卓的な機能構造になる。

対して、オブジェクト指向はナットとボルトが「どんな機能を持っているか」という振る舞いから考えるという、全く違う視点からのアプローチを行うものだった。なので、サイズが異なろうと、ナットがマイナスドライバーを使用するものだろうと、プラスだろうと、ねじを締めるという動作自体は変わらないのだから、細かい違いは継承することでカバー可能、再利用することが可能なのだ。必然的に、インスタンスを使用して、動作上の必須情報をセットする形になる。

この二つは、ファイルの構造上では同じClassファイルに属している。アーキテクチャがそもそも異なるのに、同じ土俵に立つことができるという状態。これが非常に悩ましい。
仮に、MVCのプロジェクト内に下記のようなクラスがあったとする。

Public Class StringTool

    Public Function GetCommaString(val As Integer) As String
        Return val.ToString("#,0")
    End Function

End Class

戻り値はToStringの機能を使って省略させてもらったが、こちらをSubStringやInsertを使って価格のカンマ区切りをするモジュールを実装していたとしよう。ほかにも、文字列を/区切りの日付書式にしてみたり、DateTimeを表示形式に変換するようなモジュールだ。

察しの良い人は、「なんだこれ？」と上記のおかしさに気付くはずだ。まず、静的なメソッドではないという点がおかしい。あり得ない。次点として、価格があるということは、これって商品の話なんじゃないの？という思考に至るはずだ。Itemというクラスがあって、価格のゲッターから呼ばれるモジュールとして存在するのであれば何とか納得できるかもしれないけれど、それでも違和感はぬぐえない。今どきの言語で、電卓的な機能がモジュールとして必要なケースは限られている。おそらく、Microsoftであればdllの中に組み込まれているはずだ。

ここで冒頭に戻る。では、ツール系のフォルダはいったい何だろう？
これは、新規に作成されるプロジェクトが、「古いソースを参考にした」コピペプロジェクトになっているのが原因だ。本来であれば、アーキテクチャにそぐわない「もの」は形を変えるなり、削除されるなりしていくものだが、「とりあえず動けばいいよね」という考え方があると、コピペしてしまう。一度コピペをすると、ここもあそこも、と次々とコピペされ、単にコンパイラのバージョンが異なる「だけ」のプロジェクトが完成してしまうのだ。

モジュール化とオブジェクト化は全く別の工程、アーキテクチャなので注意したいところだ。

まとめ

では、Classをどのように作るのか。これは、どうしてもアーキテクチャに依存することになる。プロジェクトの在り方のルールなのだから、当たり前の話なのだが。。この辺があいまいなエンジニアが少なからずいる。

オブジェクト指向なのであれば、振る舞いごとにClassを作ればよいし、モジュール指向なのであれば同じような機能をひとまとめにしてClassを作ればよい。今どきを考えるとオブジェクト指向なのだが、自分が所属しているプロジェクトがモジュール指向なのであればモジュールで書くべきだ。

ただ、Classはあくまでもアーキテクチャに依存することになるので、場当たり的な（Mix指向的な）自由奔放設計は避けたいところだ。