オブジェクト指向を教えてくれ！★２

**デフォルトの名無しさん** · 2021/04/27(火) 15:02:28.94

オブジェクト指向について、調べれば調べるほど疑問が募ります。低レベルで粗末な疑問かも知れませんが、ご教授願いたいです。

・データと振る舞いをまとめる？
まとめると何か良いことあるの？
ファイルあるいはモジュールにはまとまってるよね？
丁度いい単位があるのに、何故わざわざオブジェクトという概念を導入するの？
(Javaには1ファイル1クラスという文化あるらしいけど)

・カプセル化？
モジュールのimport, exportでも実現出来るよね？
(構造体などへのアクセスを制限できれば)

・ポリモーフィズム？
別にデータと振る舞いをまとめなくても実現出来るよね？

・モノのように扱いたい？
モノとして扱いたいときに扱えば良くない？なんでわざわざ全てをオブジェクトにするの？

※前スレ
https://mevius.5ch.net/test/read.cgi/tech/1615881962/

**デフォルトの名無しさん** · 2022/06/15(水) 00:01:45.70

変形して合体します

**デフォルトの名無しさん** · 2022/06/15(水) 06:24:33.83

https://i.imgur.com/6VNGbOp.gif

**デフォルトの名無しさん** · 2022/06/15(水) 06:42:31.25

>>576
特に意味はありません
あなたはだまされていたのです

**デフォルトの名無しさん** · 2022/06/15(水) 08:17:44.28

コンバートを行うコンバータ関数ばかりを集めてクラスを作るの、
ありですか。メソッドだけで構成されたクラスです。

**デフォルトの名無しさん** · 2022/06/15(水) 09:58:07.75

>>576
一種の宗教みたいなもの
プロパティは全てプライベートにしてアクセサによるアクセスのみにしましょうみたいな事を言う人がいるが
パブリックにして直接参照しても特に問題無い
（C#などはそれでもアクセサが用意されていればアクセサ経由でのアクセスになるが）
ただ仕事ではコーディング規約やルールがある場合があるので従うしかない時はある

>>581
ユーティリティクラスみたいな言い方をする場合があるけど全てスタティックのメソッドだけみたいなのは
割と良く利用されているし普通にありだけど、こういうのばかりになるとスタティックおじさんみたいな
事を言う人がたまにいるｗ
あくまでクラスに属さない処理をさせる場合に適応してクラス内の処理が妥当な場合はそちらに移動させましょう

**デフォルトの名無しさん** · 2022/06/15(水) 15:45:38.93

JAVAは結局コボラーをジャバラーにしただけだったな

**581** · 2022/06/16(木) 14:21:45.56

>>582
ユーティリティクラスですか。とても勉強になりました。
助言くださってどうもありがとうございました。

**デフォルトの名無しさん** · 2022/06/18(土) 01:22:20.46

セッターとゲッターがあればそれはオブジェクト指向ではない

**デフォルトの名無しさん** · 2022/06/19(日) 00:38:43.38

カプセル化はもう時代遅れ
教科書プログラム用の練習教材ですよ
とはいえケースバイケースで使ったほうが便利な時は使えばいい

しかしあまりに膨大なパラメーターを必要とするならthisでやり取りすべきだろう
その場合はメソッドを作るというよりは冗長なプログラムを分割するためのテクニックとして使われるはずだ
カプセル化とは意味合いが全く異なるということだ

従って綿密な注釈を入れて区別化を明確にしておくべきだろう
capsule　voidという新しいコマンドができることを強く望む

**デフォルトの名無しさん** · 2022/06/19(日) 01:02:00.90

もっと簡単に言えば
長いプログラムを組んでいればたくさんのファイルが必要となる
そのファイルすべてをカプセル化するのはじつにナンセンスと思われる
中には特定のファイルに紐づけされたファイルを作ったほうがプログラミングしやすい場合が多々発生するだろう

しかしながら教科書にはすべてカプセル化しなければならないかのような記述がある
おそらくその教科書の作者は長いプログラムを組んだことがないのだろう

そこで私はこれからのプログラムはハイブリット化が必要だと提言したい

**デフォルトの名無しさん** · 2022/06/19(日) 02:04:16.11

>>586
「カプセル化」についてもう少し勉強しようね

**デフォルトの名無しさん** · 2022/06/19(日) 02:45:28.44

