ぎにょろぐ

Androidアプリ開発に関する事やその他雑記など

オブジェクト指向入門 第4章「再利用性へのアプローチ」を読みました

現在、オブジェクト指向入門という本を読み進めています。

最近引っ越しの作業などであまり時間が取れなかったのですが、スキマ時間に読みながらようやく4章を読み終わりました。 気になった点や感想などを、いつもどおりメモしていきたいと思います。

前回はこちら。

概要

第4章は、モジュールの利点の一つである、再利用性にフォーカスを当てた内容でした。

プログラムを再利用する利点

プログラムを再利用することは、下記のような様々な利点がある。

  • 適時性:既存の部品を再利用することにより、しない場合に比べて早く完成できる
  • 保守作業の軽減:各モジュールを再利用する事により担当領域毎の責任の所在が明確になる
  • 信頼性:評判の良い部品を利用することで、1から作るより高い品質を確保できる
  • 効率性:それぞれの部品をその部品を関心事の専門家が作ることにより、最善のアルゴリズムやデータ構造に出来る。(数学者が計算ライブラリを開発するなど)
  • 一貫性:同じ事をしようとする時に、その部品に依存する全ての部分が一貫性のある書き方となる。
  • 投資:優秀な開発者のノウハウを時間とともに消費するのでなく、部品として保存し資産として利益をもたらし続ける事が出来るようになる。

再利用性の利点には

  • 生産者(部品を作る人)
  • 消費者(部品を使う人)

の2つの視点での利点が存在する。

基本的に、いきなり再利用可能な部品を作ることは不可能である。

まずは良い部品を使い、使い方の学習をしたり、部品を模倣したりすることで、自身のスキルを上げることで初めて良い部品が作れるようになる。

何を再利用するか

一口に再利用と行っても、様々な粒度が存在する。例えば、 - 人材の再利用:企業がノウハウを持つ人材を様々なプロジェクトに割り当てて、ノウハウが失われるのを防止する。 - 設計と仕様の再利用:モデル設計の再利用。コードテンプレート的な形 - デザインパターン:設計上の問題に対する解決手法のパターン - ソースコードによる再利用:ソースコードをそのまま配布する

人材の再利用や設計の再利用は企業単位の話になってしまう。

また、ソースコードによる再利用は、仕様の把握が難しかったり、利用したい特定の処理がスクリプトの中に埋もれてしまったりする問題がある。そして、ソースコードの中でルールを飛び越えて他の部品に依存してしまい、不必要な部品にまで利用者側が依存してしまう問題もある。

以上のことから、再利用可能なソフトウェアの要素は、前回の章で定義されたモジュールの条件を満たすモジュールである必要がある。また、部品の使用者に関係する情報のみが開示されて、その他の詳細は隠蔽されている = 抽象的である必要もある。

モジュール再利用の障害

  • NIH(Not invented here)症候群:自分のテリトリー外で開発された事を理由に、再利用を拒む NIH症候群 - Wikipedia
  • HIN(Habit Inhibiting Novelty)新しいもの嫌い症候群:特定のツールに慣れてしまい、新しいツールを導入することを拒む。
  • モジュールの配布方法
    • 完全なソースコードとして配布することは、教材としても良い。
    • 仕様はあくまで抽象化された部分に記述すること。ソースコードの中身に仕様が存在するのはモジュールの基準を満たしていない。

モジュールの再利用には、技術的な問題のみならず、組織/経済/文化的な側面での問題も存在する。

技術的な問題

  • プログラムを書く時、同じ処理を繰り返しがちだが、まったく同じ処理ではなく、似たようなパターンだが微妙に異なる処理を繰り返すことが大半である。その共通性を見つけて抽出するのが難しい。
  • 本当に特定の問題に対処するためだけのモジュールだと、他の部分で再利用ができず、再利用 or やり直しの2択を迫られる事になる。
  • 開放/閉鎖の原則に則って、一部分を再利用しつつ(閉鎖されている)、その問題の解決に適用が可能(開放されている)のが、良いモジュールの条件である。
  • 配列、ファイル、連結リストなど、様々なデータ構造に対して行いたい操作(全探索など)をする際に、カーソルの概念など共通項をを見出し、不必要な処理の重複を防ぐ必要がある。

