Life is beautiful: 日本語とオブジェクト指向
先日、日経BPの出版局の方と話をする機会があったのだが、私がマイクロソフトでウィンドウズ９５の開発に関わったことに触れた際、「ユーザーインターフェイスの設計において、日本人であることで何か役に立ったことはありますか？」と聞かれた。日本人であることがプラスになったとは思わないが、ふと思い出したことがある。当時、「日本語はオブジェクト指向な言語だな」と思ったことである。 その当時（９０年代初頭）、アップルの方が使い勝手に関しては一歩も二歩もマイクロソフトより進んでおり、そのためには、もともとゼロックスが提案しアップルが商品化した、「オブジェクト指向ユーザーインターフェイス」の考え方を、より推し進めるしかないという戦略で、ウィンドウズ９５のユーザーインターフェイス（当時は Object-Oriented Shell と呼ばれていた）の開発をしていた。 「オブジェクト指向ユーザーインターフェイス」
契約による設計事始め
Object-Oriented Conferenceの発表資料です。 https://fortee.jp/object-oriented-conference-2020/proposal/1224f293-8624-4448-866f-5d1b991d377f カンファレンスの感想はこちら。 …
Object-Oriented Conference参加メモ - Qiita
Object-Oriented Conference概要 ※イベント及びセッションの概要は公式HPから引用しました。 2020.02.16 SUN 10:00 - 17:00 お茶の水女子大学 #ooc_2020 Object-Oriented Conference はオブジェクト指向をテーマに、あれこれ共有したり、セッションを聴講することで、みなさんの知見を深めるためのイベントです。 オブジェクト指向といっても、分析設計から、現場で活かすためのプラクティスなど様々なテーマがあります。セッションやラウンドテーブルなどを通じて、参加者の皆様が新たな発見を持ち帰っていただけるようなイベントを目指しています。 オブジェクト指向についてまったく知らない方やオブジェクト指向を完全に理解した方、そして普段オブジェクト指向以外のパラダイムを利用している方もお気軽にご参加ください！ 開会の挨拶 オブジェク
役割駆動設計で巨大クラスを爆殺する - Qiita
大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、ドメイン駆動設計を基本思想とする「役割駆動設計」を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 小さくシンプルな構造に落とし込み、堅牢で変更容易性の高い設計へ昇華させる。 例１：筆者をモデリング 分かりやすくなるよう、まず私を例にモデリングしてみます。私は以下のような特徴があります。 IT企業の従業員 家族がいる(妻, 子供) 趣味でゲーム制作している ダメな設計 何も考えずに人クラスとして設計すると、よく以下のような構造になりがちです。 従業員として仕事をする、父親として家族サービスする、趣味としてゲーム制作する、それぞれのメソッドが備わってい
ドメインモデリングの始め方 - Speaker Deck
ドメイン駆動設計の考え方は書籍を読むとわかりますが、いざモデリングを実践しようとすると、どこから手を付けていいかわからない、ドメインモデリングの始め方がよくわからないという意見を聞きます。 このスライド資料では、そんな悩みを持つ皆さんに向けて「ドメインモデルを見つけ出し・実装に落とし・改善していく」方法を、できるだけわかりやすく解説します。
Getter/Setterを避けて役に立つドメインオブジェクトを作る - かとじゅんの技術日誌
Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んでます。モデリングに関しては成分薄めですが、よい本だと思います。はい。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 作者: Robert C.Martin,角征典,高木正弘出版社/メーカー: KADOKAWA発売日: 2018/07/27メディア: 単行本この商品を含むブログを見る 本書の大筋から少し逸れるが、「5章 オブジェクト指向プログラミング」の「カプセル化」が面白かったので、これを切り口にモデリングについて考えてみる。 OO言語のカプセル化はすでに弱体化している オブジェクト指向の三大要素の一つである、カプセル化について、以下のようなことが書いてあります。 「カプセル化」がOOの定義の一部となっているのは、OO言語がデータと関数のカプセル化を簡単かつ効果的なものにしているから
オブジェクト指向の呪いと、その避け方 - mizchi's blog
このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
Tell, Don't Ask [ 求めるな、命じよ ] - はむはむエンジニアぶろぐ
Tell, Don't Ask は、オブジェクト指向プログラミングのよいとされる考え方の一つです。 Tell, Don't Ask は、日本訳で 求めるな、命じよ と訳されているのが、多いみたいですね。 オブジェクト指向というのは、役割を思ったオブジェクト同士が協力(コラボレーション)しながら機能(価値)を提供する。 オブジェクトが持つ役割が、あいまいだと良い設計と言われている 凝集度が高く結合度の低い ものは出来ません。 その為に、必要な考え方の一つなのが Tell, Don't Ask [求めるな、命じよ] である。 求めるな、命じよって言われてもピンきにくいですよね(´・ω・｀)w シーケンス図とか書いてみて、解説します。 Tell, Don't Ask Tell, Don't Ask とは、 Ask ではなく Tell しなさいというものです。 オブジェクトAが、オブジェクトBを呼
![Tell, Don't Ask [ 求めるな、命じよ ] - はむはむエンジニアぶろぐ](https://cdn-ak-scissors.b.st-hatena.com/image/square/ac7e2df06bedb9512e0b7b1b3caa43724e98d3a7/height=288;version=1;width=512/http%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fs%2Fsecret_hamuhamu%2F20150816%2F20150816222337.jpg)
境界づけられたコンテキスト 実装編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab
little-hands.hatenablog.com こちらの記事で説明できなかった、「境界づけられたコンテキストをどうやって実装に落とし込むのか？という話を書きます。 境界づけられたコンテキスト実装の基本イメージ 結論からいくと、基本的には、 1コンテキスト = 1アプリケーション と思ってもらってOKです。 これを基本として、用途や実装コストと相談しながら少しずつ設計を組み替える検討が可能です。 1アプリケーション単位で、オニオンアーキテクチャ概略の記事で紹介したアーキテクチャを1セット揃えると思ってください。 つまり、こちらの記事で紹介した2つの境界づけられたコンテキストに対して、 以下のようにアプリケーションを2セット作ります。 ドメイン層を外界と隔離して、外部に公開するする操作を周りの層で定義するのです。 最終的に、マイクロサービス2つ作ると思ってもらって良いです。そうすると、
![境界づけられたコンテキスト 実装編 - ドメイン駆動設計用語解説 [DDD] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/651dc2c9022ca618fd318e11235cd199205385a3/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20171207%2F20171207001225.png)
Web Developer Roadmap 2018が出たので2017年版と比較してみる - Qiita
のようなイメージではないでしょうか？ (灰色と橙色の分け方は作者のおすすめ度（匙加減）な気もしなくないんですが） はい…まさにこの通りですのでこれを参照頂ければなと思います。隅まで目を通していないのがバレますね。 では早速本題 🚀Introduction これが2017版 2018版 左の奴らが軒並みチョーヤバいです。雑だな！ まあここは導入みたいなもんなんで深くは追及しません。最早OSSや仮想鯖、クラウド環境化での開発は必須なんだってことが言いたいんだと思います。（適当） デザインパターンってのはGoF(Gang of Four)というおじさん４人がソフトウェア開発に取り入れたオブジェクト指向プログラミングにおけるこう書くとオブジェクト指向的にええと思う！っていうパターンの集まりです。全23種、知らず知らずのうちに使っているものも多いです。 なんで今追加されたのか僕にはよくわかりません
「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～
増田亨氏の「現場で役立つシステム設計の原則]」の評判が高いようです。 この本が、オブジェクト指向の初級者に受け入れられ易いことはわかります。オブジェクト指向的なプログラミングが出来ていない現場で、明日からでも出来そうなことが平易に書かれているからです。オブジェクト指向の入り口を指し示しているように見える。 一方で、私としては、この本が指し示す入り口は、入りやすいかもしれないけれど、結局はどこにも通じていないのではないかと疑っています。 本稿では、そのように私が考える理由について、３つの切り口からご説明したいと考えています： 何のために、「データとロジックを一体に」するのか？ポリモーフィズムは何のために？「ドメインモデル」とは何か？長くなるので、今回は、一番目の「何のために、『データとロジックを一体に』するのか？」について。 批判 (1) 何のために、「データとロジックを一体に」するのか？本
現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法
2017年7月5日紙版発売 2017年7月5日電子版発売 増田亨 著 A5判／320ページ 定価3,234円（本体2,940円＋税10%） ISBN 978-4-7741-9087-7 Gihyo Direct Amazon 楽天ブックス honto ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo 本書のサポートページサンプルファイルのダウンロードや正誤表など この本の概要 「ソースがごちゃごちゃしていて，どこに何が書いてあるのか理解するまでがたいへん」「1つの修正のために，あっちもこっちも書きなおす必要がある」「ちょっとした変更のはずが，本来はありえない場所にまで影響して，大幅なやり直しになってしまった」といったトラブルが起こるのは，ソフトウェアの設計に問題があるから。日本最大級となる60万件以上の求人情
正しくオブジェクト指向できているどうかという意味のない議論
僕はプログラマをしていて、数千万行以上の規模で10億ユーザ以上が使うようなプログラムの開発にもかかわっていたりしたけど、そういう仕事環境で「（ある何かが）オブジェクト指向かどうか」という議論をほとんどしたことがない。デザインのレビューでもAPIが十分シンプルかどうか議論にはなるけど、そのやり方がオブジェクト指向かどうかなどという観点でものを見る人はいなかった。日頃のコードレビューでも、やるべきことが普通にわかりやすく行われているかという観点でコードを見るのが普通で、オブジェクト指向ではどう、ということをいう人はいなかった。 一方でプログラミングの入門書などをみると「オブジェクト指向とはなにか」という説明に多くの分量が割かれていて、オブジェクト指向というものが、なにかまるである時点で悟りを開くように理解すべきものであるかのような解説がなされていることがよくある。しかもその解説が哺乳類と犬と猫
ドメイン駆動設計のためのオブジェクト指向入門
関西DDD.java 勉強会 2016-3-5 (DDD Alliance 勉強会 2016-1-21 @東京の京都再演版）Read less
オブジェクト指向と20年戦ってわかったこと - Qiita
この記事の内容 オブジェクト指向と10年戦ってわかったこと Twitterやはてブコメントを見たら、「わかりやすかった」というコメントもあったのですが、どちらかというとネガティブ方面なコメントが多く目につきました。マサカリという用語で忌憚なく意見を言う風潮については別にいいんですが、「わかりにくい」「間違っている」「古い」みたいなコメントは何も生み出さないし、みんなでニコニコポエムを投稿しあうやさしいインターネッツになったらいいなって思ったので、僕もオブジェクト指向について投稿しようと思います。 何原則？ ３原則じゃなくて4では？みたいなコメントもあったのですが、別に3でも4でも5でも重要ではないかなって思います。この4原則の出どころがどこかは知らないですが、C++かSmalltalkあたり(このあたりの話を見かけたのはJava登場前だった気がする)をターゲットとしている気がします。Jav
大規模Webアプリケーションにおける複雑性とアーキテクチャ設計に関する一考察 - Qiita
Webアプリケーション開発についての知見を、自分の経験と知識をベースに整理してみようという試みです。 いわゆるサーバサイドにスコープを絞り、フロントエンドは対象外です。筆者は普段、オブジェクト指向言語で書いているので、本記事でもその前提（Ruby、PHP、Python、Java、Scalaあたりを想定）になっています。 では、本編をどうぞ。 ソフトウェア開発は複雑さとの戦い 『人月の神話』では、ソフトウェアの本質的な困難性について4つの性質をあげている。その中で最初に出てくるのが「複雑性」である。『新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡』なんか読んでもらえると、ソフトウェアの複雑性と戦うために、人類が生み出してきた発明の数々が説明されている。 では、複雑さとは何か？もう少し掘り下げて考えてみよう。 複雑さの正体 Webアプリケーションが複雑になる
ドメインオブジェクトの見つけ方・作り方・育て方
Java/Spring Boot/MyBatis/Thymeleafを使った、ドメイン駆動設計のサンプルコード。ビジネスルールに焦点を合わせ、計算モデルで複雑さを整理し、型指向のプログラミングで実装する、その具体例。
DDD Alliance! ドメイン駆動設計のためのオブジェクト指向入門に参加してきた - はむはむエンジニアぶろぐ
2016年1月21日に開催されたドメイン駆動設計のためのオブジェクト指向入門に参加してきました。 その時のスライドがこちら ドメイン駆動設計のためのオブジェクト指向入門 from 増田 亨 www.slideshare.net 発表内容のメモを残しておく 私のDDDに対する解釈が、混じったメモになります。 DDDは、インクリメンタルな設計である。 ドメインに対する理解(ベース)をもとに、オブジェクト指向で表現する。 ドメインモデルとは、ドメインの知識を鋭く解説する。 ドキュメントで、長ったらしく解説するより語彙が大事。 モデルと実装は結びつけろ。 開発の生産性 変更容易性 が、もたらされる。 日常で使われる言葉をコードで体現する。 ドメインを分析する人と実装する人が別れてはいけない。 ドメインを分析する人がコードを書き、コードを書く人が、ドメインを分析する。 クラスを作るためには、分析が必
僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - 亀岡的プログラマ日記
はい、ポエムです。自分が正しかろうとは欠片も考えていません。異論や示唆は歓迎ですが、そう考えろと言っているわけではないので、そこはご容赦を。 前置き終わり。 さて、Nullは50億ドルの過ちだそうですね。 null参照の考案は10億ドル単位の過ち？ | スラド デベロッパー そして、それを回避するため、Maybe / Nullable / Optional などの言語機能が生まれ、各言語に埋め込まれています。 それは、大変喜ばしいこと、だと思います。 なんですが、どうもどうも、僕はどうしてもしっくりこないのです。これら全てに対して。Nullと同じように。 Nullは何がダメなんだっけ？ Nullがダメな理由、ってなんなんでしょう。よく言われる批判として、以下があるのかなぁと思っています。 ①Nullは型ではない Nullと言っていますが、こいつはNullポインタ、でございます。 からの「何
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オブジェクト指向とは何ですか？
