オブジェクト指向では、モデリング（分析）、設計、実装は、切れ目のない一体の活動。初期の分析は初期の設計であり、初期の実装。毎日分析し、毎日設計し、毎日実装しながら、一歩一歩、モデルも実装も進化させていく。Read less
オブジェクト指向プログラミングのためのモデリング入門
オブジェクト指向では、モデリング（分析）、設計、実装は、切れ目のない一体の活動。初期の分析は初期の設計であり、初期の実装。毎日分析し、毎日設計し、毎日実装しながら、一歩一歩、モデルも実装も進化させていく。Read less
アプリ開発と状態遷移の管理 - ninjinkun's diary
このエントリーは読者としてスマートフォンアプリ開発者とWebフロントエンドエンジニアを想定して書いています。 CROSS2016に出るので、最近の自分の考えを整理しておく。 最近ReduxのSwift実装であるReSwiftを使って開発している。使った感想なども最後の部分に書いたけれど、このエントリーの本題はアプリの状態管理の話。 アプリは大きなシングルトン iOS、Android共にアプリを実装しようと思うと大抵シングルトンが必要になる。各ViewController内をまたがってデータを共有したいというユースケースが多いからだ。例えば ユーザーのログイン情報を集約するUserManager コンテンツへのいいね情報を集めるLikesManager ブックマーク情報を集めるBookmarkManager などなど。もちろんアプリの内容によってこれらの顔ぶれは違ってくると思うけれど、大抵U
AndroidではBaseActivityはやめた方がいいかもしれない - Konifar's WIP
先日行われたDroidKaigiで『BaseActivityの是非』が少し語られました。 セッションの中では反対派が多かったようです。 この話は以前から活発で、Qiitaやブログ上でも何度か議論されていました。 BaseActivityの有効性 BaseActivityに処理を求めるのは間違っているだろうか iOSアプリの設計でBaseViewControllerのようなのは作りたくない 自分は業務でも個人アプリでもBaseActivityを作っていたんですが やっぱりBaseActivityはやめようかなぁと方針が変わったので、少し思考を整理しておきます。 双方の主張 まずは肯定派と否定派のポイントを整理してみます。 肯定派 共通処理をまとめられるのでDRYになる。 将来共通の変更があった時に対応しやすい。 必ず必要なもののみ実装するようにすれば肥大化は防げる。 否定派 is-a関係じゃ
コードに対してコメントを書くと実装に関するコメントになる - きしだのHatena
おととい、渋谷JVMというイベントがあって登壇させてもらったんですが、そのあとビール飲んでるときに、ぼくが「コード書く前にコメントだけ書くのいいよね」と言ったあとの返答としてきょんくん(kyon_mm)が言った言葉。 全体としては 「コード先に書いてそのコードに対してテストを書くと実装に対するテストになるし、コードを先に書いてそのコードに対してコメントを書くと実装に対するコメントになる」 という感じ。 ここに至るまでの話もおもしろかったんだけど、ここでは、コメントについて書いてみます。 まず、実装に対するコメントってどういうのかというと、こういうの。 id = findId(name); if(id == -1){ // idが-1だったとき登録 register(name); } いやそれはコード見ればわかるから、ってやつですね。 これは、こうやるとより適切です。 id = findId
Annotations Support Library が Android Studio 0.5.5 でサポートされた - ひだまりソケットは壊れない
Annotations Support Library の概要 ちゃんとしたドキュメントが見当たらないのですが、 *1 Android Support library のリビジョン 19.1.0 から、新たに Annotations Support Library が追加されました。 このライブラリは、その名のとおり Android アプリ開発時に用いることができるアノテーションの集まりです。 例えば、@NonNull や @Nullable といったアノテーションが含まれています。 さらに、Android Studio ではバージョン 0.5.5 からこれらのアノテーションをサポートしており、アノテーションを使うことでいろいろと警告を出してくれるようになっています。 Support for the new annotations which shipped with the most r
Androidコードディング規約 - Qiita
App(Application)## 1.命名規則### アプリケーション名#### 普通の英語名（スペースを含んでも構わない） UpperCamelCase プロジェクト名#### UpperCamelCase Src(Sorce)## 1.命名規則### パッケージ名#### すべて小文字 スペースは削除して、アンダースコア(_)に変更する。 srcの中のパッケージ名： メインパッケージ：<リバースドメイン名>.<アプリケーション名> メインパッケージ以外：<メインパッケージ>.[controller|model|view...] 詳細な構成については、2のフォルダパッケージ構成に記す。 ファイル・クラス名#### UpperCamelCase 名詞 Activity、Fragment、AdapterなどはComponent名を末尾に付ける メソッド名#### lowerCamelCa
やさしい設計 〜 Android 編 - Qiita
アプリを作っていてありがちなこと Android には、画面を構成するための Activity というコンポーネントがあり、概ね MVC フレームワークの Controller に相当する機能を持っています。 MVC といえば、肥大化する Controller というのがよくある問題として挙げられますが、Activity も例に漏れず、往々にして肥大化しがちです。 また、Model も、その責務を詰め込んでいくと肥大化しやすいレイヤと言えます。 この投稿では、Controller や Model の肥大化を極力防ぐためのレイヤわけを、Android アプリ向けに書いていきます。 Activity を綺麗に保つ Activity は、Controller として、様々な UI から受けるイベントを受けて、適切にハンドリングする役割を持っています。 OptionsMenu や ContextM
モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita
はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル（＝クラス）やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません！ payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:
リファクタリング―プログラムの体質改善テクニック読んだ - 銀の人のメモ帳
リファクタリング―プログラムの体質改善テクニック (Object Technology Series) 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史出版社/メーカー: ピアソンエデュケーション発売日: 2000/05メディア: 単行本購入: 94人 クリック: 3,091回この商品を含むブログ (307件) を見る 残念ながらピアソン桐原から出版されていたので、現在は手に入りにくいんだけど、読んだ。 内容的には、リファクタリング手法のカタログみたいな感じだと思う。５章くらいまでは、導入とか、リファクタリングの心構えみたいな事が書いてある。 リファクタリングをするときに「いつすべきか？」というのが問題になると思うんだけど、この本では、機能を実装するときにその周辺をリファクタリングするといいと書いてあった。これは「動いてるものは触るな」っていう考
自分流 View Controllerの作り方 その2
図を適当に補足 ViewWrapperは既存のすでにあるどうしようもない設計のViewを何とか救いたいときに非常に便利、Wraper / Decoratorパターンを適用してボタンのタップを奪い取ってViewHelperに流すみたいな役目をする ViewHelperは簡単に言うならUITableViewControllerのdelegate, datasourceだけを担うオブジェクトみたいな感じ。要するにView専用のドメインロジックを書くオブジェクト Viewの表示を制御するドメインロジックが途方もなく大きくてViewControllerに納めるのが不可能になってしまったときに超便利 Serviceは準ドメインロジックだと思っている、たいていの場合セミシングルトンみたいにする（通信が絡むので複数画面をまたいで使うことがほとんど） Androidの場合はここ、普通にServiceクラスで
自分流 View Controllerの作り方 その1
その2はこちら 以前勉強会の際に発表した View Controller の作り方のメモをまとめてみました。あくまでメモなので中身はうまくまとまっていませんが、何かのご参考になればと思います。 通信が絡んでくると、たいていの人がやりがちな問題（実例） API通信のレスポンスを処理するコードがViewControllerの中に入っている API通信が3種類必要で、Aを実行したあとにBとCを実行しなければならないとか ABCのレスポンスJSONのパースまでViewControllerでやっている というかAPIの呼び出しの組み立てだとかURLの指定だとか自体がIBActionの中に入っていたりする API通信だけじゃなくてIn App Purchaseなどでも同様の事例が見られる それに対する対応策。そもそもなぜこのような問題が発生するのか？ Outletの生成・更新・レイアウトが分離されてい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードを書く際の指針として見返すサイトまとめ - Qiita