いまさら聞けない「オブジェクト指向設計の3つのコツ」～オブジェクト指向設計問題解説 #objectoriented - CodeIQ Blog
CodeIQ中の人、millionsmileです。 いろいろ経歴を積むと、「いまさら聞けない」ことが増えてきます。「オブジェクト指向」というのもそんないまさら聞けないものの一つでしょうか。 そんなわけで、いまさら聞けないことをイマサラ問題として出題してみました。 問題は、日本のITエンジニアの父と言いたくなるくらい温かみのあるフィードバックをしてくれることで好評な有限会社システム設計の増田亨さんからの出題です。オブジェクト指向設計について2問出題していただきました。総計65名もの方に挑戦いただきました！ 問題の解説記事は、オブジェクト指向設計の3つのコツを中心に説明してくれていますので、読みやすいですし、頭にすっと入ってきます。 ではでは、増田亨さんによる解説記事をお楽しみください。 https://codeiq.jp/ace/toru_masuda/ ◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇◇
必須のプロパティをコンストラクタで受け取る設計にすべきか？
しゃるしぃ @chocolamint 「オブジェクトが使用可能になるまでに追加でプロパティに値をセットする必要がないように設計する。」は結構微妙。コンストラクタの引数でセットにするとオブジェクト初期化子に比べて見づらいし、デフォルトコンストラクタが消えると何かと不便。絶対必要なプロパティなら1回動かせばわかるわけだし 2013-02-15 13:31:29 しゃるしぃ @chocolamint 引数が増えるならクラス化すればいいってことになるとなおさら微妙。だってHogeArgumentsクラスのプロパティをセットしなかったら一緒やん。 2013-02-15 13:32:15
ポリモーフィズムを活用するとなぜ if や switch が消えるのか？ - Qiita
if (売上.勘定科目 == 勘定科目.現金) { // 計算するロジック } else if (売上.勘定科目 == 勘定科目.売掛金) { // 計算するロジック } else if (売上.勘定科目 == 勘定科目.有価証券) { // 計算するロジック } このようなコードはしばしばスパゲッティになりがちですし、 項目が増えるたびに、条件分岐を増やさないといけないので保守も大変です。 売上の課目ごとに計算方法が違いますが金額計算するという振る舞いは同じです。 このコードからif文を駆逐するにはどうしたらいいでしょうか？ 型やフラグ、enumによる条件分岐はたいていの場合、ポリモーフィズムによって消し去ることができます。 ポリモーフィズムとは異なる型のオブジェクトを同一視し、そのオブジェクトの型によって動作を切り替えることです。 ポリモーフィズムは動的型付け言語ではダックタイピング、
状態管理用の変数をインスタンスに持たせるなこのタコって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
たとえば、今、「ユーザーが方向を入力したらプレイヤーが動くゲーム作りたい」みたいなはなしがあるとする。その場合、モデルクラスはまあシンプルな実装として下のようなものが考えられると思う。 「できたよー」って見せにいったら、今度は「あのさー、『高速移動モード』っていうモード欲しいんだよね。そのモードだと二倍速で動くの」って言われたとする。シンプルにやるとこうなりますね。 「できたよー」って見せにいったら、今度は「なあ、すげえ面白いこと考えたんだけど、『蟹モード』って面白くない？横は4倍速で動くんだけど縦は半分の速度で動くの」とか言われたわけです。あなたは「お、おう」と言って、以下のようにコードを修正しました。 これ、ヤバい感じしますね。破滅の匂いがする。「今度は『よっぱらいモード』欲しいな〜。入力に関係なくランダムに動くの」みたいなこと言われたら確実に複雑さが爆発してメンテ不能になり鬱になり死
プログラミングの「抽象化」ってどういう意味で、なぜ必要なのか - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
＜追記＞いろいろ反応あってたしかになーって思いましたが、ここで説明されてるのは「汎化」とか「パラメタライズ」としたほうが正しいですね。抽象化というと、一塊の手続きをブラックボックスにして、実装を隠蔽する面のほうが正解に近いです。でもまあそこを差し引いて読んでいただければ、それなりに有用ではある記事だと思うので、このまま残しておきます＜/追記＞ プログラミングに限らない話かもしれませんが、ふだんの生活で触れないような概念というのは、一度わかってしまえば便利なんだけど、どうしてもとらえどころがない、というようなことが多いと思います。プログラミングにもそういう概念はたくさんあって、わたしのような凡人は新しい概念にぶち当たるたびに苦労しています。今日はそんな中で「抽象化」という言葉について、「昔の自分にこうやって説明してあげたかったな〜」という説明をします。 プログラミングを学んでいく中で、「とり
デザインパターン厨よ、これが黄金の回転だ - @ledsun blog
状態管理用の変数をインスタンスに持たせるなこのタコって話 に面白い機能追加とリファクタリングの例がありました。TDDに慣れ親しんだ身からすると、 「黄金の回転のリズム」 テストを書く テストが通る最低限のコードを書く リファクタリング に比べると、リファクタリングのサイクルが大きいなと感じたので自分もやってみました。 元のクラス シンプルなmoveメソッドで移動方向に動くPlayerクラス*1 機能追加1 二倍速 2倍速で動くようにしたい 二倍速く動くなら二回 move すればよい サブクラスFastPlayerを追加して実現。 機能追加2 カニ 横は4倍速で動くんだけど縦は半分の速度で動く KaniPlayerクラスを追加してとりあえず機能を実現 class KaniPlayer < Player def move(direction) case direction when :up @
約3年かけてプログラマ向けニュース推薦アプリを作り直した話 - Qiita
概要 『もっとより良いニュースアプリはできないだろうか』 そう考えてMenthasというニュースアプリを開発し、プログラマ向けニュースキュレーションサービスを作ってみた話 という記事をQiitaに書き、自分の予想を超えた反響を受けてから約3年になります。 しばらく開発の更新は留まってしまいましたが、ニュース推薦に関しての探求が終わったわけではなく、むしろ見えてきた課題のために数多くの論文を読んだりプロトタイピングを繰り返していました。 そしてつい先日、これまで解けなかった問題に対してようやく答えを自分なりに導き出すことができたため、骨格となるアルゴリズムの刷新に始まり、ついで開発もインフラからサーバサイド、フロントエンド・デザインと、全面的なリニューアルを行うことに成功しました。 新しいMenthasは以下のリンクから使用することができます。 https://menthas.com 今回は
DeNAのデータ分析基盤 あらゆるサービスのログを蓄積・分析するインフラの仕組み
DeNAにおける、データ活用の重要性 松木秀憲氏（以下、松木）：よろしくお願いします。「2020年代に向けたDeNAの分析基盤」というタイトルでお話をさせていただきます。松木と申します。株式会社ディー・エヌ・エーのAIシステム部でAIと分析の基盤を担当しております。 なぜ「AI＆分析基盤」という担当になってるかなどを含め、お話させていただきたいと思います。 まずDeNAとAIシステム部という部署について、紹介させていただきます。 DeNAという会社はいろいろなサービスを提供している会社です。そして、自社独自であるいはパートナーさまと一緒に日々多くの価値あるサービスを創出するべく取り組んでいます。それでいて、大規模のインターネットサービスのプラットフォームの構築・運用力も持った会社です。 そのDeNAでのデータ活用ですが、やはりサービスを提供している会社なので、スライド右下の部分ですが、サー
正しいデータは正しい設計に宿る - そーだいなるらくがき帳
って話をbuilderscon 2018でします。 builderscon.io 当日利用する資料はこちら。 speakerdeck.com 私のセッションはbuildersconの最終セッション。 皆さん素晴らしいセッションが並ぶ中で選択肢に迷ってる方も居ると思います。 だから先に公開しておきますのでこれをご覧になって、他のセッションに行くというのも有りだと思います。 あと事前に去年のトークを見てくれると当日はより理解が深まると思います。 同じ話を2回しても皆さんにとって勿体無いのでリファクタリングの細かい前提の話は当日はしません。 soudai.hatenablog.com 動画はこちら。 www.youtube.com これを見て、面白そうだなって思ったらぜひ、遊びに来てください。 僕が知ってるRDB設計、そしてRDBの歩み方を全てお伝えします。 あなたの新しい道の一歩目をご用意しま
エラーメッセージはフォームのどこに表示するべきか
UX Movementの著者および設立者です。ユーザー体験のデザインスキルの開発を手助けしてよりユーザーフレンドリーな世界のために、このブログを創設しました。 フォームのどこにエラーメッセージを配置していますか？ ユーザーの期待する場所にエラーメッセージが置かれていないと、ユーザーはフォーム入力を完了できなくなってしまうかもしれません。 フォーム入力を間違えたら、ユーザーはそれを修正して送信し直すために、なにが間違っていたのかを理解する必要があります。フォームを完了しようと思っていたとしても、それがあまりにも大変であればユーザーは心変わりしてしまうでしょう。 フォームの上か、フィールドのインラインか エラーメッセージの配置場所でもっとも一般的なのは、「フォームの上」と、「エラーのあるフィールドのインライン」という２箇所です。どちらの配置場所が、ユーザーにとってより直感的でしょうか？ 調査に
物語は超簡素、ダンジョンなし、街も見た目だけ、ラスボスはポッと出 ─ それでも十二分におもしろいRPGがある - サガ スカーレット グレイス 緋色の野望
ゲームのジャンルというものは一括りにされやすいが、それはあくまで便宜上の話だ。一口にRPGといってもその内容はさまざまで、目指すおもしろさもまったく違うし、なんなら見た目もまったく違う。 『OCTOPATH TRAVELER』（2018） 上の画像は2018年7月13日にスクウェア・エニックスから発売された『OCTOPATH TRAVELER』のスクリーンショットである。HD-2Dという技術を用いて作られたフィールドマップは美しく、本作を遊んでいない人でもこれを見ただけでも興味が湧くだろう。 本作は貪欲なタイトルでもあり、バトルにはブーストシステムというものを搭載したり、世界を探索する要素もいろいろあったり、各キャラの物語も量が多く演劇のようなカットシーンすらある。かつてのRPGを遊んだことのある人ならば、いろいろなタイトルを思い浮かべるだろう。そのくらいにたくさんのものを取り入れようとし
ソーシャルゲームの価値を上げるログデータのつくりかた
はじめに 現在データ分析基盤の再構築を担当している、サーバーサイドエンジニアの小川詩織です。これまで私は4つのソーシャルゲームの新規開発・運用を経験してきました。そこでの知見と考察をまとめます。 ログデータは、調査などに必要なただの履歴という立場に置かれがちです。ですが、作業工数を大幅カットしたり、定量的な効果測定や判断ができるなど、適切なログ設計と活用により利益に繋がる施策の指針にすることも出来るものです。 ログには、コンテンツ内容により色々な種類や設計があるため、全てに共通する最適解はありません。ですが設計の指針となるべき事柄はあるので、ログの種類や活用例、設計の仕方、工夫などについて入門的な内容について一通り触れていきます。その中でログの可能性も一緒に感じていただきたいと考えています。 対象とするログと、全体像 今回はこれまでの経験が最活かせるソーシャルゲームのログのみを想定した内容
書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだので大事なポイントを自分のためにまとめてみた - Qiita
書籍「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読んだので大事なポイントを自分のためにまとめてみたGo初心者まとめarchitectureCleanArchitecture はじめに Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだ。 なぜソースコードを綺麗に書くのかから始まり、オブジェクト指向、コンポーネントの原則、アーキテクチャと体系的にまとまっている良い内容だった。 この記事では、本書の内容の引用を踏まえながら自分の考えの振り返りをまとめたものである。 実際にGoで実装したりしたので、なにか間違いなどあれば指摘していただきたい。 クリーンアーキテクチャの書籍を読んだのでAPIサーバを実装してみた 対象読者 ・Clean Architecture 達人に学ぶソフトウェアの構造と設計を読むか迷ってる人 ・Clean Arc
QiitaのTypo検出にtextlintを追加しました + 編集リクエストを送り続けて気づいたこと - Qiita
人間性をさがせよ QiitaのTypo検出 - Qiita にtextlintを追加しました。 まとめ textlintの追加は簡単だった ほんのり(優しく)チェックできるtextlintプラグインを探さなければならない ホワイトリスト機能を改善してもらった textlintに引っかかる投稿はそこそこある 誤判定は割と出る。が、一部は慣れでスルーできる 編集リクエストは一つにまとめて送信する 編集リクエストが採用されなくても泣かない 追加コード 人間性をさがせよ QiitaのTypo検出 - Qiita のコードを見ていないとなんのこっちゃですが、diffで表示します。 --- a/index.js +++ b/index.js @@ -4,6 +4,9 @@ const axios = require('axios'); const DICTIONARY = require('./dic
Getter/Setterを避けて役に立つドメインオブジェクトを作る - かとじゅんの技術日誌
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでます。モデリングに関しては成分薄めですが、よい本だと思います。はい。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 作者: Robert C.Martin,角征典,高木正弘出版社/メーカー: KADOKAWA発売日: 2018/07/27メディア: 単行本この商品を含むブログを見る 本書の大筋から少し逸れるが、「5章 オブジェクト指向プログラミング」の「カプセル化」が面白かったので、これを切り口にモデリングについて考えてみる。 OO言語のカプセル化はすでに弱体化している オブジェクト指向の三大要素の一つである、カプセル化について、以下のようなことが書いてあります。 「カプセル化」がOOの定義の一部となっているのは、OO言語がデータと関数のカプセル化を簡単かつ効果的なものにしているから
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RDB THE Right Way - builderscon 2018/ RDB_THE_Right_Way
MySQLで論理削除と正しく付き合う方法
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
trait と abstract class の使い分け
ゲームバランスってどうやって調整してるの？