伝統的なモジュール構造

  • ルーチン:javaでいうstatic関数など。入力に対する出力が存在するのみなら共通化出来るが、複雑なデータ構造が存在する場合や、様々なケースに対応しようとして複数のルーチンを用意しようとすると独立性が失われてしまう問題がある。
  • パッケージ:個別コンパイル情報隠蔽などサポートしている。しかし、型のバリエーションに対応しておらず、処理の対象としたい型が増えるたびパッケージも対応しなければならず、独立性が無いと言える。

上記のモジュール構造の問題を解決するのが、多重定義と総称性(generics)である。

多重定義と総称性

  • 多重定義:javaでいうoverload。引数が同じ型だが、それぞれ意味合いが異なる場合に対応できない。
  • 総称性:javaでいうgenerics。多重定義で問題となった型のバリエーションを受け入れるための答え。
    • に対する は実総称パラメータ(actual generic parameter)と呼ぶ
    • ListがList と定義され、実際のモジュールを獲得することを総称的派生(generic derivation)と呼ぶ

総称性は、供給者モジュールの作者のための機能で、Listなど特定の概念を表す一つの実装を複数のオブジェクトに適用することが出来るようになる。

総称性は表現の独立性、共通する処理のふるいだしには有効ではない。それに関する答えはまた次の章で解説する。

感想

固有の概念や用語が多く、なかなか読むのが辛かった章でした。

ちまちま読んで4章を振り返りながら今記事を書いていたのですが、前半部分は殆ど忘れてしまっていました…

新人研修などでinterfaceやポリモーフィズムgenericsなど使い方に関しては学習してなんとなくどのような概念かはイメージがつくのですが、このように改まって抽象的に解説されると、その言語仕様の裏側にある原則などがまだまだ理解出来てなかったのだと感じました。反面、現在自分がある程度疎結合なプログラムを無意識的に、当たり前のように開発出来ているのは、先人のこのような研究や概念の発見があってこそだったんだなと、現状のパラダイムから開発をスタートできたありがたみを感じました。

数十年前の本のはずですが人材の再利用や組織の話などは、今でも通ずる話ですね。ある程度経験を積んだエンジニアだとNIH(新しいもの嫌い)症候群になりがちかちなイメージがあるので気をつけていきたいです。

また、いきなり「再利用可能な部品を作ることは不可能である」というのは、かなり重要な原則かなと思います。いきなり再利用可能性からスタートしてモジュールを作ろうとして良い部品になる事って殆ど無いですよね。様々な優れたライブラリを使って、どのような開放/閉鎖具合が望ましいかを意識的に学習していないと、そのような再利用可能な部品を作る能力は身につか無さそうですね。

次は、第五章です。少々読むのがしんどくなってきた(まだ自分には早かったのではと感じ始めている)のと、最近業務でクラス図を書く機会が増えたので最近買った下記の書籍に浮気してみようかなと思います。

オブジェクト指向入門 第三章を読んだメモ

前回に引き続き、オブジェクト指向入門という本を読み進めていったので、そのメモです。第2章は当たり前の内容が多かったため、サラッと読み流す程度にしておき、3章をじっくり読んでみる事にしました。以下はその中で興味深かった事などのメモです。

概要

  • 「モジュール性が高い」とはなにかについて解説する。
    • 5つの基準(criteria)
    • 5つの規則(rule)
    • 5つの原則(principle)

5つの基準(criteria)

「モジュール性がある」と呼ぶ価値のある設計手法は、下記の5つを満たさなければならない

  • 分解しやすさ(Decomposability)
  • 組み合わせやすさ(Composability)
  • 分かりやすさ(Understandability)
  • 連続性(Continuity)
  • 保護性(Protection)

分解しやすさ

  • 複雑な問題の解決において、単純な問題に分解し、個々に作業を進められるだけの独立性を持っている事。
  • 分解しやすくない構造の例:ファイルやDBなどの初期化に関して、同じタイミングの事だからといってモジュール内の実装を知って一つのモジュールがまとめて初期化するなどといった、モジュールが自立せず情報が漏洩している構造

組み合わせやすさ

  • もともととは全く異なる環境においても、互いを自由に組み合わせる事により、新しいシステムの生産を助けるならば、組み合わせやすさは高い。
  • モジュールを作るに至った直接の目標から出来る限り独立するべき
  • トップダウンでモジュールを分解すると、組み合わせやすさが損なわれる傾向がある。それぞれのモジュールがそのコンテキストでの問題解決に密接に結びついているため。

  • ボトムアップトップダウンを組み合わせることが大事

