noki雑記スマートフォン用の表示で見るnoki雑記iOS、ときどきAndroidこの広告は、90日以上更新していないブログに表示しています。2017-04-23デザインパターンの基本をやってみてプログラミング普段作っているアプリを、変更に強く柔軟な作りにしたいなと思い、「Java言語で学ぶデザインパターン入門」を読んでみました。恥ずかしながら、デザインパターンを意識したことがあまりなかったので、実践例がいまいちイメージできないものもありましたが、読んでみた感想をまとめてみます。抽象化(透過的に)すべきか考える本書では抽象化をうまく使い、変化に強そうなコードに仕上げています。いったコードを読んでいると、「こういうコード書いてみたいなぁ」と思う箇所がいくつもありました。そのせいか、複数のクラスに何かしら共通部分が多かったり、if文やswitch文の分岐が多くなってきた場合など、抽象化すべきかを考えるようになりました。仕様が漠然としていたり、共通部分が曖昧な場合は無理に抽象化すべきではありませんが、それでも一考するようにしています。分割・移譲オブジェクト指向でよく目にする「単一責任」と似たことですが、クラスを分割しておくことで目的が明確にし、修正範囲を限定することができます。自分が出来ない(役割ではない)部分に関しては移譲を使うことで、責任範囲を明らかにする手もあります。実際には単一責任のように細分する必要が無いケースもあると思いますが、複雑になりそうな(なってきた)場合は一考してみる必要がありそうです。アップデート作業を行っていたときに、Swift3に対応していないライブラリがあったりして、ちょっと困ったことがありました。ライブラリは便利なので有効活用していきたいと思う一方で、活用している割合が少ないライブラリに関しては自作しても良いかなと思っています。その場合、APIの定義とうまく合わせたり、通信成功・失敗を外から扱いやすくしたりなど、考慮することは多いです。再利用性は高くなると思うのでチャレンジしてみたいです。普段から使用していたパターンも多い標準コンポーネントで使われているものや、考え方が似ているものを自作しているものも含め、ある程度の規模のプロダクトになるといくつかのデザインパターンが使われています。何が適しているかは吟味したいところです。必要なケースとしては、インスタンスが1つのみ必要で、複数存在してはならない場合だと思います。意味が無くなってしまいます。構造体で作ってしまうのも意味がなくなってしまいますね。構造体は値型なので、オブジェクトを複数生成してしますと参照先がばらばらになってしまいます。メソッドを持つクラスや構造体で良いと思うし、どちらかというと構造体で作ってしまった方が分かりやすい気がしています。パターンの区別で迷ったので自分なりにまとめてみます。パターンなのだろうと適当に思っていました。似ているなと思い始めました。パターンを適用する場合は、そういった用意がされていないクラスと、処理に必要なデータなどを結びつける(変換する)機能を実装する目的があります。パターンはイメージしにくいです。パターンのようなことができてしまうと思います。必要であれば別ですが。Mediator画面仕様が複雑になればなるほど、管理すべき対象が散らばっている状況は避けたくなります。パターンを使うことで、考え方がシンプルになりそうな気がしました。役がまとめるパターンですね。例としてログインフォームが出てきましたが、少なからずありそうな状況です。実際にはバリデーションに引っかかった項目を赤くするとか、通信中、データが無い時など、いろいろまとめられそうですね。State使ってみたいというか、実装する際に検討してみたいパターン。UIはほぼ同じものでも、状況によって処理を分けることがあります。通信中やソフトウェアキーボードが表示されている時、アプリ全体で使いまわすデータに状態があるときなど、状態管理用の変数を用意しようとした時にちょっと考えてみようかと思います。Strategy、Decoratorこれも検討してみたいパターン。実践例があまり思いつかなかったのですが、例えばECサイトなんかでカートに入れた商品の合計額を求める場合、各商品の値段の合計やクーポンでの割引、大人一般か学生か小人か、誕生日や記念日での割引、期間限定での・・・など、いくつもの条件を計算に入れなければならない場合に使えないかなと考えてみました。計算や条件式が複雑になるケースってたまにありますよね。なんとかしたいなと思いつつ、実装している最中に仕様が変わったりするケースもあるので、なかなか設計が難しかったりする時もあります。いった時にも何かしらパターンを見つけられればなと思っています。まとめデザインパターンは設計を考える際の1つの材料ですが、特定のパターンを使わないまでも、その考え方を身に着けておくことは非常に有意義だと感じました。オブジェクト指向の技術書を読んでいても、柔軟な設計にするためにいくつかのデザインパターンを使用するケースが出てきます。実際の業務では、技術書に出てくる例よりも複雑な状況は多分にありうるので、慣れるまでは複数のパターンの吟味をし続けることになるかと思います。チームで開発していく以上、自分の設計をメンバーに理解してもらう責任があるので、やはりこういった考え方は重要で、共通認識としてのパターンを知っておくことも必要だと思いました。(3)はてなブログをはじめよう!kinosiさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。