Kotlinとスプラトゥーンで学ぶデザインパターン【2. Adapter】
なんとか第二回もできました！
今回はAdapterパターンです。
Adapterパターンとは
デザパタ本には
「すでに提供されているもの」と「必要なもの」の間の「ずれ」を埋めるデザインパターン
とあります。この通りなんですが、じゃあスプラトゥーンでこのパターンが使えそうな所はあるかなぁと考えました中々思いつかず。
やっと思いついたのがスプラトゥーン２のローラーの攻撃方法の変更でした。
１では横振りのみでしたが、２ではタテ振りという概念が追加されました。
この差をAdapterパターンで埋めてみることにしました。
実装
まず、１のときの実装は以下のようになっています。
val roller : SplaRoller = SplaRoller()
println(roller.swing())
ローラークラスの詳細は以下
open class SplaRoller { fun swing():String { return "Swing!" } }
出力結果
Swing!
ただ振るのみ。
次に２のローラーの実装は以下のようにメソッドを呼び出せる想定で実装します。
val newRoller : SplaRoller2 = NewSplaRoller()
println(newRoller.swingHorizontal())
println(newRoller.swingVertical())
そのために必要なものが、まずは２仕様のインターフェース
SplaRoller2.kt
interface SplaRoller2 { fun swingHorizontal(): String fun swingVertical(): String }
旧仕様と新仕様を繋ぐクラス
NewSplaRoller.kt
class NewSplaRoller : SplaRoller(), SplaRoller2 { override fun swingHorizontal(): String { return "Horizontal " + swing() } override fun swingVertical(): String { return "Vertical " + swing() } }
出力結果
Horizontal Swing! Vertical Swing!
という感じです。ちなみに縦振り・横振りは振り始めにジャンプしているか否かで判定されるようです！
実装してみて
実装パターンをパッと見た所、クラス・インターフェースが冗長な感じがしました。
元の実装をそのとき必要な実装に合わせるだけならSplaRollerクラスを継承してSplaRoller2を作るという方が簡単ではないかと。
でもよくよく考えると、単純に継承するだけだとSplaRollerクラスが変更された時に影響を受けやすい気がします。できるだけ疎結合にしておくという意味でやはり間に継承or移譲するクラスを挟んだ方が良さそうという結論に至りました。
蛇足
これは「ダイナモローラー」。
— Splatoon（スプラトゥーン） (@SplatoonJP) 2017年6月8日
振りかぶりは遅いが、広範囲にインク攻撃ができるローラータイプのブキだ。
タテ振りはかなり遠くまで届くので、これまで苦手だった遠距離の相手も牽制できそうだ。
サブは「トラップ」、スペシャルは「ハイパープレッサー」だ。 pic.twitter.com/aWOgGl2y9t
気になっていたダイナモの縦振りやはり存在するようですね。
ローラーですら相当な飛距離なのでダイナモならどんだけ飛ぶんだよ！とか楽しみにしてます。
想像では、ダイナモの縦振り＝Fateのアーサー王のエクスカリバーです。
Kotlinとスプラトゥーンで学ぶデザインパターン【1. Iterator】
頭の中がごちゃごちゃ
最近自分の中で考えてることをごちゃ混ぜにしてアウトプットしたらタイトルのような結果になりました。
イカ、最近の自分の思考
- 「サーモンランとか激アツ！これはローカルでできてほしい」
- 「あかべこ本一通りやったけど次は何しよう」
- 「スプラトゥーン２発売まで２ヶ月きった！」
- 「WiiU売ってしまってスプラトゥーンできない。やりたいやりたいYoutubeで我慢」
- 「KotlinがGoogle公式の言語に！これはプロダクト採用ワンチャンある。勉強しよう」
- 「２はとりあえずチャージャーから入ってエイムリハビリしていこう」
- 「アーキテクチャ意識して制約加えてコーディングするようになってから悩む時間が増えた」
- 「制約の中でもスムーズにコーディングするためにはデザインパターン的な技が必要では？」
- 「赤木も山王工業戦に備えてスピンムーブとか練習してたし、やはり新しい技（デザインパターン）を習得しよう」
ベースになっているのは結城浩さんのデザインパターン本です。
それをKotlinで書き直してみました。第一回目はIteratorパターンです。
ソースは
DesignPatternInKotlin/src/iterator at master · kseito/DesignPatternInKotlin · GitHub
にまとまっています。
Iteratorパターン
Iteratorパターンとは、何かの集合から要素を順番に取り出して処理していくものです。
今回は、スプラトゥーンのイカの画面を意識して作りました。
バトルで使用する武器を選択する画面です。
武器(Wepon)があり、それがリスト化(WeponList)されそれが一覧表示(WeponIterator+println)されます。
Wepon.kt
data class Wepon(val name: String, val range: Int, val power: Int, val quickness: Int)
WeponList.kt
class WeponList(count: Int): Aggreagte { override fun iterator(): Iterator { return WeponIterator(this) } private var wepons: Array<Wepon?> = arrayOfNulls(count) private var count: Int = 0 fun add(wepon: Wepon) { wepons[count] = wepon count++ } fun getWeponAt(index: Int): Wepon? { return wepons[index] } fun getCount(): Int { return count } }
WeponIterator.kt
class WeponIterator(private val weponList: WeponList) : Iterator { private var index: Int = 0 override fun next(): Any { val wepon: Wepon? = weponList.getWeponAt(index) index++ return wepon ?: Wepon("未開放", 0, 0, 0) } override fun hasNext(): Boolean { return weponList.getCount() > index } }
デザインパターンとして作成するクラスはここまで（Interfaceは省略します）
あとは動かすだけ。
Main.kt
fun main(args: Array<String>) { val list: WeponList = WeponList(5) list.add(Wepon("わかばシューター", 32, 32, 75)) list.add(Wepon("スプラシューターコラボ", 50, 45, 55)) list.add(Wepon(".96ガロンデコ", 68, 85, 15)) list.add(Wepon("カーボンローラー", 20, 65, 70)) list.add(Wepon("ダイナモローラー", 72, 30, 20)) val weponSelect: Iterator = list.iterator() while (weponSelect.hasNext()) { val wepon: Wepon = weponSelect.next() as Wepon System.out.println("武器名:" + wepon.name + "、射程:" + wepon.range + "、攻撃力:" + wepon.power + "、連射力:" + wepon.quickness) } }
出力結果は
武器名:わかばシューター、射程:32、攻撃力:32、連射力:75 武器名:スプラシューターコラボ、射程:50、攻撃力:45、連射力:55 武器名:.96ガロンデコ、射程:68、攻撃力:85、連射力:15 武器名:カーボンローラー、射程:20、攻撃力:65、連射力:70 武器名:ダイナモローラー、射程:72、攻撃力:30、連射力:20
となります。
RxJava2.0の基本クラスを学ぶ
今さらですがRxJava2.0について学びたいと思います。
RxJava2.0ではObservableに似たクラスとしてFlowable, Maybeが追加されています。
今回は復習の意味も込めて、Observable, Single, Completable, Maybeの違いについて調べてみたいと思います。
Flowableはだいぶ特殊でObservableで扱うストリームでバッファを考慮するとき等に使うようで、（自分にとっては）現状あまり用途がないので割愛します。
Observable
0~N個のオブジェクトの流れ、完了、エラーを扱います。
プログラム
Observable.range(1, 10) .subscribe(System.out::println);
出力結果
1 2 3 4 5 6 7 8 9 10
Single
1つのオブジェクトの流れ、エラーを扱います。 onCompleteは呼ばれないです。
プログラム
Single.just(1)
.subscribe(System.out::println);
出力結果
1
Completable
オブジェクトの流れは扱わず、完了かエラーの判定のみ扱います。
完了
プログラム
Observable<Integer> observable = Observable.range(1, 10); Completable.fromObservable(observable) .subscribe( () -> System.out.println("Complete!"), e -> System.out.println(e.getMessage()));
出力結果
Complete!
エラー
プログラム
Completable.fromObservable(observable)
.subscribe(
() -> System.out.println("Complete!"),
e -> System.out.println(e.getMessage()));
出力結果
damepo
Maybe
0~1個のオブジェクト、エラーを扱います。 onCompleteは呼ばれます。
プログラム
Maybe.just(1) .filter(integer -> integer == 2) .defaultIfEmpty(3) .subscribe(System.out::println);
出力結果
3
感想
SingleとMaybeの違いが分かりづらいです。 Singleに0個のオブジェクトの時の処理を追加したのがMaybeなのかな・・・。もっと勉強しないと！
参考URL
GitHub - ReactiveX/RxJava: RxJava – Reactive Extensions for the JVM – a library for composing asynchronous and event-based programs using observable sequences for the Java VM. RxJava2.0 Observable, Single, Maybe, Completableの使い分けメモ - Qiita
KalitaのネクストGを購入しました！
今回は念願のネクストGを購入したので使い心地や感想を書きたいと思います。
きっかけ
前々から今使ってるコーヒーミルの微粉の多さに悩んでましたが、次買うとしたら高性能なコーヒーミルを買いたかったので躊躇してました。
そんなとき、神乃コーヒーのコーヒーセミナーに参加して、そこで使用していたミルと挽いた豆の粒の揃い具合に驚愕しました。フジローヤルのミルを使用していたのですが、そんなに大きくないサイズでしっかり粒の揃った豆を挽けるとは・・・これは買うしかない！という流れです。
そのあとコーヒーミルの調査をして最終的にみるっこDXとネクストGが残りました。なぜネクストGにしたかと言うと完全に値段の問題です。現時点でネクストGの方が１万円くらい安かったからです。性能的にもそこまで差は見られなかったのでネクストGを購入しました。
良かった点１ 雑味が減った
当然といえば当然ですが粒が揃って微粉が減ったので以前より雑味が減りました。これで新鮮なスペシャリティーコーヒーを挽いて飲んだ日にはその日1日上機嫌で過ごせそうです！
良かった点２ 音が静か
以前から音はあまり気にしていなかったのですが、以前使っていたコーヒーミルよりも音が小さくなりました。ネクストGの特徴としてカッターの回転速度が遅いという情報があったのでそのおかげかもしれないです。
まとめ
結果として、ネクストGのおかげで以前より美味しいコーヒーが飲めるようになったので買って正解でした。道具をアップグレードしてより美味しいコーヒーが飲めるようになるのって、RPGに近い感じがしますね。
「成長している」という感覚を大事にしながらより美味しいコーヒーを追求していきたいと思います。
次は水出しコーヒーかなぁ。サイフォンもやってみたい。
おまけ情報
コーヒーセミナーで使ってたコーヒーポッドが良かったので紹介しておきます。
タカヒロというメーカーのコーヒーポッドを使っていたのですが、狙ったところにお湯を注げてあまりの使いやすさにセミナーの講師の方に聞きました。注ぎ口の先端部が曲線になっているのが特徴らしいです。
いつか買いたい・・・
ConnectionResult.SERVICE_VERSION_UPDATE_REQUIREDを受け取ったときに試すこと
検証端末としてHuawei MediaPad M3を購入して自作アプリとかの動作検証してたらマップ表示ができなくてはまったので備忘録として記載します。
原因
if (ConnectionResult.SUCCESS != GooglePlayServicesUtil.isGooglePlayServicesAvailable(this)) { //エラー処理 }
マップ表示前に上記のように分岐させてGoogle Play Servicesが有効かチェッックしていたんですが、ここで今回購入した端末のみConnectionResult.SERVICE_VERSION_UPDATE_REQUIREDを返却されてました。 内容としてはPlayストアを最新にしてくれってことらしいんですが既に最新版なっていました・・・。
解決策
原因はPlayストアのパーミッションでした。
端末の初回設定後、ログインした以外特に何もしていないのですがパーミッションの状態が下記のようになっていました。
位置情報がOFFになっている・・・
位置情報パーミッションをONにしてあげることで解決しました。
暫定対応策としては上記のような方法になりますが、根本対策はGooglePlayServicesUtil.isGooglePlayServicesAvailableではなく
GoogleApiAvailability.isGooglePlayServicesAvailableを使う方法らしいです。deprecatedメソッドは使わない方が良いですね。
我が家のコーヒー事情
自分がコーヒーをハンドドリップで淹れ始めたきっかけは一昨年から始めたコーヒーダイエットです。
朝食にバターを入れたコーヒを飲むことに最初はすごい抵抗感がありましたが、今では完全に習慣化されて朝食にご飯を食べることに違和感があるくらいです（笑）
なぜ続けられたか考えてみると、どうせ飲むならより美味しいコーヒーを飲みたいと思って試行錯誤するのが楽しかったからだと思います。
今回は、そんな試行錯誤の状況を時系列とコーヒー豆・ドリッパー・ミルの３要素で振り返ってみたいと思います。
2015年11月頃
コーヒー豆
カルディコーヒー・近所の個人経営してる珈琲屋さんから購入
ドリッパー
カリタ製コーヒードリッパー
ミル
なし
コーヒーダイエットを始めた時期ですね。
まずは最低限の道具で始めようと思ってドリッパーだけ買いました。
豆は近所にカルディがあったので基本的にはそこで買うようにして、たまにスペシャリティコーヒーを売っているお店で買ったりしてました。
スペシャリティコーヒーは美味しく感じますが継続的に飲むにはちょっと高すぎました。。。
2016年
コーヒー豆
ドリッパー
カリタ製コーヒードリッパー
ミル
カリタ製セラミックミル
この年はまず、コーヒーミルを買いました。粉の状態で買うと１週間たたないうちに酸化した豆の匂いがしたり蒸らすときに豆が膨らまなくなったりしました。豆を買ってるお店で聞いてみたら、豆は豆のまま買って飲むときに挽くといいですよ、と教えて頂きました。そこでオススメのミルを聞いた結果がこれでした。たしかに豆のまま保存したほうが持ちがよかったです。
あと、この年の一番の発見は辻本珈琲さんの豆ですね。会社内のふとした話から知ったのですが、500gで約600円とコスパがやばかったので即購入しました。スーパーで売ってる豆と同じくらいの値段なのに蒸らすとめっちゃ膨らむ！と感動しました。今では常連で1kgとか普通に買ってます。
2017年
コーヒー豆
辻本珈琲
ドリッパー
- カリタ製コーヒードリッパー
- ハリオ V60ドリッパー
ミル
カリタ製セラミックミル
今年ですね。ハリオのV60が気になってて買おうと思っていたのですがスペース的な問題で買えなかったのですが引っ越しを機に買いました。
使った感じコーヒーの抽出量をコントロールできるのがよかったです。濃いコーヒーが苦手な人には薄めで入れたりできるので。
今年はあとミルを新調したいです！今のミルだと微粉がやばいことになってて茶こしで微粉を落とすとかなりの量の微粉が取れます。豆の４分の１くらいは微粉になってそうな勢い・・・。もっといいやつ買う。
以上です。快適なコーヒーライフを
Settings.Global.getFloatでAnimationScaleが取得できない
Android 6.0.1の端末でAnimationScale(Transition, Duration)が取得できない問題に遭遇しました。
Mからパーミッション変わった影響かなーとパーミッション見直したり、Settings.Globalのソースを見ても特に問題ないような・・・
ぐぐってもアニメーションOFFにするとスマホが早くなるよ！みたいな記事ばかりでうんざりしているとCLIで端末の設定を覗けることが判明。
試して見ると
$ adb shell settings list global | grep anim $
何も表示されず・・・。設定が見えない。さらに調べてみると
AndroidフレームワークのAnimation設定まわりでバグがあったようです。
これの影響かどうかわからないですが、開発者設定でアニメーション設定を変更したところ
$ adb shell settings list global | grep anim animator_duration_scale=1.0 transition_animation_scale=1.0 window_animation_scale=1.0 $
表示されるようになりました。何かスッキリしないですがそんなことがありました。
