クラス · JavaScript Primer #jsprimer
クラス 「クラス」と一言にいってもさまざまであるため、ここでは構造、動作、状態を定義できるものを指すことにします。 また、この章では概念を示す場合はクラスと呼び、クラスに関する構文（記述するコード）のことをclass構文と呼びます。 クラスとは動作や状態を定義した構造です。 クラスからはインスタンスと呼ばれるオブジェクトを作成でき、インスタンスはクラスに定義した動作を継承し、状態は動作によって変化します。 とても抽象的なことに思えますが、これは今までオブジェクトや関数を使って表現してきたものです。 JavaScriptではES2015より前まではclass構文はなく、関数を使ってクラスのようなものを表現して扱っていました。 ES2015でクラスを表現するためのclass構文が導入されましたが、このclass構文で定義したクラスは関数オブジェクトの一種です。 class構文ではプロトタイプベ
[Think IT] 第2回：ユースケース図を学ぼう！ (1/3)
【伝わる！モデリング】はじめようUML！ 第2回：ユースケース図を学ぼう！ 著者：株式会社テクノロジックアート 照井 康真 公開日：2008/04/08（火） ユースケース図とは 前回は、UMLに関する全般的なお話から、業務分析でアクティビティ図を使用する方法を説明しました。今回は、要求分析でユースケース図を使用する方法を説明します。 ユースケース図は、UMLの生みの親であるスリーアミーゴスの1人、ヤコブソンがOOSEという方法論から取り入れた図です。システムが、外部から求められる機能的な要求を表現します。開発工程の中では主に要求分析段階で、開発者がユーザに機能的な要求を確認するために記述されることが多い図となります。図1は、最もシンプルな表記によるユースケース図の例です。 「サブジェクト」は、書いても書かなくてもそれほど違いはありませんが、ここでは後の説明のしやすさのために記述しています
Go言語での構造体実装パターン
Go言語での構造体実装は、埋込や独自コンセプトのインターフェースといったGo言語独自の機能を理解して行う必要があります。 今年からGo言語を始めましたが理解が曖昧なままだと実装に迷うことが何度かありました。今回よい機会なので、Go言語での構造体実装パターンとしてまとめてみることにしました。 構造体実装パターン 実装パターンの洗い出しとして、GoFデザインパターンをGo言語で実装する手法をとりました。 その中で繰り返し現れる実装をGo言語での構造体実装パターンとしてまとめてみました。 コンストラクタ関数 エクスポートによるアクセス許可 インターフェースによるポリモフィズム 構造体によるポリモフィズム 構造体によるサブクラス・レスポンシビリティ 構造体による移譲 関数による移譲 以下、それぞれのパターンを解説していきます。 コンストラクタ関数 Go言語には構造体のコンストラクタがないため、構造
感想：オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方
感想：オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方 by nao · 公開済み 2020年1月16日 · 更新済み 2020年12月25日 Rubyで初めてのオブジェクト指向なら本書！ あなたのメイン言語がRubyで、オブジェクト指向を学んだ事がないなら、本書はオススメです。 本書は、「簡潔で見通しが良く、変更が容易な設計」と「アンチパターンと呼ばれる設計」との違いを教えてくれます。やや回りくどい文章で翻訳されていますが（恐らく原文も回りくどい）、本書の価値を落とすレベルではありません。 構成は、自転車に関するクラスに対して機能拡張を繰り返し、実装を適宜リファクタリングして、より良いオブジェクト指向が何かを教える流れです。機能拡張時に、私達がやりがちな安易な実装（アンチパターン）を多く示します。「アンチパターンの何が悪いか」や「未来の設計
オブジェクト指向エクササイズのススメ
3. ThoughtWorksアンソロジー ThoughtWorks社コンサルタント ● の 骨太なエッセイ集 様々な ジャンルを収録 ● DSL、プログラミング、設計、 マネジメント、ビルド、デプロイ、テス ト．．． オライリーさんブースで ● 絶賛販売中！ 3
地下アイドルとアイドルオタクを疎結合にしてみたら、夢も希望もなくなった〜デザインパターンのObserverを考える〜 - Qiita
ある日の地下アイドル 地ア「は〜あ。今日もライブは３人しかこなかったなぁ」 地ア「きょう来てくれたのは、たっくんと、しのぶんと、ゆっきーか」 地ア「この３人、いつも来てくれるんだよねぇ。大事にしなくちゃ」 地ア「私、ぜったいに売れっ子アイドルになるんだから！」 地ア「…そろそろCD発売だから、告知しよっと」 アイドルクラス /** アイドルクラス */ function ChikaIdle() { } ChikaIdle.prototype.noticeCdRelease = function() { /** わたし、みんなの名前も顔も覚えてるよ！ */ var takkun = new Otaku('takkun'); var shinobun = new Otaku('shinobun'); var yukki = new Otaku('yukki'); /** CD買って（はあと）
現代のオブジェクト指向の class の割れ窓化と宣言的プログラミング
オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだの Hatena の件。基本的には同意。ただちょっと切り口が違うので自分の意見を言っておく。ただ、このテーマで何度か書こうとして失敗していて、今回も成功しているとはいえない。 宣言的プログラミングの時代 現代の主流は「宣言的プログラミング」であると思っている。これはリソースの宣言と、その状態遷移の手続きや振る舞いの付与が中心にある。 宣言型プログラミング - Wikipedia その代表的な例がフロントエンドの React と、バックエンドの k8s で、どちらも時系列に基づいた状態の宣言と、フレームワーク側による状態遷移処理、 Reconcillation(調停) が基礎にある。 フロントエンドとバックエンドという両極端な世界で、この変化が起きたのがこの時代を反映したものであると思う。 例えば、jQuer
Rust風にデザインパターン23種 | κeenのHappy Hacκing Blog
κeenです。 GoFのデザインパターンは有名ですが、言語機能によっては単純化できたりあるいは不要だったりするのでRust風に書き換えたらどうなるか試してみます。 発端はこのツイート。 デザインパターン、古いJavaの機能の足りなさのワークアラウンド的なテクニックも含まれてるからあまり宜しくないんだよね。enumやクロージャで十分なのもいくつかある。 Rustで写経、デザインパターン23種 - Qiitahttps://t.co/MhpS3Z2OlF — κeen (@blackenedgold) 2017年5月5日 一応誤解のないように説明しておくと、該当のQiitaの記事に不満がある訳ではなくてGoFのデザインパターンついての言及です。 リンク先のコードで十分な時にはここでは流すのでリンク先も同時に参照下さい。 また、比較しやすいようにサンプルコードはリンク先のものに則って書きます。
オブジェクト指向設計（2016年度）
コンテンツ 第1章 基本的な用語 第2章 オブジェクト指向開発 第3章 設計の問題 第4章 オブジェクト指向設計の原則 第5章 単一責任の原則 第6章 Visitor パターン 第7章 LSP、DIP、ISP 第8章 パターン技術 第9章 ユースケース 第1章 基本的な用語 クラスとオブジェクトの違い 第2章 オブジェクト指向開発 オブジェクト指向開発 オブジェクト指向分析 機能外要求 User インタフェース Student クラスとTeacher クラス Student クラスのソースコード Teacher クラスのソースコード 演習2-1 UserLocator クラスのソースコード 演習2-2 演習2-2 の解答 Teacher.java UserLocator.class 第3章 設計の問題 演習3-1 演習3-1 の解答1（返却値を利用した方法） 演習3-1 の解答2（条件分岐
Visitor パターン再考 - Qiita
オブジェクト指向 Advent Calendar というものを見つけたので、Visitor パターンについて書いてみます。 嘘です Visitor パターンについて書きたいけれど、Java Advent Calendar は埋まってしまってるので、それっぽい Advent Calendar に参加しただけです。別に Advent Calendar に参加しないといけない決まりなんてないんですけど。 デザインパターン Visitor パターンとは、デザインパターンの一つです。 そもそもデザインパターンとは何かというと、1995 年に Gamma らが "Gang of Four"、俗にいう GoF で提唱した、オブジェクト指向プログラミングによって特定領域の問題を解決しようとする際に頻出するイディオムのようなものです。 GoF で提唱されたデザインパターンは多くありますが、1995 年に発表
継承は禁止するべき
キチガイに刃物、ゴミプログラマに継承。危険なものは取り上げるべきだ。 オブジェクト指向プログラミングにおける継承は強力な手法であるが、これを正しく使えるプログラマは残念なことに極めて少ない。たいていの場合、継承を使うことで却ってプログラムの保守を困難にしてしまう。継承のアンチパターンの最たるものは、単なるメソッドやメンバ変数の共有のために継承を使うパターンだ。これを行うとデータが密結合になってバグの原因になり、プログラムを把握することも極めて困難になる。 そもそも、熟達したプログラマの感覚では、業務で書くアプリケーションの実装に継承を使うべき局面などほとんど無い。ライブラリ等のより低レベルな処理で仕様が確定しているものについては、継承が効果的となる場合もあるが、複雑なアプリケーションのロジックに継承を使うのはほとんどの場合、時期尚早な抽象化となる。 また、凡庸なプログラマが継承で実現したい
リスコフの置換原則 - Wikipedia
この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 出典がまったく示されていないか不十分です。内容に関する文献や情報源が必要です。（2021年12月） 脚注による出典や参考文献の参照が不十分です。脚注を追加してください。（2021年12月） ほとんどまたは完全に一つの出典に頼っています。（2021年12月） 独自研究が含まれているおそれがあります。（2021年12月） 出典検索?: "リスコフの置換原則" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL リスコフの置換原則の概念は、バーバラ・リスコフにより初めて導入された。2010年に撮影された写真。 リスコフの置換原則（りすこふのちかんげんそく、英: Liskov substitution principle）は、オブジェ
オブジェクト指向と20年戦ってわかったこと - Qiita
この記事の内容 オブジェクト指向と10年戦ってわかったこと Twitterやはてブコメントを見たら、「わかりやすかった」というコメントもあったのですが、どちらかというとネガティブ方面なコメントが多く目につきました。マサカリという用語で忌憚なく意見を言う風潮については別にいいんですが、「わかりにくい」「間違っている」「古い」みたいなコメントは何も生み出さないし、みんなでニコニコポエムを投稿しあうやさしいインターネッツになったらいいなって思ったので、僕もオブジェクト指向について投稿しようと思います。 何原則？ ３原則じゃなくて4では？みたいなコメントもあったのですが、別に3でも4でも5でも重要ではないかなって思います。この4原則の出どころがどこかは知らないですが、C++かSmalltalkあたり(このあたりの話を見かけたのはJava登場前だった気がする)をターゲットとしている気がします。Jav
Rubyでcase文を卒業してダックタイピングに入門する - Qiita
この記事はRuby Advent Calendar 2016の19日目の記事です。 今回は、リファクタリング系のわりと初歩的な内容かなと思います。 常にこうした方がいいというわけではなく「こういう道もあるんだよ」という選択肢を持っていると、いつか役に立つかも。ぐらいのトピックです。 発想がHash 例えば以下のようなコードがあったとします。 def 料理する(foods) foods.each do |food| case food["type"] when "フルーツ" 皮をむく(food["name"]) 切る(food["name"]) when "野菜" 切る(food["name"]) 煮る(food["name"]) end end end foods = [ { type: "フルーツ", name: "みかん" }, { type: "野菜", name: "キャベツ" }
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デザインパターンを置き換えよう！ Javaラムダ式によるシンプルコーディング一覧
杉本啓 on Twitter: "getterは、自身が返す値がインスタンス変数として保持されたいたのか算出値なのかという知識を隠蔽するのが責務。その責務をちゃんと果たしている。 その他の知識を隠さないからといってgetterはカプセル化違反だというのは、スジが通らない。責務を分離して考えましょう。"
杉本啓 on Twitter: "コードを書く時に僕が考えているのは、 ①達成したいことそのまま書くのではなく、相互に独立した要素に分解して書こう（関心の分離） ②意図が伝わる書き方にしよう ③ユニットテストし易くしよう ⓸その上で、要素の数をできるだけ減らそう ということぐらい。"
杉本啓 on Twitter: "継承に関しては90年代から危うさが指摘され「継承よりコンポジション」と言われてきた。 現代ではそれを踏まえて、継承する場合は、それを意図した抽象基底クラスを作り、継承不可のメソッドはfinalとするという風になってきていると思うの… https://t.co/oSWzvg2F7a"
GitHub - kamranahmedse/design-patterns-for-humans: An ultra-simplified explanation to design patterns
AにBを持たせる class A { private B b; // 実装} AをラップしてBと共通のイン..