分かりやすさ

  • 保守過程で重要
  • 悪い例:特定の順序で起動されたときのみ機能するよう設計されたモジュール。例えば、 UnixA | B | C といった形でモジュールAの後、モジュールCの前に起動した場合のみ正しく動くモジュールBなど。モジュールAやCを理解しないとBの理解は困難になる。

連続性

  • 問題の修正や小さな変更があった際に、出来る限り影響がそのモジュール内、もしくは少数のモジュールで閉じている事

    変更はソフトウェアを構築する過程における中心的な部分を締めている

感想

  • 例が分かりづらい

保護性

  • 異常な条件、エラーが起きた場合、影響をモジュール内、もしくは最悪周辺の少数モジュールにのみにしか広がらない場合、保護性が高い
  • いい例:入り口での値の検査
  • 悪い例:例外機能(Exception)。上手く使わないと保護性を損なう恐れがある

5つの規則

モジュール性を保証するために守らなければならないもの

  • 直接的な写像(Direct Mapping)
  • 少ないインタフェース(Few Interfaces)
  • 小さいインタフェース(Small Intefaces, small coupling)
  • 明示的なインタフェース(Explicit Interface)
  • 情報隠蔽(Information Hiding)

直接的な写像

  • 問題領域を記述するいいモデルが既に存在する場合、ソフトウェアとしてのコードとのマッピングを明快に保つことが望ましい。例えば、桁数に制約のある概念(注文個数)などをInt型として扱うのは、マッピングが上手く出来ていない。
  • 関連する基準:連続性、分解しやすさ

少ないインタフェース

  • モジュール同士の通信、依存を出来る限り少なくする
    • モジュール同士が呼び合う、データ構造を共有する など
  • 関連する基準:連続性、保護性
    • モジュール間の関係が多いと、変更やエラーの影響が大きくなる

小さいインタフェース

  • 2つのモジュールが通信する場合、更新される情報ができるだけ少なくする
  • 共有されるデータが大きいと、データが全てのモジュールで誤用される可能性がある
  • 関連する基準:連続性、保護性
  • ざっくりいうとグローバル変数は悪だよねという話

明示的なインタフェース

  • AとBのモジュールが通信する時、そのことがAまたはBから、あるはその両方のテキストから明らかにわかること。モジュールの接続部分が明らかになっている事
  • 関連する基準:分解しやすさ、組み合わせやすさ
  • データの共有は間接的結びつき

情報隠蔽

  • モジュールの中からいくつかを公開情報として選び、その公開情報でもってして他の世界(モジュール)から認知される事が期待される。
  • 関連する基準:連続性
    • 公開されている部分が小さいほど、モジュールに対する変更の影響は小さくなる。非公開の部分を変更しても、他のモジュールは影響を受けない
    • 例えば、テーブルの構造(ハッシュテーブル or 逐次配列)がどちらかという情報が隠蔽されていれば、どちらを採用しようと呼び出す側には直接影響はない
  • あくまで呼び出す側のモジュールは、公開されているインタフェースにのみ依存すべき(内部の実装に依存しない)
    • 情報隠蔽によって、内部の実装に依存するようにかけないようにするべき

5つの原則

  • 言語としてのモジュール単位(Liguistic Modular Units)の原則
  • 自己文書化(Self-Documentation)の原則
  • 統一形式アクセス(Uniform Access)の原則
  • 開放/閉鎖(Open-Closed)の原則
  • 単一責任選択(Single Choice)の原則

言語としてのモジュール単位

  • モジュールは使用される言語(プログラミング言語、設計言語)に対応していなければならない
  • 注文機能 = 注文モジュールとして一致していなければならない。注文モジュールなのに発注も出来てはいけない

自己文書化

  • モジュールを設計する人は、モジュールについての全ての情報をモジュールの一部として作るように努力すべき
  • モジュールの分かりやすさに影響
  • 情報隠蔽と併用することにより、詳しすぎる情報を省く。内部実装の情報までドキュメント化すると詳しすぎて情報量がパンクしてしまう。
  • モジュールの中にドキュメントを含めるべき
    • GithubのReadmeみたいな形?
  • ソフトウェアを開発する人が、モジュールそのものの内部を知らずに顧客モジュールを書けるようにするためのもの

