iPhone 6を買ってよかったが未だどうか悩んでいる。
iPhone 6を買ってよかったが未だどうか悩んでいる。
経緯はこうだ。
- iPhone 6を購入した。
- やはり大きい。
- iPhone 5sに戻す。やはり、小さい方が使い易い。
- しかし、電車の中では本を読みたいが満員電車の中でiPad miniはでかい。
- 仕事でNexus 5にストラップを付けて使う。一部私用で使ってみる。
- 手を滑らせるようにして使えば5インチ端末も使い易い。
- iPhone 6にストラップを付けて同じように使う。使い易い。
で今の心境
- iPhone 6 plusもストラップを付ければ楽に操作できるんじゃない?
- Apple Watchが出ればiPhoneなんて体の何処かにつけておけばw。
- iPhone 6の解像度がフルHDに上がって5インチになれば。。。plusをスルーすべきかも。
- ジャンパラ等で売っている中古plusも大分安くなってきたな。買おうかな
という訳で目的達成について、自分でも整理できてない。
要求の獲得は難しいな。
iPhone6とアルミフレーム購入検討〜要求獲得の難しさ。
iPhone6をまだ買っていない。理由はアルミフレームが出揃っていないからだ。 幾つ出ているがネットで眺めてもいいか悪いかわからない(以前買って失敗したし)。 色々店に出向いて眺めると質感がいいか、かっこいいか?悪いかがある程度わかる。
ただ、実物に付けられているわけではないので、本当にかっこいいかどうかが分からない。 ストラップ穴がない場合、付けられるかどうかが分からない。
このように、たかだかiPhoneのアルミフレームでさえ、実物に装着して使う事なしにぴったり としたフレームを見つけるのは難しい。
ましてや自由度の高いアプリではなおさらだ。これからのスキルアップの方向性は要求獲得と UI設計になるだろう。
Swiftにみるモデル駆動開発の将来
UMLツールや一頃流行った?MDAという技術にモデルからコードを自動生成というのがある。
効率云々はともかく、オブジェクト指向開発に習熟していくと、クラス構成とコーディングを自由に行き来したくなってくる。
で上記のモデル駆動ツールであるが、結局は流行らなかった。理由は色々あると思う。大規模開発を想定して敷居が高い、値段が高い、オブジェクト指向技術を使いこなせるプログラマーがいない、操作性が悪い等等。
しかし、私自身はプログラミング言語がそれを全面支援していない事。および開発環境もなんか堅苦しく、遊び心が足らなかった事というのが原因だと思う。
話は展開するが、こういう点でAppleがSwiftを打ち出したのは何か意図があってと思うし、そういう意味で期待もしている。解析が用意な静的言語を採用したのはそういう意味からだろう。
Playgroundの発展系でコーディングするとクラス図が自動的に表示されるとか、オブジェクト図を表現するようなデバッガが出てくる事を期待している。なんせ、アップルと合併前のNeXTSTEPでは当時では画期的なモデリングツールやGUIビルダーを世に広めて、その後のRADプログラミングのトレンドを作ったわけだし。
オブジェクト指向のデータ構造的意味論。
オブジェクト指向(というか抽象データプログラミング。そう言い方はしないのでオブジェクト指向)はクラス(ネーティブ型もここではクラス)を秩序を保ってまとめ上げて新しいクラスを作り上げるにすぎない。
それらがいろいろ再帰的に合成されて、基盤ライブラリ、UIフレームワーク、モデル、サービス、UIコントローラー、ビュー、アプリと合成されて、ある種の複合データ構造を形成していく。
責務もそれに伴い、平、主任、係長、課長、部長、事業部長、社長と会社組織のよう巨大化していく。
というわけでオブジェクト指向設計とは複合的なデータ構造を作る作業であり、ドメインモデルや問題領域の基本的な秩序を与え、アーキテクチャは駆動環境の基本的な秩序を与える。したがって、データ構造の一部に手を入れると意識を保って作業しなければ、オブジェクト間の連携は壊れ、シスエムは崩壊する。
スモールオブジェクトプログラミングについて〜クラスはより小さくする
はじめに
SmalltalkerのケントベックやThoughtWorksの中の人が暗に提唱し、最近いろんな識者がネットや本で語っている*1*2、バリューオブジェクト、小さな部品、小さなクラス、小粒クラス、粒度の小さいクラス、スモールオブジェクトプログラミングと言われている、ストイックなまでに小さくしたクラスを使った開発手法について長所/短所を補足、記述しました。
長所
部分的な問題に分解できる。
割り込みに強い(仕事中の電話から、数ヵ月毎の保守まで)。
要求仕様を表現しやすい。
フレームワークと違って、作ったクラスを他のプロジェクトに再利用しやすい。
モデリング作業〜コーディング作業の行き来がしやすい。というかコーディング作業そのものが オブジェクト間の関連やメッセージパッシングを検討する作業にすり替わる。
クラス間の依存が減る?
処理のコーディングレイアウト、コメントとかどうでもよくなる。そんなものやっている暇があれば即クラスに分割を検討。
仕様書からコードが自動生成できる?
クラスがする仕事が明確になる。急に質問されてもパッと答えれるぐらいに。
クラスの不変性を表現しやすい。
同様にクラスの状態が減ってわかりやすくなる。
XPライクなアジャイル開発に強い(1時間置きに客やPMが話しかけて、ちょこまか小さい方針がかわったり、要求仕様を探るためのライブコーディングするような場合)。
重複コードが減る。
短所
O/Rマッパとの相性が悪い。
高い概念構築、構成能力が必要(=オブジェクト指向分析/設計能力)。
正しくクラス分割するにはオブジェクト設計へのかなりな習熟が必要(クラスの命名やメソッドも同様)。
ソースコードが自然とオブジェクト間のメッセージパッシング表現する事になるので、オブジェクト指向に慣れていない人にとってはソースが読みづらい?
パフォーマンスやメモリ使用に影響与える?
スモールオブジェクトプログラミングを禁止されると退職を考えてしまうw。
パッケージ編成を上手に行う必要がある
結論
週末書きます。
条件分岐とメッセージパッシングの差異について。移譲型制御についての考察の続き
オブジェクト指向プログラミングはオブジェクト間の通信によって世界が構築される。 上から降ってくる仕事は、小さなタスクに分割されてどんどん包含されているオブジェクトに移譲される。
一方、If文の使用はオブジェクト指向プログラミングで良くないとされている。 ただ現実にはif文はそれなりに使われている。純粋型オブジェクト言語の代表であるSmalltalkでさえも*1。
で、オブジェクトにとってifとは何かという問いに対しては、私なりの現時点の回答は以下の通り。
- オブジェクトの判断(意思決定)
- (実作業系)下に位置するオブジェクトが行うアルゴリズム(業務)
前者については、管理する以上、意思決定は避けらない。ただし、良い上司と部下の関係と同様に重要な部分だけ判断するにとどめるのが望ましいだろう。ソース可読性とクラスの再利用の観点から。
後者については、下位のオブジェクトについては、どうしても手続き的プログラミングにならざる得ないという事だろう。考えれば見れば当たり前で、下位のオブジェクトが関わるのはバリューオブジェクト、つまり意志を持たないオブジェクトと関わるようになってくるからだと思う。