Life is beautiful: 日本語とオブジェクト指向
先日、日経BPの出版局の方と話をする機会があったのだが、私がマイクロソフトでウィンドウズ９５の開発に関わったことに触れた際、「ユーザーインターフェイスの設計において、日本人であることで何か役に立ったことはありますか？」と聞かれた。日本人であることがプラスになったとは思わないが、ふと思い出したことがある。当時、「日本語はオブジェクト指向な言語だな」と思ったことである。 その当時（９０年代初頭）、アップルの方が使い勝手に関しては一歩も二歩もマイクロソフトより進んでおり、そのためには、もともとゼロックスが提案しアップルが商品化した、「オブジェクト指向ユーザーインターフェイス」の考え方を、より推し進めるしかないという戦略で、ウィンドウズ９５のユーザーインターフェイス（当時は Object-Oriented Shell と呼ばれていた）の開発をしていた。 「オブジェクト指向ユーザーインターフェイス」
オブジェクト指向の呪いと、その避け方 - mizchi's blog
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
続・SOLIDの原則ってどんなふうに使うの？ 〜オープン・クローズドの原則 センパイのコーディングノート編〜 - Speaker Deck
2018年7月14日 PHPカンファレンス関西2018
現場で役立つシステム設計の原則 | 技術評論社
概要 「ソースがごちゃごちゃしていて，どこに何が書いてあるのか理解するまでがたいへん」「1つの修正のために，あっちもこっちも書きなおす必要がある」「ちょっとした変更のはずが，本来はありえない場所にまで影響して，大幅なやり直しになってしまった」といったトラブルが起こるのは，ソフトウェアの設計に問題があるから。日本最大級となる60万件以上の求人情報サイト「イーキャリアJobSearch」の主任設計者であり，システム設計のベテランである著者が，コードの具体例を示しながら，良い設計のやり方と考え方を解説します。 目次 第1章 小さくまとめてわかりやすくする なぜソフトウェアの変更は大変なのか ソフトウェアの変更に立ち向かう 変更が大変なプログラムの特徴 変更するたびに変更が大変になる プログラムの変更が楽になる書き方 わかりやすい名前を使う 長いメソッドは「段落」に分けて読みやすくする 目的ごとに
正しくオブジェクト指向できているどうかという意味のない議論
僕はプログラマをしていて、数千万行以上の規模で10億ユーザ以上が使うようなプログラムの開発にもかかわっていたりしたけど、そういう仕事環境で「（ある何かが）オブジェクト指向かどうか」という議論をほとんどしたことがない。デザインのレビューでもAPIが十分シンプルかどうか議論にはなるけど、そのやり方がオブジェクト指向かどうかなどという観点でものを見る人はいなかった。日頃のコードレビューでも、やるべきことが普通にわかりやすく行われているかという観点でコードを見るのが普通で、オブジェクト指向ではどう、ということをいう人はいなかった。 一方でプログラミングの入門書などをみると「オブジェクト指向とはなにか」という説明に多くの分量が割かれていて、オブジェクト指向というものが、なにかまるである時点で悟りを開くように理解すべきものであるかのような解説がなされていることがよくある。しかもその解説が哺乳類と犬と猫
オブジェクト指向と20年戦ってわかったこと - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事の内容 オブジェクト指向と10年戦ってわかったこと Twitterやはてブコメントを見たら、「わかりやすかった」というコメントもあったのですが、どちらかというとネガティブ方面なコメントが多く目につきました。マサカリという用語で忌憚なく意見を言う風潮については別にいいんですが、「わかりにくい」「間違っている」「古い」みたいなコメントは何も生み出さないし、みんなでニコニコポエムを投稿しあうやさしいインターネッツになったらいいなって思ったので、僕もオブジェクト指向について投稿しようと思います。 何原則？ ３原則じゃなくて4では？みたい
Ruby のココがダメ - Qiita
タイトルは釣りです。Ruby に盲目的に惚れている迂生には Ruby の痘痕（あばた）はエクボです。 それはともかく。 メソッド名の別名がありすぎ 「あなたは map 派？ それとも collect 派？」っていう問いがまず嫌い。 いや，別名にも意義があるとは思うんだけど，記憶の負担が大きい。 自分では map しか使わなくても，他人のコード読むんだったら collect を知っていなくちゃならない。 しばらく前に reduce っていうメソッド見て，そんなのあったっけ？と思ったら inject の別名だった。 map/collect と inject/reduce の名前とその背景にある発想については，Rubyist Magazine に良い記事がある： そうかと思えば，Array#delete_if と Array#reject! みたいに，働きは基本的に同じだけど，削除が行われなかっ
より良いプログラムを書くための究極の奇策 – 「Data first, not code first」 | POSTD
(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) 開発者は嫌うでしょう。 ここでは、標準的なコツや策略について書きますが、本当に興味があるのは、別のことです。究極の奇策を見つけたいと思います。策略をひとつずつ試して、プログラミングの聖域に少しでも近づければ良いのですが。 はじめに 私が初めて書いたビデオゲームは、 Ninja Wars （忍者戦争）でした。 そう、これは、画像で埋めたHTMLのtableです。 src 属性を変えることで、動きを実現しています。JavaScriptファイルの冒頭は下記のようになっています。 var x = 314; var y = 8; var prevy= 1; var prevx= 1; var prevsw= 0; var row= 304; var endrow= 142; var sword= 296; v
else句を使わないのが良いコードなの？いや、そんなはずは・・・ · DQNEO日記
if (条件) { return 20; } else { return 30; } ↓ if (条件) return 20; return 30; こうすれば確かにネストは浅くなりますが、いつも毎回こう書く方がよいのでしょうか？ elseを書いた方がよいケースもあるのではないか 条件の部分が特殊・例外的な場合は、確かにこの方がわかりやすいと思います。 例えば、スーパーマリオで、マリオの状態が「無敵・チビ・大きい」の３種類しかないとします。 敵に触れたときの挙動を関数として書きます。 (オブジェクト指向っぽくないかもしれませんが、本記事の主眼はif-elseの書き方です。) function () { if (マリオ.is無敵モード) { 敵.死ぬ(); return ; } //以下、通常モードの場合のコードを書く } 無敵モードは特殊な状態だから、これはよいと思います。 しかし、マリオ
- Open-Closed Principle とデザインパターン
1999/09/03 更新 石井 勝 さて，このセクションではデザインパターンを統一的に理解するために，「 Open-Closed Principle (OCP) 」 という設計ルールに基づいてパターンを眺めてみることにします．まず OCP の意味と解説を行い，その後デザインパターンを OCP の観点から見てみます．実は，デザインパターンのうちの多くは OCP を満たすために用意されたものと考えることができるのです．このセクションでは， OCP を理解し，数あるデザインパターンの中からどういう場合にどのパターンを使うのが一番効果的なのかを考えます． GoF のデザインパターンは，全部で 23 個ものパターンがあります．このデザインパターンは，多くの局面で繰り返し現れる設計を抽出したものですから，オブジェクト指向のエッセンスを集めたものだと言えるでしょう．オブジェクト指向には，カプセル化，継
JavaScriptはいかにしてprototypeを捨てクラスベース継承を得るのか - なんたらノート第三期ベータ
きっかけは、prototype と constructor と __proto__ の関係を再確認していたときでした。JavaScriptはこうだけど、これって、AltJSな言語の継承はどうなってるんだろうと思って試したくなりました。 ちょっと気持ち的に、なんだか宗教に入ったみたいに俺は JavaScript がわかったって声高に言う人、だいたいみんな、プロトタイプチェーンによる移譲がクラスベースの継承に束縛されていた思考のブレイクスルーなんだぜ、みたいに言うんだけど、いったいそれがどれほど素晴らしいものなんだろうと考えてしまい... もしプロトタイプチェーンがそんなに素晴らしいんなら、npm にあるほとんどのライブラリがチェーンを活かして作られてない理由が説明できない。もしかしたら、仕組みがいくら面白くても、実際のメンタルモデルにフィットせず、実は使い物にならないんじゃないか ----
新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを
詳細 ECMA-262-3 第7章1節 OOP: 概説 - mixi engineer blog
おはようございます。「 Dmitry 先生、言いたい放題」のコーナーへようこそ。大形尚弘です。 今回は最長、そして ECMAScript をどっかに忘れた Dmitry 先生が、オブジェクト指向というものを一般より一段抽象化したレベルから語ります。 誰あろう私がそうなのですが、オブジェクト指向や、その他の何であれプログラミングパラダイムを学ぶとき、大抵そのパラダイムを代表する実装や言語をベースに学習します。すると、パラダイム自体への理解が、その実装の制約に縛られることが多々あると思います。 私は主に ActionScript2/3 でオブジェクト指向を学習しましたので、 JavaScript は「オブジェクト指向言語では無い」と思ってしまっていたことがあります。これはこの章をお読みいただければ分かるとおり、全くの間違いです。正確に表現するならば、オブジェクト指向のための「理論的糖衣」が A
RequireJSをプロジェクトで使ってみての所感 - ダーシマ・ヱンヂニヤリング
JavaScriptのモジュール定義・読み込みをAMD (Asynchronous Module Definition) でできるライブラリであるRequireJSをプロジェクトで使ってみた。 プロジェクトの規模感を簡単に説明しておくと、まず単画面アプリケーションではなく、従来通りテンプレートが複数あるウェブサイトだ。よくあるウェブサイトとはいえ、JavaScriptで動く機能やUIがたくさんあり、テンプレートのパターンが100枚以上ある。カルーセルと画像切り替えが動けばヨシ、みたいなそこらのコーポレートサイトよりは遥かに規模の大きいウェブサイトとなっている。 導入を決めたのは、今回のプロジェクトで必ず現出するであろう懸念点を、あらかじめ潰しておきたかったという動機から。その懸念点というのは主にファイルサイズの問題。ウェブサイト内で使われている全JSファイルを全て結合圧縮すると、最終的に1
オブジェクト指向できていますか？
Visual Studio Users Community Japan #1 で発表した資料になります。 https://vsuc.connpass.com/event/143114/
ECMAScript と OOP パラダイム、それに ES.next の議論中 OOP 周りのシンタックス - oogatta のブログ
JavaScript Advent Calendar 2011 (オレ標準コース)4日目の id:oogatta です。どうもどうも、いやどうも。 最近丁度 ES Wiki を眺めていて、面白いことになってるなあ。変態的なことになってるなあ。と楽しく見ていた OOP パラダイム周りのいくつかの手法（定義、継承、 mixin 、 trait ）について、 ES.next または Harmony で議論されているものをご一緒に調べながらご紹介したいと思います。 ECMAScript3 さて、復習としてまずは ES3 での OOP パラダイムの実装についてですが、これはもう Dmitry 先生の ECMA-262-3 in detail. Chapter 7.1. OOP: The general theory. を読んでくださいというか、気持ちよく丸投げしたいところですが、翻訳すると言ってまだ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オブジェクト指向とは何ですか？