統一形式アクセス

  • 関連する基準:連続性、情報隠蔽
  • 例えば、出金の入金のプロパティを持つ口座オブジェクトが存在した場合、口座残高プロパティを書きのように定義できる
    • 都度入出金プロパティをもとに計算する
    • 口座残高プロパティとして定義し、入出金プロパティが変更されるたびに再計算して更新する
  • このような設計はトレードオフになり、後で仕様を変更する事になる事が多い。どちらの実装でも 口座.口座残高() のように統一された形式でアクセスされると、これを使用するモジュールが気にする必要は無い。これは、連続性の基準を満たしているといえる。

開放/閉鎖の原則

  • モジュールは開いていると同時に閉じているべきである
  • モジュールに対する拡張欲求と閉鎖欲求は並行して存在する
    • 機能を作るにあたり、既存のモジュールの仕様では求める要件を満たせない。モジュールのデータ構造にフィールドを追加したり、メソッドを増やすなど行って、新たな機能を作成したい。
    • 既にそのモジュールに対しては複数のモジュールが依存している。そのため、既存の振る舞いをあるモジュールの要件を満たすためだけに修正すると、他のモジュールの振る舞いも意図しないものになってしまう。
  • クラスの継承を使えば、もとのクラスに必要な一貫性に影響を与えずに、変形に必要なものを提供することが出来る
  • 一方で、もとのモジュールの不具合を拡張によって直すべきではない。それは、直接もとのモジュールで修正すべきである。

単一責任選択

  • 開放/閉鎖の原則と情報隠蔽の原則の両方の論理的帰結
  • ソフトウェアシステムが選択肢を提供しなければならないとき、そのシステムの中の一つのモジュールだけが、その選択肢のすべてを把握すべきである
  • 特定のクラスのある概念が拡張される(例えば、区分が増えるなど)すると、そのクラスに依存するすべてのモジュールの処理を書き換えなければならない。連続性を満たしてないともいえる。
  • 責任が単一じゃないクラス = 神クラスという形で想像すると分かりやすいかも。
  • この原則は、ソフトウェアにおける知識の分散についての原則とも言える
  • 組織で採用されている手法に例えると、「必要に応じて知らせる方式」
  • この原則は、開放/閉鎖の原則の結果としてみることも出来る
  • 多相性(Polymorphism)と動的束縛(dynamic binding)がこの原則を満たす具体的なアプローチである。

感想

第二章も面白かったです。SOLID原則と似たような概念が出てきたのですが、最初の3つの原則は言語でサポートしていたり、無意識的に行っている事が多いかなと感じました。

その点、SOLID原則全てを意識するよりこれらの原則を意識するほうが難易度が低そうですね。

SOLID原則は知っているけどなぜ必要なのかはモヤモヤしていたので、「5つの基準」から段階的にその必要性から原則に発展していくこの章の構成はとても腑に落ちる形で読みやすかったです。(登場する例はイメージしづらくて読みにくいですが)

個人的には、開放/閉鎖の原則がなんとなく「修正に対しては閉じていて、拡張に関して開いていること」という言葉だけで理解した気になっていたのが、より具体的にその必要性とどのようにな設計がこの原則に則っているかがはっきりイメージしていたため、ブレイクスルーになりました。仕事でのAndroidアプリ開発におけるモジュール、Viewコンポーネントの設計に早速役立ちそうです。

一気に第二章を読み切ったのですが、しんどかったのと睡眠時間が削られてしまったので、次はもうちょっと細切れに進めていこうかなと思います。

オブジェクト指向入門 第一章を読んだのでメモ

はじめに

最近、オブジェクト指向入門という本を購入し、読み進めています。 理解を深めるために、章ごとに気になった所や分からなかった所、面白かった所をアウトプットしていく予定です。 今回は第一章に関してです。

概要

本章は「ソフトウェアの品質」とはなにかという所に立ち返って、より品質という概念を細分化し整理している。

外的品質と内的品質

ソフトウェアの品質には2種類の性質が存在する。

外的品質要因(external factor):一つはユーザーにとっての品質。使いやすさや速度だったり、そもそも要件が守られていることなど。

内的品質要因(internal factor):もう一つは開発者にとっての品質。モジュール性が高い、コードが読みやすいなど

外的品質要因を高める事が1番の目的であり。結局、内的品質要因が高くないと結局外的品質要因も高くならない。