>>576
オブジェクトのインターフェイスを統一して
いろんなアプリで利用できるようにしましょうっていう
考え方が1990年代にあったんよ

JavaBeansやMSのComponent Object Modelなど

クライアントアプリのGUI構築には役に立った
いまでもJavaBeansやCOMで動くアプリはある

あくまでもオブジェクト指向の応用の一つでしかないので
真似する意味はあまりないよ

**デフォルトの名無しさん** · 2022/06/19(日) 03:04:29.39

カプセル化はアクセサーを用意することではなくて
データと操作を一体化すること

オブジェクト指向は小さい部品を組み合わせて大きい部品を作り
さらにそれを組み合わせてシステムを作るみたいな
レゴブロックのようにプログラムを構築できるから作ってて楽しい

**デフォルトの名無しさん** · 2022/06/19(日) 05:34:06.82

ﾃﾞｰﾀとメソッドは全然別物
一体化なんてしねぇだろ
何適当なこと言ってんだこいつ

**デフォルトの名無しさん** · 2022/06/19(日) 08:56:58.57

>>586
そこでpackage/moduleですよー
なおそれをbless()してOOP機能を実装してしまった言語の末路…

**デフォルトの名無しさん** · 2022/06/19(日) 09:46:45.68

>>589
それだね。
DIの考え方が根底にあって、外部から列挙可能であることも重要なんだが
getter/setterの形式だけ真似しても意味が分からないのは無理もない。

**デフォルトの名無しさん** · 2022/06/23(木) 18:47:48.02

オブジェクト指向はもう古い
たとえ重複するプログラミングコードがいくつになろうとも
メンテナンスのしやすさを考えると
合理化より複合化を選択するべきだろう
それが実用だ
教科書う通りにしたがるガリ勉くんは講師でも目指したほうがいい
これからはプログレッシブル指向という新概念を私は提唱したい

**デフォルトの名無しさん** · 2022/06/23(木) 22:06:20.59

関数の引数を無くすか
新しく演算子を考えてよ

**デフォルトの名無しさん** · 2022/06/25(土) 03:43:53.27

スクリプト言語はポリモーフィズムを積極的に使うことでいわゆる型による条件分岐を内部に委ねられるから往々にしてその部分の実行速度を上げられる

**デフォルトの名無しさん** · 2022/06/28(火) 13:40:13.28

積極的に使うほどそもそもポリモーフィズム使うか？
jsとかだと余計に使わないかと
ゲームとかなら敵の種類毎にクラスにするとかあるけど
業務や管理画面みたいなので使う所あるか？

**デフォルトの名無しさん** · 2022/06/29(水) 00:29:20.28

私は数年前からオブジャクト指向は廃止するべきだと思っている
なぜならオブジュクトごとに変数を設定しるため、ぱっと見でわかりにくいからだ
膨大なプログラムを組む場合このぱっと見は極めて重要だ
そこで私はプログレッシブ指向をかねてから提案してる
具体的にはメインクラスで重要な変数を全て設定して
サブクラスにthisで受け渡す包括方式だ
オプジェクト指向は数式遊びになってしまった感がある
このへんで初心に戻るべきだろう

**デフォルトの名無しさん** · 2022/07/15(金) 20:52:22.59

正答率が1桁から50.3％に改善
　それに対してMinervaによるMATHデータセットの正答率は50.3％にも達する。過去のSOTAを大幅に上回った。
グーグルは他の問題データセットでもMinervaの性能を試した。優秀な中学生であれば満点が取れる小学生レベル
の算数問題のデータセット「GSM8k」のMinervaによる正答率は78.5％（SOTAは74.4％）で、
高校と大学レベルの工学、化学、数学、物理学などの問題からなるデータセット「MMLU-STEM」の正答率
は75.0％（SOTAは54.9％）だった。いずれもSOTAを上回った。
https://xtech.nikkei.com/atcl/nxt/column/18/00692/070600084/

**デフォルトの名無しさん** · 2022/07/19(火) 10:11:55.94

>>594
template みたいに重複しまくりでメンテナンスもし難いのが最強ですね判ります

**デフォルトの名無しさん** · 2022/07/27(水) 22:15:41.34

お爺ちゃん、今は2022年ですよ？
オブジェクト指向を廃止だのカプセル化が時代遅れだの、そんな御託を述べる前に言葉の意味を理解しようね

