2024/3/24に開催されたObject-Oriented Conferenceでの登壇資料です。 https://ooc.dev/2024/
「オブジェクト指向の継承を使うな」という主張が広まっているようです。なんでダメになったんでしょうか。 インターネットで見かけた「継承はダメ」という主張をいくつか眺めて、友人と議論しつつ、考えてみました。 「コードが読みにくくなる」 継承があると、メソッド呼び出しが実際にどのメソッド定義を呼び出すのか字面でわからない。 デバッガを使って、親クラスのメソッドに飛んだり、子クラスに飛んだりするのを追いかけないと行けない。 つらい。という主張。 めっちゃわかる。わかるんですが、これは「高度に共通化されたコードは読みにくい」という一般的な側面がかなり大きいような。 たとえば継承の代わりに高階関数を使うと、関数呼び出しがどのクロージャに飛ぶか字面でわからなくなる。 ひどいとコールバック地獄になって何が何やらになります。 継承がことさらにまずい理由を想像すると、すべてのメソッド呼び出しがポリモーフィック
この文章みてください。 オレはもう20年以上システム業界にいるけどな、その長い経験から言うと、オブジェクト指向なんてものは、理論としては面白いけど、およそ実用的とは言い難いものだな。まぁ、例えばGUIのコンポーネントとかはオブジェクト指向に基づいて作られているようだから、そういうツールとかを作る人には必要なものなのかもしれない。しかし君たちがいずれ作ることになる業務アルゴリズムにはまったく無縁のものだと思ってもらって間違いない。どうもこの業界、オブジェクト指向でなければダメ、というような風潮がまかりとおっているけどな、オブジェクト指向なんか本当に使っている人はほとんどいないよ。オレも少し勉強してみたけど、カプセル化とかポリ何とかとか、どうにも利点が理解できなかったね。実際、実業務で使ったことなどないしな…… 「またお前、オブジェクト指向の話をしてるのか」と思ったかもしれませんが、2010年
今回の記事はオブジェクト指向プログラミングにおける設計の基本、「SOLID原則」について。 ある程度プログラミングの文法を知っていれば、動作するコードを書くことは可能です。しかし、より良いコードを書きたいのであれば、文法の知識だけではなく、設計に関する知識も必要になってきます。 特にUnityでは、適当にコードを書いていくと目も当てられないようなスパゲッティーコードが容易に出来上がります。「とりあえずシングルトンにすりゃいいや!」みたいなノリで「何とかManager」クラスを作りまくった結果、「あれ?この処理どこに書いたんだっけ?」という状況になったこと、誰しも一度はありますよね…? 今回は、そんなクソk…良くないコードを書かないための設計原則である「SOLID原則」について紹介します。記事内のコードはC#で記述しますが、言語に関わらずSOLID原則は広く応用の効く考え方なので、是非とも覚
「オブジェクト指向するとプログラムが読めなくなるから禁止」のような話は昔からあって、新しい技術についてこれない人を揶揄するようなニュアンスで使われていましたが、実際にはこれはオブジェクト指向迷路にうんざりした現場での率直な意見だと思います。 オブジェクト指向は、まじめにやるほどプログラムを読みにくくするという性質をもっています。 ※ 使い方次第というコメントついてますが、だからこそちゃんと性質をしっておく必要があると思います。 オブジェクト指向の代表的な指針を3つあげると次のようなものがあります。 オブジェクト同士の連携としてプログラムを組む 単一責務の原則 インタフェースと実装の分離 まず、オブジェクト同士の連携でプログラムを組むと、コードが飛びまくって追いにくくなります。そして単一責務の原則により、小さいクラスが大量に生成されて、追いにくさがさらにあがっていきます。 ダイクストラ先生が
きしださんが先日もたのしいお題を投下されていました。 出遅れましたがこのネタについて少し掘り下げてみます。 念のため個人的なスタンスをあらかじめ表明しておくと、オブジェクト指向に対してはそれなりに好意的ですが、別に時代の最先端だとかソフトウェア開発に必須の知識というほどではない(でも知っておくと便利というか、知らないと不便なこともあるかもしれないのでわざわざ避けるのはおすすめしない)というくらい温度感です。 オブジェクト指向 is 何 そもそも「オブジェクト指向」という言葉自体、座りの悪い言葉です。 意味が明確なのは「オブジェクト指向プログラミング(OOP)」、「オブジェクト指向プログラミング言語(OOPL)」、「オブジェクト指向設計(OOD)」「オブジェクト指向分析(OOA)」といった「オブジェクト指向なんとか」の方で、それらをふわっとまとめた(ような気がする)単語が「オブジェクト指向」
定期的にオブジェクト指向disを書いてしまってるのだけど。 とりあえずオブジェクト指向の話をすると定義が人によって違いすぎるので、改めてここでの定義を書いておくと 、基本的にはOMTの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」 に従うのですが 「1990年に流行りソフトウェア開発のすべてを飲み込み、いまとなっては人それぞれ定義が違って技術的議論に使えなくなった、主にオブジェクトを基本単位としてプログラムを整理するやりかたを指すマーケティング用語」 という感じです。 ほとんどの場合で人によってオブジェクト指向の指す範囲が違いすぎて、技術的知見の共有には使えなくなっています。でも、いずれの定義にしろオブジェクトを基本単位にするというのは重要ではないかと。 ソフトウェアの組織化の単位としてオブジェクトを使うというのが大事で、データの搬送に構造体代
どうも、都内の某企業に勤めるフルスタックエンジニアです。この記事では、ITの非専門家に向けて、オブジェクト指向の解説をしたいと思います。 小学生のプログラミング教育が開始されたり、AIやIoTなどの技術が身近になった今日、オブジェクト指向を理解しておくことは極めて重要です。なぜならば、オブジェクト指向はITエンジニアとっての「共通言語」であって、今やあらゆるソフトウェア技術がオブジェクト指向の上に成り立っているからです。したがって、オブジェクト指向を理解すれば、ITのすべての分野の基礎が身についたことになります。難しい概念がいくつか出てきますが、分かりやすく解説するので頑張ってついてきて下さい! オブジェクト指向とはまず、オブジェクト指向とは何かを解説します。オブジェクト(object)とは、「モノ」のことです。言い換えれば「モノ指向」です。つまり、コンピュータのようなバーチャルな対象では
垂木いすゞ @Isuzu_T このアカウントは誰向きでもありません。発言を読んだことに起因する不快感に関して当アカウントは責任を負いかねます。フォロー・リムーブ・リプライはご自由に。挨拶不要。反応するかは気分次第です。このアカウントはエロ、愚痴、政治、アニメ実況、不謹慎ジョーク、その他一切の言動を自重しません。サイバーイグアナ氏フォロー中 垂木いすゞ @Isuzu_T 学生の頃の話だ。 当時、僕が所属していたプログラミングサークルの後輩が、オブジェクト指向にはまっていた。僕はオブジェクト指向がなんなのかよくわからず、構造体に毛の生えたような使い方しかしていなかったのだが、後輩は継承にドハマリし、あらゆるコードで継承を使っていた。 2021-02-23 17:07:05 垂木いすゞ @Isuzu_T 「継承って使いすぎると良くないって聞くけどね」 僕はそう言ったが、聞き齧りなので理由は説明で
私がIT業界の片隅に所属をし始めた2000年ごろ、Javaエンジニアはスーパースターだった。Javaエンジニアを名乗るということは、秘奥義オブジェクト指向を習得していることに他ならないからだ。 「オブジェクト指向こそ正義」だった。 Javaとオブジェクト指向を身につければ、20年は食っていけると言われたものだった。 あれから20年。たしかにJavaとオブジェクト指向で20年は食えた。が、もはやオブジェクト指向は絶対でも正義でもない。 僕は、IT講師として新入社員にJavaを教える仕事もしているが「オブジェクト指向こそ正義」と無垢な生徒達に教えなければならない時に、苦痛を覚えるようにすらなってしまった。 2000年代から、新人教育のテキストは変わっていない。継承は積極的に使っていくべきで、オブジェクトは現実世界を模した仮想現実世界をコンピューター内に生み出す技術とされている。Strutsだけ
キチガイに刃物、ゴミプログラマに継承。危険なものは取り上げるべきだ。 オブジェクト指向プログラミングにおける継承は強力な手法であるが、これを正しく使えるプログラマは残念なことに極めて少ない。たいていの場合、継承を使うことで却ってプログラムの保守を困難にしてしまう。継承のアンチパターンの最たるものは、単なるメソッドやメンバ変数の共有のために継承を使うパターンだ。これを行うとデータが密結合になってバグの原因になり、プログラムを把握することも極めて困難になる。 そもそも、熟達したプログラマの感覚では、業務で書くアプリケーションの実装に継承を使うべき局面などほとんど無い。ライブラリ等のより低レベルな処理で仕様が確定しているものについては、継承が効果的となる場合もあるが、複雑なアプリケーションのロジックに継承を使うのはほとんどの場合、時期尚早な抽象化となる。 また、凡庸なプログラマが継承で実現したい
以下はjavinpaul( Webサイト / Twitter / Facebook / dev.to )による記事、11 Essential Skills Software Developers should Learn in 2020の日本語訳です。 なおリンク先URLは元記事のままであり、和訳にあたり変更などは行っていません。 11 Essential Skills Software Developers should Learn in 2020 注意事項:この記事にはアフィリエイトリンクが含まれています。 この記事に記載されているリンクを踏んで製品やサービスを購入すると、私が利益を受けとることがあります。 ソフトウェア開発を始めてしばらくすると、優れたプログラマになるには何をすればいいのかという考えが時によぎるでしょう。 より良い開発者になるために、2020年には何を学ぶべきでしょう
<5> (標準) Pascal へのオブジェクト指向拡張 (Pascal へのオブジェクト指向拡張の歴史と Delphi)DelphiプログラミングPascalobjectpascalTurboPascal 5. (標準) Pascal へのオブジェクト指向拡張 1993 年の (標準)Pascal へのオブジェクト指向拡張はドラフトのまま放置されました。 Object-Oriented Extensions to Pascal (1993) 余談ですが、このドラフトには 『J&W』改訂者のジム・F.マイナー氏や、Apple のカート・J.シュマッカー氏、Borland のデビッド・インターシモーヌ氏が参加しています。 5.1. ドラフトのオブジェクト指向拡張案 クラス型は型宣言部 (type) にて "型名 = class (親クラス) ~ end;" として定義します。 3.1.1.
<4> Turbo Pascal のオブジェクト指向拡張 (Pascal へのオブジェクト指向拡張の歴史と Delphi)DelphiプログラミングPascalobjectpascalTurboPascal 4. Turbo Pascal のオブジェクト指向拡張 Borland は 1989 年の Turbo Pascal バージョン 5.5 において、オブジェクト指向拡張を取り入れました。自社の Pascal に対して行った最初のオブジェクト指向拡張です。 これが Delphi に繋がる (Borland の) Object Pascal の始まりとなるのですが、Borland 自身はこの拡張を Object Pascal とは呼んでいません。オブジェクト指向拡張を強調する文脈では Pascal with Objects や、単に オブジェクト指向拡張 (Object-Oriented
最近の新人は勉強熱心だ。新しく聞いた概念を貪欲に取り入れようとする様は、はたから眺めていても感心する。私なんて10年前に得た知識でなんとかごまかしごまかし生きているというのに。 もちろん様々な場面で「躓き」は発生する。有名どころではポインタや非同期処理が初心者キラーだ。そして一番の初見殺しは……オブジェクト指向だ。 オブジェクト指向に殺されたプログラマは数知れない。新人からベテランまで、たいてい皆殺しにされている。 なぜそれほどまでに多くのプログラマを混乱させるのだろう。本やネットではオブジェクト指向の数々の多大なメリットが列挙されており、実に素晴らしいパラダイムに思える。しかし教本通りに組んでみてもどうにもしっくりこない。本当に自分はオブジェクト指向のメリットを享受できているのだろうか? 種明かしをしよう。実はそれらメリットとやらは全部全くの嘘で、オブジェクト指向にメリットなんてものは存
刺身にタンポポ乗せる仕事ってきょうび言わねーな……。 プログラミングとは、勉強も運動もスマブラも下手なクソ隠キャ中学生が「俺もパソコン1台で凄い技術者になって…!」とワクワクしながら始めるものの思ったより普通に難しいし学校の試験で出たような知識要求されるしで3日で放り投げ、10数年後にnoteで「お前らは絶望的にプログラミングに向いてないからやめろ」なんて記事を書くだけのザコに成り下がる、夢と希望に溢れた技術である。 近年ではパソコンのスペックの上昇にともないできることも増え、どこのご家庭にもあるRTX2080で簡単にディープラーニングもできるようになった。Unityで3Dゲームをバリバリ動かしてもブルースクリーンは出ない。やっぱ世界を広げるのは小賢しい知恵よりもスペックの暴力だぜ。 開発環境や言語も選択肢豊富で、エディタもかつては有料クラスでも手に入らなかったような贅沢な機能が満載のもの
The Delphi language in 10.3 has a fairly core change in the way it allows far more flexibility in the declaration of local variables, their scope and lifetime. This is a change that breaks a key tenet of the original Pascal language, but offers a significant number of advantages, reducing unneeded code in several cases. Old Style Var Blocks Since Turbo Pascal 1 and until now, following classic Pas
はじめに とある企業で組み込み系ソフトエンジニアとして働いていますが「このままだと、将来ないかも?」と思えてくる場面に日々遭遇します。 今回は日本の組み込み業界の将来が不安になる、耳を疑った”上司の発言”をまとめてみました。 「最近の若いやつらは残業が足りない」 働き方改革が騒がれるこの時代に、そんなこと言う人いるの!? と驚く方もいるかもしれないですが、いるんです。 そして、それがまかり通る現場の一番の問題は 「開発業務の効率化、スピードUPを図る文化が根付かない」ことだと私は思っています。 「時間が足りなければ残業でカバーすればOK!残業代も出るし、いいでしょ。」 という考え方では、どうすれば開発スピードが上がるか?無駄な作業はないか?自動化できることはないか?といった改善のアイデアは、なかなか出てきません。 残業を推進し次から次へと業務が積まれていくような現場では、改善のアクションの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く