ポリモーフィズムが1種類しかないと思ってたエンジニアの備忘録
この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の72週目の記事です！ 2年間連続達成まで残り34週となりました！ はじめに ソフトウェアエンジニアの福土（@ryoya_cre8or）です。 ふと社内のSlackで「ポリモーフィズムを使っているときに、冗長になるコードをジェネリクスを使うことで綺麗にまとめる事ができる」と呟いたところ、「ジェネリクスもポリモーフィズムの1種だよ」とツッコミをいただき、それを機にポリモーフィズムの概念について整理したいと思っていたので、年末年始にオリャっとまとめちゃいます。 実は共変性・反変性の概念を理解する上でもポリモーフィズムの概念を整理することはすごく良かったので、そこまで記事を書き切りたかったのですが息が足りず... 続きは次回とし本記事ではポリモーフィズムが何なのかについてまとめています。 ポリモーフィズム
正式仕様リリース！ JavaScriptの最新仕様ES2022で追加された「全」新機能
JavaScriptの仕様はECMAScriptで、ECMAScript 2015（ES2015）、ECMAScript 2016（ES2016）...というように毎年進化を続けています。 これまでの仕様はES2021でした。 本日6月22日、ES2022は正式仕様として承認され、ES2022が最新仕様となりました。 22.06.2022 Ecma International approves new standards - Ecma International ブラウザ対応も完了しており、全モダンブラウザ（Google Chrome・Firefox・Safari・Microsoft Edge）でES2022の全機能が使えます。 本記事では、ES2022すべての新機能を紹介します。「何が使えるようになったのか？」「どうしてそれが必要だったのか？」が、できるだけわかりやすいように解説しました
異なるモデリングパラダイムから見るモデリングの勘所 #ooc_2020
トランザクションスクリプトはどこから来たのか トランザクションスクリプトは何者か トランザクションスクリプトはどこへ行くのか #sekkeinight
オブジェクトライフサイクルとメモリ管理を学ぼう / OOC 2020
Object-Oriented Conference 2020 https://ooc.dev/ #ooc_2020 #ooc_b Session Abstract https://fortee.jp/object-oriented-conference-2020/proposal/a07d…
オブジェクト指向で考える アプリケーションアーキテクチャ設計 / Object-Oriented Conference 2020
[Object Oriented Conference](https://ooc.dev/)での登壇資料です。 [オブジェクト指向で考えるアプリケーションアーキテクチャ設計 by 弓山彬 | トーク | Object-Oriented Conference #ooc_2020 - fortee.j…
オブジェクト指向の呪いと、その避け方 - mizchi's blog
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを
Small Functions considered Harmful
In this post, I aim to: — Shed light on some of the presumed benefits of small functions — Explain why I personally think some of the benefits don’t really pan out as well as advertised — Explain why small functions can actually prove counterproductive sometimes — Explain the times when I do think smaller functions truly shine General programming advice doled out invariably seems to extoll the ele
オブジェクト指向設計（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（条件分岐
契約による設計と名前による型づけ, およびオブジェクトの不変性 - 貳佰伍拾陸夜日記
契約による設計と名前による型づけ 最近, 社内で契約による設計の話が雑談として何度か出ていて, id:hakobe932さんが社内勉強会で紹介していたり, id:shiba_yu36さんがWEB+DB PRESSでSmart::Argsで制約をチェックする記事を書いていたり, 活発な議論になっている. インスタンスのファクトリメソッドとオプショナルな型を組み合わせると事前・事後条件を満たすことが保証できて, id:hakobe932さんの資料で言うところの「要求型」と「保護型」の区別も明確になってよいという話を書こうかとおもっていた. (これはそのうち別で書く.) とはいえ, こんな話はもう言っている人がいるだろうと思ってちょっと調べていて, どういう語句で調べたらいいか考えていた. インスタンスの型からそれを生成したファクトリメソッドが特定できて, それによって事前・事後条件が保証される
最近のプログラミング言語にgetter/setterがないのはなぜ？
Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。 Androidは、Google社が開発したスマートフォンやタブレットなど携帯端末向けのプラットフォームです。 カーネル・ミドルウェア・ユーザーインターフェイス・ウェブブラウザ・電話帳などのアプリケーションやソフトウェアをひとつにまとめて構成。 カーネル・ライブラリ・ランタイムはほとんどがC言語/C++、アプリケーションなどはJavaSEのサブセットとAndroid環境で書かれています。
ES6 In Depth: Subclassing – Mozilla Hacks - the Web developer blog
ES6 In Depth is a series on new features being added to the JavaScript programming language in the 6th Edition of the ECMAScript standard, ES6 for short. Two weeks ago, we described the new classes system added in ES6 for handling trivial cases of object constructor creation. We showed how you can use it to write code that looks like this: <pre> class Circle { constructor(radius) { this.radius = r
モノモーフィズム（単相性）について – JavaScriptのパフォーマンスを例に | POSTD
JavaScriptのパフォーマンスに関する講演やブログ記事では、よく単相的コードの重要性が強調されています。しかしながら、モノモーフィズム（単相性）／ポリモーフィズム（多相性）とは何なのか、それがどうパフォーマンスに影響してくるのかということについては、あまり分かりやすく説明されていません。私自身の講演でも、＜＜ 1.良い型、2.悪い型 ＞＞的な二者択一のスタイルに要約してしまうことが少なくありません。パフォーマンスに関するアドバイスを求められることがありますが、そういう時に最もよくリクエストされるのは、 モノモーフィズムとは実際のところ何なのか 、ポリモーフィズムがなぜ生じ、それがなぜ悪いのか、ということを説明して欲しいというものです。 困ったことに、そもそも「ポリモーフィズム」という用語そのものが相当に多重定義されています。昔ながらのオブジェクト指向プログラミングにおいては、 ポリモ
問．Cでオブジェクト指向プログラミングを行なえ - 株式会社CFlatの明後日スタイルのブログ
問．Cでオブジェクト指向プログラミングを行なえ。ただし「オブジェクト指向プログラミング」とは、次のような特徴を持つプログラミング技法であるものとする： オブジェクトの実装はオブジェクトのユーザーからは隠蔽される（カプセル化／隠蔽） 同一型のオブジェクトと同一メソッドを与えた時、実際のメソッドの動作はオブジェクトの内容により変化する（ポリモーフィズム／多態性） なお、ユーザーが既存のオブジェクトをカスタマイズして新たなオブジェクトを作成する機能は、必要ないものとする。 この問いの狙い よく、「オブジェクト指向プログラミング」と「オブジェクト指向言語」は混同されます。が、前者はプログラムを設計する上での考え方で、後者はその考え方を容易にソースコードに書けるような仕様になっている言語の事で、全く違うものを指しています。 その証拠を示すため、「非オブジェクト指向言語」たるC言語で「オブジェクト指向
再考: GoF デザインパターン - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代
オブジェクト指向の法則集 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、故石井勝さんが1999年に書いた記事を Qiita に転載するものです。オブラブ(objectclub.jp)にて記事をホスティングしていましたが、現代でも十分に読める内容なので、たくさんの方に読んでもらいたいと思い、若干の編集（リンクとコンテキスト追加）を平鍋が行い、転載します。今でも、読みやすく、カジュアルな語り口のよい記事です。 オブジェクト指向の法則集（転載元：http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/oo-p
クラスの「継承」より「合成」がよい理由とは？ゲーム開発におけるコードのフレキシビリティと可読性の向上 | POSTD
コード構造における重要な問題として、複数のクラスを共有する場合に合成と継承のどちらを用いるかという点があります。“has a”の関係と、“is a”の関係と言われる2つの対比です。例えば、“ソファには綿が入っている”と、“ソファは家具である”という違いのようなものです。この例では2つの違いは非常に明白ですが、実際には、“has a”の関係でも“is a”の関係でも意味を成すケースがたくさんあります。ゲームのキャラクターについて、これはコリジョンボックスを持っているかと聞くのと、これは衝突可能なオブジェクトかと聞くような場合です。この2つは全く同じことではありませんが、それぞれが（または両方一緒に）衝突を処理する主構造として用いられ、どちらの方がよいかは必ずしも明白ではありません。私の経験では、直感的には継承の方がよいと思うことも多いのですが、それだと問題がたくさんあって結局は合成の方がよか
クラスの命名のアンチパターン - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParame
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
脱オブジェクト指向講座(5分LT資料)
オブジェクト指向とは何ですか？