しかし、内的品質要因の向上はあくまで外的品質要因を満たすための手段である。

外的品質の要因

  • 正確さ:アプリケーションの要件を満たすこと。仕様を満たすこと
  • 頑丈さ:入出力などで例外が起きても、システムが完全に破壊される(DBが消えるなど)といった問題を起こさず、エラーメッセージに丸めてレスポンスを返すなど適切な処理が行われる
  • 拡張性:仕様変更が入った際の適応のしやすさ。モジュールが適切に分割されていたり、シンプルなアーキテクチャが存在することで、変更の影響が極力少ないと拡張性が高いといえる。
  • 再利用性:同じようなパターンの処理を異なる開発で使いまわす事で、その分減ったリソースを他の品質の向上(頑丈さや正確さ)が出来る。
  • 互換性:他のソフトとの組み合わせやすさ。そのソフト固有のフォーマットでデータを取り扱っており、他のソフトが解釈し得ない形でしか出力できないと、互換性が低いと言える
  • 効率性:ざっくりいうとパフォーマンス。性能に注力しすぎることも、しなさすぎる事もダメ。
  • 可搬性:その名の通り、様々なプラットフォームに移植できる事
  • 使いやすさ:背景・経験が異なる人々が同じく容易にそのソフトウェアを使いこなせるか、また、応用できるか。
  • 機能性:システムが提供する機能の範囲。たくさんの機能(CSVだけではなくExcelでも出力できるなど)があるほどこの性質が高いと言える。機能性は納期や他の品質トレードオフになることも。
  • 適時性:ユーザーが必要としている時にソフトウェアをリリース出来ること。シンプルに言えば我々の嫌いな納期。

その他の外的品質要因

  • 実証性:エラーが出た際追跡しやすい
  • 統合性:セキュリティ
  • 修復性:バグ修正のしやすさ?よく分からず
  • 経済性:予算に大して費用が低いほど経済性が良い。(炎上案件で無理やり納期を合わせて赤字になりがちな適時性と相反しがち)

外的品質に関してと、特に重要なポイント

納期 vs 予算など、外的品質要因同士は明らかにトレードオフの関係にあるものもある。

特に重要なのは下記2つとされている。 - 「正確さと頑丈さ」:要件通りに動くアプリケーションで、致命的なエラーになることが無い事(シンプルに言うと、バグが無いこと)(俗に言う信頼性) - 「拡張性と再利用性」:仕様の変更を簡単に実装でき、再利用出来るコンポーネントがより多い。よりエコに変更に追従できること。(俗に言うモジュラー性)

本書で解説されるオブジェクト指向が、上記の重要な要因も含め、様々な品質要因を改善することが出来る手法と述べられている。例えば、効率性(パフォーマンス)に関しては、処理能力の高い再利用可能なコンポーネントを作成し再利用することで向上が出来る。

ソフトウェアの保守について

ソフトウェアのコストの70%以上は保守に費やされている。 ソフトウェアの 「保守」とはなにか。車や家電みたいに繰り返し使った所で疲労するものではないため、ソフトウェアを「保守(maintain)」するという表現は正確ではない。 ソフトウェア業界の「保守」は - 新しく機能を追加する、仕様の修正 - バグを直す(本書では「期限の過ぎてからのデバッグ」というある意味粋な?言い方をしている) などの意味で使われている。

感想

自分が思っていたけど言語化出来ていたかった部分がきれいに言語化されていて、喉のつかえが取れたような気分になりました。

特に、

オブジェクト思考技術を習得すれば、ソフトウェアを短い時間と少ないコストで生産出来るようになる。これはオブジェクト指向的手法によって機能の追加が用意になるばかりでなく、手法そのものが新しい機能の追加を示唆することもあるためである。

この言葉はまさに自分がオブジェクト指向に対する考え方そのものです。 オブジェクト指向やDDD的な手法を知らなかった頃に比べると、今はスピードが早く間違いのない(あってもトレーサビリティが高くすぐ修正出来る)アウトプットが出来ていると感じています。

また、「外的品質を高めるためには、コードのきれいさ・モジュール性のような内的品質が鍵になる」という主張も、自分の「ソフトウェア開発はバグなくかつ工数を少ない形でアウトプットするのが正義。しかし安定してそれを実現するためにはモデリングオブジェクト指向、各種アーキテクチャなどを用いた所謂きれいなコードを書く技術が必要になってくる」という自分のスタンスと一致していたため、安心感を得ました。