**デフォルトの名無しさん** · 2022/07/27(水) 22:46:47.88

今更遅すぎだろうけど
>>1みたいに賢い人間はRustをやってみるべきだよ
君は対象者だ

**デフォルトの名無しさん** · 2022/07/27(水) 23:39:35.59

>>601
2022年は、去年ですよ？？

**デフォルトの名無しさん** · 2022/07/31(日) 23:31:05.92

冗談を真に受けるなよ

**デフォルトの名無しさん** · 2022/08/06(土) 23:39:31.15

米国のMIT（マサチューセッツ工科大学）で行われた研究によれば、大学レベルの数学の問題を「解く」
「説明する」「新たに生成する」の3つが実行可能なAIを開発した、とのこと。
これまで開発されたAIは一部を除き人間用に書かれた数学の問題文から直接答えをを導き出そうとして失敗してきました。
しかし新たに開発されたAIは、人間用に書かれた数学の問題文をコンピューター用の正しいプログラムコードに
自動的に変換・合成する訓練がなされており、わずか数秒で既存のAIの
10倍にあたる81%の精度で正しい回答を行うことが可能となっています。
https://nazology.net/archives/112943

**デフォルトの名無しさん** · 2022/08/11(木) 15:58:24.47

ニューラルネットワークは高度な数学の問題を解くことはできないと広く信じられてきた。
MITはこの神話を打ち破るため、ニューラルネットワーク「OpenAI Codex」を用いてテキストで事前学習し、
コードで微調整することで、大学レベルの数学問題を正答率81％で解くことに成功した。
これまでの正答率は8.8％だったという。さらに問題について解説したり、新たに問題を生成したりすることも可能だ。
https://atmarkit.itmedia.co.jp/ait/spv/2208/09/news151.html

**デフォルトの名無しさん** · 2022/08/14(日) 20:30:37.05

オブジェクト指向出てきてから５０年くらいたつのか？
じゃあ古いじゃん

**デフォルトの名無しさん** · 2022/08/20(土) 13:17:29.92

オブジェクト指向とかデザインパターンとかまとめてゴミになりそうね

**デフォルトの名無しさん** · 2022/08/21(日) 11:02:50.87

デザインパターンがゴミになると思ってるやつは総じてゴミ

**デフォルトの名無しさん** · 2022/08/21(日) 11:10:39.17

パターンｗとか言っている方がゴミだけどなｗ
そんなのプログラムしていれば分かるような事ばかりなのに
そういう本から入った奴らって低能ばかりなんだよなぁｗ

**デフォルトの名無しさん** · 2022/08/21(日) 15:18:48.70

>>610
マジでパターン理解してないんだな
まぁ頑張ってね

**デフォルトの名無しさん** · 2022/08/21(日) 16:22:21.87

>>611
だから本から入ったんでしょ？ｗ
で偉そうになんとかパターンですｗとか言っているのは滑稽だという話ｗ
理解できないなら相当頭が悪そうだけどｗ

**デフォルトの名無しさん** · 2022/08/21(日) 16:45:03.52

ブリッジパターンとストラテジパターンを覚えたが良い

**デフォルトの名無しさん** · 2022/08/22(月) 02:47:49.95

デザインパターンは言語機能の欠陥を埋め合わせるパッチワークでしかない
デザインミスを隠蔽するためのパターン集だと言うことを分かって使ってる奴がいないよな
こう言うのは大体JavaかC#しか言語触ってないと相場が決まってる

**デフォルトの名無しさん** · 2022/08/22(月) 02:54:22.43

パターン名を言う奴のほとんど、それを使う理由を写経レベルでしか理解していない説

君はデザインをやってるつもりなんだろうけど、実際はコピペプログラマからコピペプログラマ未満になってることを自覚した方がいい
コピペプログラマは、「うは、これ便利」と思ってコピペするけど、
デザインパターン厨は長々しい実用性のない議論と先駆者への謎の敬意と引用の後に
結局なぜそれを採用するかの説明から逃げるからな

説明から逃げる上流気取りは総じてカス
誰もその基本を指摘しないから、致命的な段階になるまで錯誤し続けるんだよな

**デフォルトの名無しさん** · 2022/08/22(月) 09:43:55.60

