プログラミングのすすめ。PLとBLを明確に分けましょう!

徒然草2.0

PLとはプレゼンテーションロジックのことで、BLとはビジネスロジックのことを指す。

プレゼンテーションロジックとは

表示部分。値入力。編集画面。編集画面上のエラーチェックを行うところ。ユーザーインターフェース層とも呼ばれる。その名の通り、ユーザが向き合う画面部分のロジックを指す。

ビジネスロジックとは

データ処理を行うところ。業務上必要な計算などをおこなすロジックを指す。

PLとBLがごちゃ混ぜになったシステムは失敗だ

※なお今後は、プレゼンテーションロジックをPL、ビジネスロジックをBL、ユーザ―インターフェースをUI、ユーザーエクスペリエンスをUXと表記する。

「PLとBLまぜるな危険!」とは言ってみたものの、これが言葉が本当に正しいか分からないが、プログラミングをしていて、これははっきりと区別しておくべきだと常々思う。

ひどいデータ構造と処理ロジックに出会ったことが何度もある。プログラミングを上手くやるためには、このデータ構造と処理ロジックを、いかにうまく扱うかに掛かっていると言っても間違いない。オブジェクト指向プログラミングやその上位概念とでもいいのかDDD(ドメイン駆動設計)もひいて言えばこのPLとBLの整理手法ではないだろうか。(例えば、オブジェクト指向でなくても名前空間でメソッドや変数の独立性は保てるという人がいるし自分もそう思うところがあるが、名前空間ではPLとBLの分離は考慮されないあくまでコードレベルの独立性を担保するものだ。オブジェクト指向もBLを意識したPLというふうに現実世界のモデリングを意識しなくては中途半端なものになるが…それは今回その点にふれると話がややこしくなるのであえてふれません)

さて、PLとBLが混同された問題は、往々にしてデータ構造と処理ロジックの分別がつけられていないことに通じる。

PL/BL混合問題のとあるシステムとは、具体的に以下のようなものだ。

  • 画面から入力されるAとBのパラメータがあります。この値はAかBのいずれかがとある条件によって採用されます…採用された変数値が請求金額へ加算されるということです。ソースコード上では、請求金額へ加算される値として、A+Bと書いて加算をしています。加算する前に採用されない方の変数には、画面へ請求金額として出力される直前で数値0にしています。

…とまあ「分かりにくく」書いているのですが…これの何が問題か説明できるだろうか?

ロジック的に問題なくつくればOKという回答も間違ってはいないでしょう。正しく動いている業務システムであれば問題がないと言ってもよいのかもしれない。しかし、AとBのいずれかが採用されるということを、画面に0を入れることで実現しているのは非常に危うい気がしませんか。危うい気がするなら、ふつうにPLとBLがまざる考えの人です。

プログラムの修正時にAにもBにもなんらかの値を入れてしまうような修正をしてしまう恐れがあります。つまり、PLとBLの知識がない人が間違いを起こしやすい処理ロジックになっています。これで問題が起こったら、修正したプログラマに責任があるのでしょうか。

例えば、この場合の解決策としては、AまたはBに値をいれたことを表すフラグ的なものがあって、AとBいずれかの値を加算させるロジックを明示的に選ばせるようにしたほうがよいのかもしれません。フラグというデータカラムが増えることになることを嫌うならば、もう少しPL/BLをシステムに落とし込む部分についてのコミュニケーションをPMとSEとPGあたりで適切に行ったほうがよいのかもしれません。

ところでA+BというBLは、PL部分のロジックを前提に作られていることになります。つまり、PLとBLの区別がつけられていない人物が仕様を決めているということになる。大半の人は「これで何の問題があるのか?」とたぶん思うのでしょう。

PLとBLの絶妙なバランス

PLとBLを明確に分けるつくりにすると、あるデメリットが生まれがちのため、PLとBLの分離を嫌う人が少なくありません。そのデメリットは、プログラムのステップ数が増えてプログラミングに慣れた人が扱いづらいということ。

自分が考えた処理と画面は素晴らしいと思っている人(?)ほど、ビジネスロジックとプレゼンテーションロジックを一緒くたにしたシステム設計並びに画面設計をしがちなのではないでしょうか。

私もUI・UXの設計にはまったく定評がありません(!)が、このPLとBLの混同はシステムとして致命的になりかねないので、PLとBLを無理やりくっつけるような愚には、先んじで気づきます…というか、ビジネスロジックなんて知らない方が、実は客観的に処理・UI・UXを評価できたりするものです。

よく誤解されることですが、必要なのは分別です。

ちなみにPLとBLの分離は、UIの使いづらさにつながりやすいですが、必ずしもUIが使いづらいわけではありません。というか、PLとBLの分離を果たしながら、最高のUI・UXを目指すのが理想の画面設計です。というか、PLとBLを考慮した設計がUI・UX設計の幹部分だとすら思っています。

まとめ

  • PLとBLは明確に分ける意識をしよう
  • PLとBLを意識することのメリット
    • ユーザが使いやすい → システム屋の評価が上がる
    • データ構造を見るだけでビジネスロジックが分かる
    • オペレータは画面を見るだけで動かし方が分かる
    • エンジニアは保守しやすい

結論

PLとBLの意識をしよう!

※私が言いたいことが捻じくれて書いてあって分かりにくいので…今度もう少し清書しようと思います。

徒然草2.0
スポンサーリンク
シェアする
gomiryoをフォローする
ごみぶろぐ

コメント

タイトルとURLをコピーしました