一方で、再利用性や拡張性など、一見内的品質要因に区分されそうな事も外的品質要因として取り上げられている事には違和感があります。 内的品質要因の一覧はまたそのうち出てくるのでしょうか。 この辺の話は、ISO/IEC 9126 - Wikipedia の国際規格としての品質の定義も合わせて確認して比較してみるとより勉強になりそうです。

まだオブジェクト指向に関する話は出てきてませんが、早くも次の章が楽しみです。

いいなと思ったプログラミングの原則・法則まとめ

YAGNI

You Aren't Gonna Need It (その機能は必要無いよ!)の略称。

「HogeHogeの改修したい時のためにこの仕様にしておいた方がいいよね」といった「もしも」のために作った機能は、結局の所ほとんど使われることはないため、工数の無駄であるという考え方です。

Extreme Programming の文脈から登場した概念とのことです。

このトピックに関するインターネット上の記事が散見されますが、このように抽象度の高い概念だとどうしても自分の経験に基づく解釈をしがちなのかなと感じました。

例えば、YAGNIはソフトウェア実装の原則。直訳は「そんなモン要らんって!」 - ベルリンのITスタートアップで働くソフトウェアエンジニアのブログ においては、「仕様を満たす上での技術選択におけるオーバーエンジニアリング」に対して、 YAGNI ~ 予想でモノを作るな | 悪態のプログラマ の記事では、「CSV出力機能」などの要件レイヤーの部分に対する事に大してYAGNIの観点から批判をしています。

しかし、ともすれば設計をクリーンに保つためのリファクタリングなどもオーバーエンジニアリングとして捉えられてしまうため、常にこの概念に対する解釈をアップデートしていく必要があるでしょう。

私的には、この原則は後者の機能レイヤーに対しての原則だと解釈しています。例に出したCSV出力機能レベルの事は言わずもがなですが、もう少し細かい事例を想定してみると、

  • この画面は他画面から遷移されるかもしれないから、より汎用的・独立的に使えるようにしよう。(今は完全に遷移元の画面に依存した作りになっている)
  • エラー画面を動的に変更したり、エラー文言が変わるかもしれないから、それらに耐えうる汎用性の高い仕様にしよう。(今はエラー画面パターンは完全に固定)

といった提案に対しても、YAGNIの原則を当てはめてあえて限定した処理しか記述しないようにすべきであると思います。

一般的に、Viewコンポーネントやオブジェクトが機能を提供しているメタ構造自体が、コードを読む上で現在の仕様把握の手がかりとなるケースがあり、用途不明の機能はその理解を妨げ、結果保守における工数が増加してしまうからです。

また、一般的にDDDの文脈におけるモデル駆動の設計は、クラスも増えるためオーバーエンジニアリングに見られがちですが、実際には提供する機能を制限したりプリミティブ型の取り扱いをなくして、値オブジェクトとして取りうる値の制約を明示したりと、プリミティブ型をそのまま取り扱った手続き型プログラミング的書き方で「コードは汚いけど工数を極力少なくしてYAGNIを実践した」という主張より、どこまでが提供すべき機能で、どこまでが提供すべきでない機能であるかを明示している分、YAGNIをしていると自分は感じます。

Don't tell, ask

新装版 リファクタリング 既存のコードを安全に改善する | MartinFowler, 児玉公信, 友野晶夫, 平澤章, 梅澤真史 | 工学 | Kindleストア | Amazon の著者が提唱した概念。

Martin Fowlerが書いた記事 TellDontAsk によると

Tell-Don't-Ask is a principle that helps people remember that object-orientation is about bundling data with the functions that operate on that data.