この世には2種類の人間がいる
・ブリッジパターンを知らない人
・ブリッジパターンを知ってる人

どちらになるかはその人しだい

**デフォルトの名無しさん** · 2022/08/22(月) 09:45:38.54

>>614
バカ乙、お前はブリッジパターンを何も理解してないことがお前の発言から明らか
よってお前はブリッジパターンを知らずにただ漫然と時が過ぎるのを是とし
過ぎ去る日々をボーと眺めてるに等しいボケ老人

**デフォルトの名無しさん** · 2022/08/22(月) 09:49:16.82

>>615
パターン名は覚えていないと車輪の再発明になるよ
一生涯をかけてプログラムに磨きをかけてブリッジパターンを再発明しました
みたいな悲しいことになっちゃうからブリッジパターンはいまのうちに覚えておこうよ

**デフォルトの名無しさん** · 2022/08/22(月) 09:53:07.23

世界的に使われるアプリ作った人が
「〇〇パターンを採用しました」とか言ってるのは見たことないからそういう事

アプリの中のソースコードにも様々なセクターがあって色んな設計、言語が織り交ざるんだから
デザパタ云々の話ってどこでやるのって思う

**デフォルトの名無しさん** · 2022/08/22(月) 10:01:20.65

>>619
そんなの当たり前だろ
ユーザにソースコード説明してどうすんだアホｗ

**デフォルトの名無しさん** · 2022/08/22(月) 10:03:10.09

このように何もかもをごっちゃにしてバグった頭で日々を過ごすアホになりたくなかったら
ブリッジパターンを勉強して整理する力を身に着けて圧倒的成長を遂げよう

**デフォルトの名無しさん** · 2022/08/22(月) 10:04:39.87

>>620
創設者がインタビューされた記事で
使った言語とか経緯とか歴史を喋る事ってあるでしょ

そこで"デザパタ"の話は出てきた事あるだろうか・・・

**デフォルトの名無しさん** · 2022/08/22(月) 10:07:42.18

>>622
ちょっと何言ってんのかわからない

**デフォルトの名無しさん** · 2022/08/22(月) 10:08:21.97

何を創設したん？何の話？統一協会の話してんの？

**デフォルトの名無しさん** · 2022/08/22(月) 10:17:00.75

別にGARAMでもなんでもｗ
探せば何か喋ってるよ

デザパタって単に手足として働く役割の社畜マにコードリーディングさせるときのヒントだと思うよ
一流の人はもっと違う場所の事考えてるから話題にならない

高負荷や技術的障害はなんちゃらパターンが解決してくれること無いし
最も優秀な人は、全体の1%のコードのボトルネックとなる部分を負荷軽減する発想や技術があって
残り99%は社畜マでも作れるからデザパタで組もうが何しようがどうでもいい事なのよ

**デフォルトの名無しさん** · 2022/08/22(月) 10:26:35.12

GARAM創設の話？それってブリッジパターンとなんか関係あるんすか？

**デフォルトの名無しさん** · 2022/08/22(月) 10:28:03.79

会社作ったときのサクセスストーリーをインタビューしてブリッジパターンを引き出したら
そのインタビュワーはただものじゃないな

**デフォルトの名無しさん** · 2022/08/22(月) 10:31:45.95

> 創設者がインタビューされた記事
起業の話かな？

> 高負荷や技術的障害
運用の話かな？

ブリッジパターンと全然関係ない話を自分でして
ブリッジパターンは役に立たないんだという結論を導く
みなさんこれがアホです

**デフォルトの名無しさん** · 2022/08/22(月) 10:32:42.31

ブリッジパターンを勉強してこなかったツケがこの有様です

**デフォルトの名無しさん** · 2022/08/22(月) 12:30:53.49

>>619,622
すごい
バカ丸出しwww

デザパタコンプレックス拗らせてるのはこの手の人だったのか

**デフォルトの名無しさん** · 2022/08/22(月) 12:38:32.92

>>625
>高負荷や技術的障害はなんちゃらパターンが解決してくれること無いし
デザインパターンとはレイヤーが異なるだけ
サーキットブレイカーとか知らないでしょ？

**デフォルトの名無しさん** · 2022/08/22(月) 12:48:42.80

パターンというものの本質的価値を理解せず
デザパタの表面だけみてる人は抽象化思考能力が著しく低い

