タグ

関連タグで絞り込む (22)

タグの絞り込みを解除

OOに関するch1248のブックマーク (51)

  • 目的を規定せずにモデリングを考えても意味がない - きしだのHatena


    オブジェクト指向の本では﹁自転車をモデリングしてみましょう﹂﹁鳥をモデリングしてみましょう﹂ということが、どういうシステムで使うか規定せずによく書かれています。 けれども、モデリングではどういうシステムで使うかということが大事で、それを決めずにモデリングを考えても意味がありません。モデリングすべきはモノではなくシステムのプロセスです。 よく、オブジェクト指向では現実をモデリングするのようなことが言われますね。 例えば鳥が鳴くとして、その一種であるニワトリをどうモデリングするか、ということを考えるとします。 そうすると、まず void 鳴く() { print("コケコッコー"); } のようなメソッドを考えるのですけど、コケコッコーとうまく鳴けるのは鳴き慣れたニワトリです。そのため、鳴くメソッドにカウンターを用意してどんどんうまくコケコッコーになるようにしたくなります。 いや、そもそも、コ
    目的を規定せずにモデリングを考えても意味がない - きしだのHatena
    ch1248
    ch1248 2024/04/14
    その通りだし、端的に必要な話題がまとめられている。
    リンク

  • オブジェクト指向の複雑性を軽減する、データ指向プログラミング入門

    思った以上に反響をいただき嬉しく思っています。SNSやコメントで言及していただいている構造化プログラミングとの比較や現代的なOOP開発への適応記事を執筆予定です。記事が完成しましたら自分のSNSで共有いたしますので、もし良ければフォローしてお待ちいただけますと幸いです。（記事を書くのは思考が整理されて良いものですね。） TL;DR データ指向プログラミング(DOP) とは、データとコードを分割してアプリケーションを設計・実装するプログラミングパラダイムのこと。 DOPの実装は、以下の原則に従う。 コードとデータを分離する 汎用的なデータ構造でデータを表現する データをイミュータブルなものとして扱う データスキーマとデータ表現を分離する 個人的にDOPは、バックエンドを宣言的プログラミングっぽく書くための現実的な解だと捉えています。実装の詳細は翔泳社より出版されている「データ指向プログラミン

    オブジェクト指向の複雑性を軽減する、データ指向プログラミング入門
    ch1248
    ch1248 2023/10/25
    OOPでもクラス指向からメッセージ指向になったと解釈できるのかな。
    リンク

  • オブジェクト指向はコードを複雑に読みにくくする - きしだのHatena

    「オブジェクト指向するとプログラムが読めなくなるから禁止」のような話は昔からあって、新しい技術についてこれない人を揶揄するようなニュアンスで使われていましたが、実際にはこれはオブジェクト指向迷路にうんざりした現場での率直な意見だと思います。 オブジェクト指向は、まじめにやるほどプログラムを読みにくくするという性質をもっています。 ※ 使い方次第というコメントついてますが、だからこそちゃんと性質をしっておく必要があると思います。 オブジェクト指向の代表的な指針を３つあげると次のようなものがあります。 オブジェクト同士の連携としてプログラムを組む 単一責務の原則 インタフェースと実装の分離 まず、オブジェクト同士の連携でプログラムを組むと、コードが飛びまくって追いにくくなります。そして単一責務の原則により、小さいクラスが大量に生成されて、追いにくさがさらにあがっていきます。 ダイクストラ先生が

    オブジェクト指向はコードを複雑に読みにくくする - きしだのHatena
    ch1248
    ch1248 2023/02/25
    少なくともクラス指向でのOOPだと、IDE前提にしても処理が飛び過ぎで複雑化が免れないんだよね。メッセージ指向の方面からもうちょい何とかならんのかなとは思うが……。
    リンク

  • 現代のオブジェクト指向の class の割れ窓化と宣言的プログラミング


    オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだの Hatena の件。基本的には同意。ただちょっと切り口が違うので自分の意見を言っておく。ただ、このテーマで何度か書こうとして失敗していて、今回も成功しているとはいえない。 宣言的プログラミングの時代 現代の主流は﹁宣言的プログラミング﹂であると思っている。これはリソースの宣言と、その状態遷移の手続きや振る舞いの付与が中心にある。 宣言型プログラミング - Wikipedia その代表的な例がフロントエンドの React と、バックエンドの k8s で、どちらも時系列に基づいた状態の宣言と、フレームワーク側による状態遷移処理、 Reconcillation(調停) が基礎にある。 フロントエンドとバックエンドという両極端な世界で、この変化が起きたのがこの時代を反映したものであると思う。 例えば、jQuer
    現代のオブジェクト指向の class の割れ窓化と宣言的プログラミング
    ch1248
    ch1248 2021/01/22
    同意できる意見だった。
    リンク

  • オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだのHatena


    某所でオブジェクト指向についていろいろ書いたのでまとめておく。 問題意識としては初学者がなにかというと﹁オブジェクト指向できるようになりたい﹂のようなことを言うけどそこまでの優先順位でがんばるものではないんでは、というところです。 まず前提として、オブジェクト指向は1980-2000年くらいに流行って発達したものの、それ以降は時代にあわせた進歩はしていない20年以上前の技術ってのがあります。 そのころは今だとCPUのキャッシュにも満たないようなメモリをやりくりしてプログラムを書く必要があったので、オブジェクト指向はメモリ上のデータをコピーすることなくうまく使いまわせるようなプログラム技術になっています。 そしてオブジェクト指向にはそこから目だった更新はなく、タイトルに書いたように、カメラがやっとついたくらいのガラケーのような古い技術という感じがします。 オブジェクト指向について、アプリケー
    オブジェクト指向には、カメラがやっとついたころのガラケーのイメージがある - きしだのHatena
    ch1248
    ch1248 2021/01/21
    言いたいことは読み取れた。フレームワークの裏側でOOが存在している事は多いので、チームの中で一定数の人間は扱える形が理想かも。
    リンク

  • ミノ駆動 on Twitter: "ちと出遅れたけどリスコフ置換原則遵守の実装物としてWPFの図形クラスの抽象基底、Shapeがよく出来ていて、ここから楕円Ellipseや矩形Rectangleに派生している。ShapeはUI部品の基本、UIElementを継承して… https://t.co/B3cT7Xv0o8"

  • オブジェクト指向プログラミング -- 1兆ドル規模の大失敗


    CodeIQのブログより。🤔 なぜ、OOPから移行する時なのか Ilya Suzdalnitski OOPは、多くの人にコンピューターサイエンスの重要資産と考えられています。コード構成(code organization)に対する究極のソリューション。すべての問題の終焉。私たちのプログラムを書くための唯一の本当の方法。自分自身をプログラムするという真なる唯一神から私たちに授けられました… それまでは、そうではなく、抽象化の負担、そして無差別に共有されるミュータブルなオブジェクトの複雑なグラフによって、人々は屈し始めています。現実世界の問題を解決するのではなく、﹁抽象化﹂と﹁デザインパターン﹂について考えるのに貴重な時間と頭脳が費やされています。 非常に著名なソフトウェアエンジニアを含め、多くの人々がオブジェクト指向プログラミングを批判してきました。驚くことに、OOP自身の発明者でさえ、今
    オブジェクト指向プログラミング -- 1兆ドル規模の大失敗
    ch1248
    ch1248 2019/07/24
     クラス指向のOO、メッセージング指向のOOを分けた上で前者の批判。(後者は賞賛) さらにはクラス指向のOOのデータと関数の密結合を批判、と読んだ。なるほど、筋は通っている。  

    ●OO
    ●programming
    ●論
    ●*資料
      
    リンク

  • 一時期プログラミングのデザインパターンというものが大流行しましたが、現在ではどのように評価されているのでしょうか？

    回答 (5件中の1件目) この質問にかなり先行して2015年、Quora（本家）で投げかけられた質問として、 Why do some functional programmers criticize design patterns in OOP languages as a sign of language deficiency, while Monad is also a design pattern? なぜ、関数型プログラマらは、オブジェクト指向(OOP)言語のデザインパターンを、言語の欠陥の象徴だと批判するのでしょうか？モナドもデザインパターンじゃないんですか？ があります。...

    一時期プログラミングのデザインパターンというものが大流行しましたが、現在ではどのように評価されているのでしょうか？
    ch1248
    ch1248 2019/03/25
    同意。そして毛の壁批判批判ブックマーカーの出所の怪しさよ。
    リンク

  • オブジェクト指向とは何ですか？

    回答 (8件中の1件目) 英語では「object-oriented」で「OO」と略され、1960～1980年代のプログラミング手法（OOP）から始まり、その応用としてソフトウエアの設計・分析の手法（OOD/OOA）、近年はユーザーインターフェース・エクスペリエンスのデザイン（OOUI/OOUX）、オブジェクト指向存在論（OOO）なる哲学分野にまで、広く使われる用語です。ここではOOPについて説明を試みます。 オブジェクト指向の「オブジェクト」は、1967年に発表されたSimula 67 [1] というプログラミング言語に組み込まれた当時としては新しい同名の言語機能（あるいはそれに準ずる...

    オブジェクト指向とは何ですか？
    ch1248
    ch1248 2019/02/17
    suminさんのガチな解説。
    リンク

  • お前は絶望的にプログラミングに向いてないから諦めて刺身にタンポポ乗せる仕事でもやってろ｜古都こと｜note


    刺身にタンポポ乗せる仕事ってきょうび言わねーな……。 プログラミングとは、勉強も運動もスマブラも下手なクソ隠キャ中学生が﹁俺もパソコン1台で凄い技術者になって…！﹂とワクワクしながら始めるものの思ったより普通に難しいし学校の試験で出たような知識要求されるしで3日で放り投げ、10数年後にnoteで﹁お前らは絶望的にプログラミングに向いてないからやめろ﹂なんて記事を書くだけのザコに成り下がる、夢と希望に溢れた技術である。 近年ではパソコンのスペックの上昇にともないできることも増え、どこのご家庭にもあるRTX2080で簡単にディープラーニングもできるようになった。Unityで3Dゲームをバリバリ動かしてもブルースクリーンは出ない。やっぱ世界を広げるのは小賢しい知恵よりもスペックの暴力だぜ。 開発環境や言語も選択肢豊富で、エディタもかつては有料クラスでも手に入らなかったような贅沢な機能が満載のもの
    お前は絶望的にプログラミングに向いてないから諦めて刺身にタンポポ乗せる仕事でもやってろ｜古都こと｜note
    ch1248
    ch1248 2019/01/01
    OOのとこでため息ついてたが、「オブジェクト指向 qiita」で検索したら粗悪な記事がバンバン出て来て、「こいつらのせいか……。」となった。
    リンク

  • オブジェクト指向にメリットなんて存在しない｜古都こと｜note

    最近の新人は勉強熱心だ。新しく聞いた概念を貪欲に取り入れようとする様は、はたから眺めていても感心する。私なんて10年前に得た知識でなんとかごまかしごまかし生きているというのに。 もちろん様々な場面で「躓き」は発生する。有名どころではポインタや非同期処理が初心者キラーだ。そして一番の初見殺しは……オブジェクト指向だ。 オブジェクト指向に殺されたプログラマは数知れない。新人からベテランまで、たいてい皆殺しにされている。 なぜそれほどまでに多くのプログラマを混乱させるのだろう。本やネットではオブジェクト指向の数々の多大なメリットが列挙されており、実に素晴らしいパラダイムに思える。しかし教本通りに組んでみてもどうにもしっくりこない。本当に自分はオブジェクト指向のメリットを享受できているのだろうか？ 種明かしをしよう。実はそれらメリットとやらは全部全くの嘘で、オブジェクト指向にメリットなんてものは存

    オブジェクト指向にメリットなんて存在しない｜古都こと｜note
    ch1248
    ch1248 2019/01/01
     suminさんの爪の垢を飲ます案件。皆病気になってないからワクチン不必要って位に雑な主張。/これでも読め。http://d.hatena.ne.jp/minekoa/touch/20090120/1232478685  

    ●ネタ
    ●OO
    ●論
    ●*clip
      
    リンク

  • オブジェクト指向の呪いと、その避け方 - mizchi's blog


    このテーマで書く前に、まず、最初に自分に多少の偏りがあることを認めておかなくてはなりません。 オブジェクト指向より、関数指向寄り オブジェクト指向のアプローチは有用だが、ただしそれを実現する手段はクラスと継承ではない。 階層化されたツリー構造(GUI/リレーショナルな参照構造)に埋め込まれる状態はコード品質を悪化させるので、できるだけ出現するべきではない。 ただし、状態は確実に存在する。だからこそ慎重に扱うべきだ、という派閥です アンチパターン: 特に理由もないクラスメソッドへの所属 何かのバリデータを実装したいとします。 その関数がどこに所属するかについて、よく見るこれらの実装は全部アンチパターンといっていいと思います export class Validator { static validate() {...} } export class Validator { validate(
    オブジェクト指向の呪いと、その避け方 - mizchi's blog
    ch1248
    ch1248 2018/07/31
    論旨に同意。OOにおいてクラスはあくまで代替品であるし、継承やSingletonはあくまで必要悪であり密結合の権化なので排除されて然るべき。
    リンク

  • Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。 – ゆびてく

    Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。 – ゆびてく
    ch1248
    ch1248 2017/12/02
    面白かった。
    リンク

  • オブジェクト指向とは何だったのか？ – ゆびてく

    オブジェクト指向とは何だったのか？ – ゆびてく
    ch1248
    ch1248 2017/12/02
    大変興味深い。
    リンク

  • 単一責任の原則(SRP)についての見解と方法論 - FLINTERS Engineer's Blog


    こんにちは@kimutyamです。 今週末はいよいよScalaMatsuri2017ですね。 弊社は、今年も将軍スポンサーとして参加させていただきます。 そして今年も同人誌を配布させていただきます。 同人誌については去年配布した話を杉谷がブログで紹介しております。 labs.septeni.co.jp 今年の同人誌目次は以下となります。 ScalaでAndroidアプリ開発 単一責任の原則(SRP)についての見解と方法論 末尾再帰の呼び出し最適化の有無によるScalaコンパイラの挙動について Akka HTTP で LINE bot を作ってみました 新卒scalaエンジニアが書くISUCONの歩き方 去年に比べて記事数は少なめですが、内容は濃くなっております。 ちなみに私は弊社の今泉と一緒に﹃単一責任の原則(SRP)についての見解と方法論﹄を執筆しました。 (Scala関係ないw) 代わ
    単一責任の原則(SRP)についての見解と方法論 - FLINTERS Engineer's Blog

  • 404 Blog Not Found:オブジェクトは難しくない。難しいのはクラス


    2006年11月16日16:55 カテゴリLightweight Languages オブジェクトは難しくない。難しいのはクラス 大人だからオブジェクトは難しくなる。子供にとっては実はオブジェクトは自然で自明で簡単だ。 オブジェクト指向を正しく理解する‥ITpro オブジェクト指向はしばしば，とっつきづらく難しい技術と言われます。その理由の一つには，対象とする分野が広く，それぞれに深みがあることが挙げられます。しかし，それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と，﹁もの中心﹂を意味するコンセプト自体の問題です。事実、オブジェクト指向というのは最初は子供向けだったのだ。 このことを、現在﹁オブジェクトとはなんぞや﹂という大人たちは忘れてしまっている。 それで、オブジェクトとは何か、といえば、﹁自分が何が出来る
    404 Blog Not Found:オブジェクトは難しくない。難しいのはクラス

  • オブジェクト指向設計（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（条件分岐

  • ドメイン駆動設計のためのオブジェクト指向入門


    その時は最善の実装だと思っていたことでも、月日が立つことで、それは間違いだったと気づくことがあります。5年という歳月はそれを気づかせるには十分な時間で、 DDDをやり始めた初期の頃に書かれたコードは良くディスられたりしています。 そのコードは何を失敗していたのか？そして、それは改善するために改善した事とは？ BIGLOBEにおける"今"のいいコードの書き方をできる限り具体的な事例を元に紹介します。
    ドメイン駆動設計のためのオブジェクト指向入門

  • 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/
    Android Javaでフィールドにmプレフィクスをつけるのはやめよう - Islands in the byte stream
    ch1248
    ch1248 2016/01/24
    なるほど。
    リンク

  • Squeak Smalltalkで荷物運びゲームを作るガイド - レガシーコード生産ガイド


    2015-12-07 Squeak Smalltalkで荷物運びゲームを作るガイド Smalltalk Squeak これはSmalltalk Advent Calendar 2015の7日目の記事です。 はじめに この記事では、Squeak Smalltalkで荷物を運ぶゲームの簡易版を製作した過程などを紹介します。 完成品のプレイ動画です。 www.youtube.com この記事対象はかなり限定されています。簡単に言えば、少し前の私が読みたかった記事です。 Smalltalk以外でのプログラミングの経験は少しあって、Smalltalkにかなりの興味を持ち、入門書を読み終わった時点です。しかし今までの環境とあまりにも違うので、何を作れるのか、どう踏み込んでいけばよくわからず躊躇していました。そういう風に戸惑っていた私と同じような人を対象とし、モチベーションを上げることを目的としています
    Squeak Smalltalkで荷物運びゲームを作るガイド - レガシーコード生産ガイド
  • 1 2 3 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.