(約 : Tell-Don't-Ask はオブジェクト思考がデータ構造とそのデータを処理する関数と紐付ける事であることを思い出させてくれる原則である)

と述べています。詳しい事は上記の記事や他の記事を参照。

デメテルの原則 と似たような領域の話ですが、デメテルの原則は具体的な「オブジェクトが保持するインスタンスのメソッドを参照しない」という事にフォーカスを置いているのに対して、ドメインを表現する事にフォーカスしている概念と感じました。

下記のコードのように、プロパティを参照して呼び出しもとで計算を行うことはよくあるのではないでしょうか(あまり上手いたとえでなくて申し訳ないです。)

// wifeが呼び出し元に対して、nameプロパティをtellして(伝えて)いる
val firstName = wife.firstName
val lastName = "Stiller"

println("married name is " + firstName + " " + lastName)

このような処理を、できるだけオブジェクト自体に振る舞いをもたせようとすると、おそらく下記のような作りになるでしょう。

println(wife.marriedName(husband))

class Wife(private val firstName : String) {
     fun marriedName(lastName: String) : String {
          return this.firstName + " " +  husband.lastName
     }
}

下記の方が不要なプロパティの公開も無く、アプリケーションの仕様用途がより明確となる構造となっているためより良いオブジェクトのように見えます。

ただ、上記の記事でMartin Fowlerは Tell Don't Askも銀の弾丸ではない旨を述べている。病的なまでのGetter撲滅により可読性の低い構造化をしてしまう恐れがあったり、オブジェクト同士の効果的な連携を阻害してしまう恐れがあるとのことです(このあたりはまだ理解できていません)。

But personally, I don't use tell-dont-ask. I do look to co-locate data and behavior, which often leads to similar results. One thing I find troubling about tell-dont-ask is that I've seen it encourage people to become GetterEradicators, seeking to get rid of all query methods. But there are times when objects collaborate effectively by providing information.

参考

YAGNI - Wikipedia

その1 YAGNI(ヤグニ)の原則でいこう

Martin Fowler氏が"Yagni: You Are Not Gonna Need IT"について語る

YAGNIはソフトウェア実装の原則。直訳は「そんなモン要らんって!」 - ベルリンのITスタートアップで働くソフトウェアエンジニアのブログ

YAGNIを実践する(翻訳)

TellDontAsk

何かのときにすっと出したい、プログラミングに関する法則・原則一覧 - Qiita

デメテルの法則 - Wikipedia

ボードゲームの戦績を記録するアプリを作りかけた(Vue.js + Vuetify + Firebase)

はじめに

この記事は、ギークハウス元住吉 Advent Calendar 2018 - Adventar20日目の記事です。

11月から12月の序盤にかけて、謎のやる気がありAndroidアプリ開発以外もしたくなったので、会社の人がハマっていたVue.jsと、モバイルアプリでよく使っているfirebaseを使ってナウいサーバーレスのアプリケーションを作っていました。

その頃ギークハウス元住吉ではドミニオンが流行っていたので、題材はボードゲームの戦績を記録するアプリとしました。

また、タイトルにもある通り、完成はしていません。途中でスマブラが出たなど諸般の事情でためやる気が完全に吸い取られましたためです。 また気が向いたら開発を再開しようと思っています。

アウトプット

アプリケーション

https://boardgame-battle-log.firebaseapp.com/

githubレポジトリ

github.com

採用した技術

  • vue.js
    • vuetify
  • firebase
    • firestore
    • hosting
    • authentication(を使いたかった)

参考にした資料

Udemy vue.js 入門

https://www.udemy.com/learn-vuejs/

vuetifyjs.com

Cloud Firestore を使ってみる  |  Firebase

作りかけた感想

良かった点

  • jQueryや生のjsを書いてきた人間の取って、androidのようにdatabindingを基にフロントを書けるのは、責務の分割も出来て大変快適だった。vueを使っている人が皆言うように、書いていて楽しかった。
  • vuetify使うだけでそれっぽいマテリアルデザインのサイトにする事が出来てすごい。
  • 様々なもくもく会に作業に行った中で、様々なエンジニアの人に出会えて楽しかった。モチベにもなった。

次回改善したい点

  • 作る前に思ってた3000倍くらい状態が多く、片手間でアプリを作る題材としてはダメだったと痛感。

    • 学習用に作るサービスは、自分が思うより数倍シンプルな状態にしなければいけないと感じた。
    • vueの目玉であるコンポーネント化を行う前にやる気と時間が付きてしまった。
  • 要件とワイヤーを明確に定義しておく事の重要さ。モチベupのためにvuetifyでそれっぽい見た目にしようとしたら、そちらに工数の大半を取られてしまった。

  • サービスとして使って貰える状態ではないため、きちんと計画と期間とやる気のコントロールを考えて次は計画を立てたい。

おわりに

ナウいフロントの技術に触れることが出来て楽しかったです。次はwebpackに関して理解してから、よりシンプルなアプリを作るようにしたい。 最近またAndroidのやる気が上がってきたので、しばらくはAndroidの勉強しようかなと思います。

ギークハウス元住吉近辺のオススメスーパー3つ

はじめに

この記事は、ギークハウス元住吉アドベントカレンダー15日目の記事です。

2日遅れで再び泣きながら書いてます。もうちょっと事前にストックしておくとかすれば良かったと現在後悔中です。(学習はしない)

今回は、ギークハウス元住吉の近くにあるすすめスーパーを紹介したいと思います。

1. まいばすけっと

  • アクセス:★★★★★
  • 安さ  :★★★☆☆
  • 品揃え :★★☆☆☆

最近できた元住吉駅に一番近いスーパー。 店舗が狭いため、少々品揃えが悪い。また、価格もそこまで安くない。ただ、アクセスが良いので私は一番使っています。

2. マックスバリュ

  • アクセス:★★★★☆
  • 安さ  :★★★★☆
  • 品揃え :★★★★★

そこそこ店舗が大きいマックスバリュギークハウス元住吉からは一番近い。私は仕事帰りは大抵まいばすけっとに行ってしまうので、休日くらいしか使いません。 諸用でどうしてもカリフラワーが欲しかったとき、他のスーパーにはなかったがマックスバリュにはあったので、品揃えを★5にしています。

3. ダイイチ

  • アクセス:★★☆☆☆
  • 安さ  :★★★★★
  • 品揃え :★★★★☆

実は私は行った事がありませんが、悪魔的に価格が安いらしいです。 今度行ってみようとおもいます。

ワイが課金して使ってるアプリ3つ

はじめに

この記事はギークハウス元住吉 Advent Calendar 2018 - Adventarの12日目の記事です。 忙殺されて完全に遅れて泣きながら書いてます。

今回は私が月額課金してでも使っているWebサービス、アプリを紹介したいと思います。 どれも素晴らしいサービスなので、気になった方はぜひチェックしてみてください。

Spotify

www.spotify.com

  • 言わずとしれた音楽ストリーミング配信サービス
  • 皆もっと使っているかと思ったが、周りは意外とapple music派が多い。個人的にはspotifyを推したい
  • 邦楽が弱いと言われているが、よほどマイナーなグループじゃない限りは大抵網羅されている。
  • アカペラに関しては、めちゃめちゃマイナーなグループもSpotifyに登録されており、音源のリリース日に曲を聞くこともできる。
    • 「CDを買う」という行為に決断エネルギーを使わないので、ストレスフリーで様々な音楽を楽しむいいきっかけになっている(気がする)
  • UIが安っぽくない。spotifyを使っている自分に満足できる。

inkdrop

inkdrop.app

  • markdwonエディタ。個人的にかなりかゆい所に手が届いて最強
  • クラウド完備・シンタックスハイライトがリッチ
  • 書いているmarkdownを同期して静的コンテンツとして公開出来る機能が鬼便利。ちょっとしたメモをリッチなエディタで書いて、HTMLとしてレンダリングされたもの即座に共有出来る。
  • クラウドに関しては、サービス提供側が用意しているサーバーのほか、自分のサーバーも使える。重要な情報を書き込みたい、外部のサーバーに情報を漏らしたくない人にも対応。
  • モバイルアプリもかなりしっかり作られている。 boostnote を一時期使っていたが、モバイルアプリが使い物にならない + クラウドでの文書の同期機能が外部サービス連携のため、使いづらかった。

SummaryPocket

pocket.sumally.com

  • 貸し倉庫 x アプリのサービス
  • アイテムを送ったら、タグ付けして管理してくれる。スマホアプリを開くと、どのようなものを保管しているのか、画像つきで一覧で参照出来る。
    • 整理整頓が苦手な人には神サービスになると思う。
  • 服やスーツなど、管理を間違えると傷んだりするものでも、適切に管理してくれる。スマホからクリーニングに出したりヤフオクに出品も出来る(割高になっちゃいますが)。
  • 自分は冬服と夏服をそれぞれのシーズンで保管・引き出ししているのと、CDや本を保管しています。どのようなものを保管しているのか、手元ですぐ確認できるので便利。
  • 引き出し料金が高い(1000円ほど)なので、こまめに保管・引き出しを繰り返すようなものには向かないかも。