抽象化思考能力の低い人はまともなソフトウェアは作れない
ソフトウェア開発者の適性がないと言い換えてもいい

つまり>>609

**デフォルトの名無しさん** · 2022/08/22(月) 13:55:06.32

デザパタの名前なんて後付けだしな

**デフォルトの名無しさん** · 2022/08/22(月) 13:58:03.19

>>615
ほんそれ
めっちゃ判りますωωω=2πf

**デフォルトの名無しさん** · 2022/08/22(月) 14:01:45.39

>>633
お前の名前だって後付だろ
だからといってお前に価値が無いわけではないだろ
生まれてきてくれてありがとう

**デフォルトの名無しさん** · 2022/08/22(月) 14:10:48.49

エドガー・ダイクストラはGoTo文のパターンを整理してIfやForといった名前をつけた
今日のプログラミングではIfやForを使ってプログラムを作る
プログラミングにおいて名前を付けることは新たな道具の発見である

**デフォルトの名無しさん** · 2022/08/22(月) 14:12:05.65

道具としての設計、深いね

**デフォルトの名無しさん** · 2022/08/22(月) 15:06:13.89

GARAMって何やねんw
マサラか？Racebookか？

**デフォルトの名無しさん** · 2022/08/22(月) 17:37:57.52

>>636
社畜風情が勘違いしすぎｗ
社畜マがどのように何を考えて「誰でも出来る範囲の」コーディングをしようが
天才たちの知る話ではないという事だ

所詮、デザパタやオブジェクト指向含め、社畜マが何か真理とかと勘違いして勉強するけど
結局はただ世の中にあるソースコードに一貫性・規則性持たせる努力義務を課し
社畜達が保守点検しやすい規格をポンっと用意してるだけ
おわかりかな？

**デフォルトの名無しさん** · 2022/08/22(月) 17:53:24.28

>>639
天才ねえ弱小少数派の意見は参考にならないな
所詮少数派だろ

**デフォルトの名無しさん** · 2022/08/22(月) 17:53:55.66

天才にはそういうの必要ないとか、そういう詭弁の方が必要ないだろ

**デフォルトの名無しさん** · 2022/08/22(月) 18:22:02.42

>>639
やっぱりな実装面しか見えてない
底辺社畜のデザパタ嫌悪

**デフォルトの名無しさん** · 2022/08/22(月) 19:39:35.57

GoFによると、会話の中で用いるために、デザインパターンに統一された名前がついていることは大切らしいぞ。

**デフォルトの名無しさん** · 2022/08/22(月) 19:44:10.29

建築家クリストファー・アレグザンダーが提唱したパターン・ランゲージの一部として捉えると理解しやすいかもしれない。

**デフォルトの名無しさん** · 2022/08/22(月) 19:44:59.09

天才が考えた正規表現を見てみるか、オブジェクト指向だったら
replace(regex , "$1,$2,$3")
こんな実装許されないよ？可読性低すぎ引き継ぐ次の人の事考えてない社畜としてあるまじき関数だ
こんな自作関数定義したらすぐクビだね

何らかのデザインパターンに沿ったオブジェクト指向なら、こうするべきだろう異論は認めるよ
o = obj.new(str)
o.replace(regex)
o.Regex["$1"]
o.Regex["$2"]
o.Regex["$3"]

**デフォルトの名無しさん** · 2022/08/22(月) 19:47:53.25

あああれね

**デフォルトの名無しさん** · 2022/08/22(月) 21:05:25.05

>>645
デザインパターン以前に正規表現に対する理解が不足してるように思われる

正規表現は式からオートマトンを生成して
オートマトンに文字列を入力してオートマトンが終端状態に達するか確認するものなんよ

よって作成するオブジェクトはオートマトンを内部に保持するものだよ

こんな感じ
re = Regexp.Compile(expression)

使うときはこんな感じ
re.Replace(source, destination)

式が固定ならオートマトンオブジェクトを使い回すことで式からオートマトンを生成する処理を減らせる
直感的で性能の良いオブジェクトのできあがり

**デフォルトの名無しさん** · 2022/08/22(月) 22:06:19.63

>>645
何らかのデザインパターン！？
何らかのデザインパターン！？
何らかのデザインパターン！？
wwwwww

**デフォルトの名無しさん** · 2022/08/22(月) 22:06:29.75

