オブジェクト指向の複雑性を軽減する、データ指向プログラミング入門
思った以上に反響をいただき嬉しく思っています。SNSやコメントで言及していただいている構造化プログラミングとの比較や現代的なOOP開発への適応記事を執筆予定です。記事が完成しましたら自分のSNSで共有いたしますので、もし良ければフォローしてお待ちいただけますと幸いです。（記事を書くのは思考が整理されて良いものですね。） TL;DR データ指向プログラミング(DOP) とは、データとコードを分割してアプリケーションを設計・実装するプログラミングパラダイムのこと。 DOPの実装は、以下の原則に従う。 コードとデータを分離する 汎用的なデータ構造でデータを表現する データをイミュータブルなものとして扱う データスキーマとデータ表現を分離する 個人的にDOPは、バックエンドを宣言的プログラミングっぽく書くための現実的な解だと捉えています。実装の詳細は翔泳社より出版されている「データ指向プログラミン
オブジェクト指向はコードを複雑に読みにくくする - きしだのHatena
「オブジェクト指向するとプログラムが読めなくなるから禁止」のような話は昔からあって、新しい技術についてこれない人を揶揄するようなニュアンスで使われていましたが、実際にはこれはオブジェクト指向迷路にうんざりした現場での率直な意見だと思います。 オブジェクト指向は、まじめにやるほどプログラムを読みにくくするという性質をもっています。 ※ 使い方次第というコメントついてますが、だからこそちゃんと性質をしっておく必要があると思います。 オブジェクト指向の代表的な指針を３つあげると次のようなものがあります。 オブジェクト同士の連携としてプログラムを組む 単一責務の原則 インタフェースと実装の分離 まず、オブジェクト同士の連携でプログラムを組むと、コードが飛びまくって追いにくくなります。そして単一責務の原則により、小さいクラスが大量に生成されて、追いにくさがさらにあがっていきます。 ダイクストラ先生が
オブジェクト指向プログラミング -- 1兆ドル規模の大失敗
CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、「抽象化」と「デザインパターン」について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今
オブジェクト指向の呪いと、その避け方 - mizchi's blog
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
単一責任の原則(SRP)についての見解と方法論 - FLINTERS Engineer's Blog
こんにちは@kimutyamです。 今週末はいよいよScalaMatsuri2017ですね。 弊社は、今年も将軍スポンサーとして参加させていただきます。 そして今年も同人誌を配布させていただきます。 同人誌については去年配布した話を杉谷がブログで紹介しております。 labs.septeni.co.jp 今年の同人誌目次は以下となります。 ScalaでAndroidアプリ開発 単一責任の原則(SRP)についての見解と方法論 末尾再帰の呼び出し最適化の有無によるScalaコンパイラの挙動について Akka HTTP で LINE bot を作ってみました 新卒scalaエンジニアが書くISUCONの歩き方 去年に比べて記事数は少なめですが、内容は濃くなっております。 ちなみに私は弊社の今泉と一緒に『単一責任の原則(SRP)についての見解と方法論』を執筆しました。 (Scala関係ないw) 代わ
404 Blog Not Found:オブジェクトは難しくない。難しいのはクラス
2006年11月16日16:55 カテゴリLightweight Languages オブジェクトは難しくない。難しいのはクラス 大人だからオブジェクトは難しくなる。子供にとっては実はオブジェクトは自然で自明で簡単だ。 オブジェクト指向を正しく理解する：ITpro オブジェクト指向はしばしば，とっつきづらく難しい技術と言われます。その理由の一つには，対象とする分野が広く，それぞれに深みがあることが挙げられます。しかし，それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と，「もの中心」を意味するコンセプト自体の問題です。事実、オブジェクト指向というのは最初は子供向けだったのだ。 このことを、現在「オブジェクトとはなんぞや」という大人たちは忘れてしまっている。 それで、オブジェクトとは何か、といえば、「自分が何が出来る
Android Javaでフィールドにmプレフィクスをつけるのはやめよう - Islands in the byte stream
Android Javaでは昔からAOSPのcoding style guidelineに則ったスタイルがとられることが多いようです。そのなかで、private fieldに "m" (member) や "s" (static member) などのプレフィクスをつけよ、というものがあります。 AOSP Java Code Style for Contributors | Android Open Source Project これはいわゆるハンガリアン記法の変種で、こういうやつですね。 class Recipe { private String mTitle; private List<String> mSteps; // ... } これについての態度はプロジェクトごとに様々ですが、たとえばクックパッド社のJavaのスタイルガイドでは明確に否定しています。 styleguide/
Squeak Smalltalkで荷物運びゲームを作るガイド - レガシーコード生産ガイド
2015-12-07 Squeak Smalltalkで荷物運びゲームを作るガイド Smalltalk Squeak これはSmalltalk Advent Calendar 2015の7日目の記事です。 はじめに この記事では、Squeak Smalltalkで荷物を運ぶゲームの簡易版を製作した過程などを紹介します。 完成品のプレイ動画です。 www.youtube.com この記事対象はかなり限定されています。簡単に言えば、少し前の私が読みたかった記事です。 Smalltalk以外でのプログラミングの経験は少しあって、Smalltalkにかなりの興味を持ち、入門書を読み終わった時点です。しかし今までの環境とあまりにも違うので、何を作れるのか、どう踏み込んでいけばよくわからず躊躇していました。そういう風に戸惑っていた私と同じような人を対象とし、モチベーションを上げることを目的としています
「オブジェクト指向の価値ってよく分からないですよね」について - manie's blog
そういえばCORBAとかROSEとかUMLとかやってた気がします。 プログラミング勉強中の人にオブジェクト指向とは何なのかを何となく伝えたい話 - かまずにまるのみ。 「オブジェクト指向の価値ってよく分からないですよね。」 誕生の歴史を知ればよい。環境によっては価値がある。 コンピュータは情報数学と電子回路から誕生した。電子回路は半導体によってハードウェアからソフトウェアとなり、機械語（そしてアセンブリ言語）が必要になった。C言語はアセンブリ言語に配列と構造体を加えたものだ。手続型言語ではデータ構造とアルゴリズムを同時に設計するが別々の保守が必要だった。保守は同時にやるべきだ。データ構造とアルゴリズムを同時に同じ場所で実装し保守出来る仕組みがクラスだ。 情報数学と電子回路 情報数学は乱暴に言えばビット演算学だ。NOTとORとANDを使ってあらゆる命題論理を電子回路で置き換え可能な式に書き下
Scalaは関数型プログラミング言語ではない - みどりねこ日記
面白い記事があったので翻訳してみました。 ライセンスはCreative Commonsです。 しばらくScalaで仕事をして、疑う余地なく以下のことが断言できるようになりました。 ”Scalaは関数型言語ではありません。クロージャを持ち、静的な型を持つオブジェクト指向言語です。” なので、みんなが嘘の売り文句を延々と言うのをやめてくれないかなと思っています。 これがどういうことなのかを理解するためには、ScalaのメーリングリストにJon Harropが流した挑発的な文を見てみてください。そのスレッドで、Martin O.が ”オブジェクト指向こそが唯一の”美しい”解である” と主張しています。のちにMLで、もう少し丁寧にこのことについて述べていて、それによると、アプリケーションの基幹のデータ構造を何度も変更しなくてはならないようなとき、オブジェクト指向が最適な解であると述べてみます。最終
オブジェクト指向の本懐・あとがき・オブジェクト指向における再利用 - Strategic Choice
「オブジェクト指向の本懐」を書いていて、気付いたことが2つありました。1つめは「再利用」の意味です。オブジェクト指向的再利用いわゆるGoF本と言われている書籍の正式名称は「オブジェクト指向における再利用のためのデザインパターン」です。私はこの「再利用」の意味をずっと勘違いしていました。これまでは、この再利用を「この書籍でデザインのパターンを紹介するので、そのパターンを是非再利用してください」という意味だと思っていました。しかし、この書籍の題意は「オブジェクト指向で流動的要素をカプセル化し、その他の部分を再利用するためのデザインのパターン」ということだったのです。 デザインパターンの流動的要素確かに、流動的要素のカプセル化は、多くのデザインパターンのテーマになっているようです。ただ、その観点で意識をしてデザインパターンを見たことがなかったので、本当にそうなのか、考察してみる事にしました。Ab
ソフトウェア工学・ソフトウェア工学特論
平成23年度 ソフトウェア工学 ソフトウェア工学特論 2012年後期（2単位）月曜日1限、電算機演習室 2012年後期（2単位）火曜日2限、73号教室 最終更新日：2013.1.27 - 渕田孝康 本講義の目的 ソフトウェア工学の究極の目的はソフトウェア作成の自動化にある。「こういうソフトがほしい」と伝えれば、分析・設計・実装をすべて自動で行ってソフトウェアが出てくるような仕組みがあれば、ソフトウェア開発者は不要である。しかし、実際にはそこまで行くとは思われないし、行ったとしてもはるか未来の話だろう。もちろん、本講義もそのような高みを目指してはいない（思ってもない）。 ソフトウェア開発方法論は歴史的にいくつかの段階を踏んで発達してきたが、現在では大きく2つの種類に大別できる。構造化技法とオブジェクト指向技法である。この講義では、それぞれの技法がどのような考えに基づいてソフトウェアの開発プロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
一時期プログラミングのデザインパターンというものが大流行しましたが、現在ではどのように評価されているのでしょうか？
オブジェクト指向とは何ですか？
Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。 – ゆびてく