>>647
正規表現って文字列だけだと思ってるだろ
プログラミング言語には実装されてないだけで正規表現は文字列に限定しないぞ

そもそもコンピュータにおいて文字列と配列って言語によっちゃ近いものなんだよ
配列を正規表現できるってことは、構造体も正規表現できるだろ
じゃあ次は構造体を正規表現したらアプリケーションも正規表現できるぞ
なぜやらないんだ

**デフォルトの名無しさん** · 2022/08/22(月) 22:12:22.43

正規表現で配列・構造体・アプリケーションを書かれると、人が理解できないからだぞ
人が理解できないと、限りなく短縮された表記を捨てて
一次変数や、コメントや、オブジェクト指向という冗長したものをソースコードに入れる必要がある

でざいんぱたーんもそのひとつ

理解（りかい）できない人（ひと）のために冗長（じょうちょう）したものをプログラミング（ぷろぐらみんぐ）言語（げんご）にいれる必要（ひつよう）がある

**デフォルトの名無しさん** · 2022/08/22(月) 22:14:42.04

>>645
>replace(regex , "$1,$2,$3")
string.replace(regex, "$1,$2,$3")と書きたかったのかな？
じゃないならreplaceする入力値はいずこ？

**デフォルトの名無しさん** · 2022/08/22(月) 22:15:58.07

>>649
正規表現はあくまでも有限オートマトンなので限界があるよ
JSONさえ書き表せないのにアプリケーションは無理じゃないかな

**デフォルトの名無しさん** · 2022/08/22(月) 22:22:53.84

>>651
this selfくらい知っておけｗ

>>652
文字列は配列であり、配列は構造体である
って分からないのかな？
C言語でポインタまともに学んでるかどうかだな

**デフォルトの名無しさん** · 2022/08/22(月) 22:24:54.46

>>653
それは実装によるでしょ
JavaScriptでは文字列を木構造で管理してるよね

**デフォルトの名無しさん** · 2022/08/22(月) 22:28:36.05

仮に文字列が配列だったとしても
正規表現はあらゆる文字列を扱えるわけではないよね
たとえばJSONは正規表現では扱えない
JSONも扱えないのにアプリケーションを正規表現で書くのは無理じゃないかな

**デフォルトの名無しさん** · 2022/08/22(月) 22:30:36.09

木構造やリストなど再帰的データ構造は正規表現では無理

**デフォルトの名無しさん** · 2022/08/22(月) 22:32:35.76

「文字列は配列だ」
と
「アプリケーションを正規表現で書ける」
の
間には大きな隔たりがあるよ

**デフォルトの名無しさん** · 2022/08/22(月) 22:39:44.17

オブジェクト指向の話に戻すと
オブジェクト指向では文字列オブジェクトの内部で配列を使ってるかを気にする必要はないよ
オブジェクトの内部に依存するプログラムを書かなければいけないならオブジェクトの設計がよろしくない

**デフォルトの名無しさん** · 2022/08/22(月) 22:46:38.86

>>653
>this selfくらい知っておけｗ
いや何言ってんのw
マジでw

**デフォルトの名無しさん** · 2022/08/22(月) 22:48:11.12

>>654
実装っていうかね
最もコンピュータにとって素早く無駄なく処理できる構造体って、ようはCの文字列、バイナリだろ
正規表現ってのはC言語で使えば実感わくだろうけど、メモリーマップにある指定場所のバイナリを弄ってるんだよ
そしてＣ言語ってのは文字列と配列と構造体の敷居が非常に薄い
あとはもうわかるでしょｗ
難しい話だねｗ

**デフォルトの名無しさん** · 2022/08/22(月) 22:52:49.94

>>659
経験した言語が少なすぎる・・・
this self省略したソースも見たことないのか

**デフォルトの名無しさん** · 2022/08/22(月) 23:08:38.51

>>660
> 最もコンピュータにとって素早く無駄なく処理できる構造体って、ようはCの文字列、バイナリだろ
処理によるんじゃなかろうかと
配列と木構造では計算量が異なるからね
配列が優れてる処理もあれば木構造が優れてる処理もある
配列はたとえば値を単純に追加していく処理や任意の位置に値を挿入する処理が苦手
あなたが何を言いたいかは俺にはわからないな

**デフォルトの名無しさん** · 2022/08/22(月) 23:18:57.00

>>661
Stringクラスとかに追加するある関数の中で
this.replace(regex, "$1,$2,$3")
と書いた例だったの？
オブジェクト指向とか言ってんのに
あえてレシーバーを省略する意味もわからんけど
例がヤバすぎやろ

o.replace(regex)はどこにthis/selfが省略されてるのかな？
難問すぎるわw

**デフォルトの名無しさん** · 2022/08/22(月) 23:23:58.47

>>649
その文字と文字じゃないものってどういう区別で言ってる？
正規言語の入力は有限でお互い識別できる記号の列である必要があって、通常それを文字と呼ぶ。

**デフォルトの名無しさん** · 2022/08/22(月) 23:36:53.17

本人も自分が何を言ってるのかわかってないんじゃないかな
思考がぼんやりとしてる人っているからね

小泉環境大臣「くっきりとした姿が見えてるわけではないけど、おぼろげながら、浮かんできたんです。46という数字が」

**デフォルトの名無しさん** · 2022/08/22(月) 23:50:24.80

>o = obj.new(str)
>o.replace(regex)
>o.Regex["$1"]
>o.Regex["$2"]
>o.Regex["$3"]

意味不明なコードなんだが
何をしたいのか誰かエスパー解説してくれ

**デフォルトの名無しさん** · 2022/08/22(月) 23:58:25.34

まずそもそもオブジェクト指向以外の例として正規表現の可能性に触れたけど、「正規表現でもプログラミング可能」という1例に過ぎず
その一つすら理解できないでそこの話もっとしなきゃいけないのは面倒くさいよw
せめて文字列＝配列＝構造体＝アプリケーションでイコール繋がってくれる基礎教養のある人に
「気づき」を与えたいだけのレスであって、基礎知らないないで分かった振りしてる人じゃどうにもならないなあ

**デフォルトの名無しさん** · 2022/08/23(火) 00:21:58.37

「負け犬の捨て台詞」パターンですねw

**デフォルトの名無しさん** · 2022/08/23(火) 02:18:11.31

正規表現とは「文字列の集合を表す文字列」でしかない。

**デフォルトの名無しさん** · 2022/08/23(火) 10:32:18.96

>>665
4610

**デフォルトの名無しさん** · 2022/08/23(火) 10:34:14.76

>>666
perlでもpythonでもawkでもなんでもいいから正規表現を覚えろ

**デフォルトの名無しさん** · 2022/08/23(火) 11:11:51.25

何か偉そうにイキってても
コード書かせたら>>645レベルとかw
リアルでは滅多にお目にかかれない低レベル

**デフォルトの名無しさん** · 2022/08/23(火) 11:41:13.55

オブジェクト指向あたりから、マジで数学センス言語センス皆無の
奴がSEとして業界に受け入れられ始めたことを考えると
センス皆無の奴を雇って請負賃金を請求してフィーを掻っ攫う分にはガチで役に立つんだろうなと思ってる

まあ数学も言語もできないやつにデザインセンスが備わるとも思えないので
デザインパターンを暗記して教条的に語るしかできない自称設計集団が出来上がったと

**デフォルトの名無しさん** · 2022/08/23(火) 12:18:38.76

>>666
「python regex」で検索しても、pythonには無い

誰かのモジュールかも

**デフォルトの名無しさん** · 2022/08/23(火) 12:40:33.27

自称数学センス言語センスのある人が書いたコードが>>645

まさかぁwww
算数センスすらないじゃんwww

**デフォルトの名無しさん** · 2022/08/23(火) 12:44:01.84

自称数学センス言語センスのある人は文系SEにこき使われてルサンチマン溜まってるんだろう
でも客観的に見ればデザインパターンを理解してる文系SEのほうがよっぽど使える
現実逃避は辞めてさっさと仕事しろ

**デフォルトの名無しさん** · 2022/08/23(火) 12:44:29.11

> 何らかのデザインパターンに沿ったオブジェクト指向なら、こうするべきだろう異論は認めるよ
> o = obj.new(str)
> o.replace(regex)
> o.Regex["$1"]
> o.Regex["$2"]
> o.Regex["$3"]

衝撃的、こんなのありえないだろ

みながわけんじさんのIteratorパターン以来の衝撃
https://ameblo.jp/kenchaz/entry-12247911109.html