オブジェクト指向はオワコン
レス数が900を超えています。1000を超えると表示できなくなるよ。
ここまでくると糖質っぽいな
オブジェクト指向はオワコンと言い続けて何年経過してんだよw オブシコオhル
けど、脳汁が出るのは、なんでもアリなC++なんだよなあ これこれ
オウムみたいな感じ
はなから議論をする気が無い
オワコンオワコン繰り返して気持ちよくなるだけ 非論理的=気持ちよくなる
専門用語を回避する現象? 自分がオブジェクト指向で挫折したから
あんなの一時の流行りでしかない!って喚いて溜飲を下げようとしてるけど
そもそも理解しないで挫折してるから「あんなの」が永久に
90年代のC++の時の“自動車の車輪を付け替える”からアップデートしない アップデートという目標は分かったが現時点では違う目標を持つ者にとって
ふつうに考えると目標を達成するためには目標を変更しないのが合理的
問題は、どうすれば永久に合理的であり続けるのをやめられるか 俺がいる
中途半端ってぶっちゃけ怖いよね
>>826
議論っていうか、使えと言われた言語・ライブラリ(SDK)使うんだからね結局
好き・嫌い、とかって雑談してりゃいいんだよ
俺は、継承を使いこなせるいい漢になりたいぜ オブジェクト指向だろうがオブジェクト指向言語だろうが語りたいのならマ板でやれ
雑談どころかここで議論とか正気かよ。議論してもプログラム技術の役に立たないくらいわかるよな >>831
はっきり言う、お前はオブシコのことを何もわかってない
>>832
お前もだ
オブシコは挫折してからが始まりだ intではなくてMoneyだ
Moneyを継承してYenを作れ
stringではなくてAddressだ
Addressを継承してPrefectureを作れ
本物のオブジェクト指向を経験しろ
ぜったい挫折するから >intではなくてMoneyだ
当たり前
>Moneyを継承してYenを作れ
意味不明
オブジェクト指向で作るならYenはMoneyの一属性
>stringではなくてAddressだ
当たり前
>Addressを継承してPrefectureを作れ
意味不明
オブジェクト指向だから挫折したのではなく間違ったオブジェクト指向を学ぼうとしたから挫折したんだな >>832
ムに置いときゃ、ムに資するネタがまじるけどね
俺は後から来たけど >>835
MoneyにbaseCurrency問い合わせると“Yen”って返すように作るよなぁオブジェクトなんだから >>824
本当にオワコン化したものは話題にすらならんよ
今どきポケベルはオワコンなんてスレ建てる奴なんていないだろ?
つまり、そういうこと ポケベルを話題にした自分自身を否定するより
オブジェクト指向にファイティングポーズする方がよっぽどポジティブじゃないか APIやライブラリを一切使わず、自分自身で「処理をしてオブジェクトを返す部分」も作らずにどんなプログラムが作れるんだよ
現代でプログラム書いてるやつは意識しなくても使うしか無い手法じゃないか
使わずにHelloWorldすら書くのは超難しい システムコールだけでHello Worldやるの無茶大変だった思い出 API使ってればオブジェクト指向とか頭になんか湧いてるだろ 「APIそのものがオブジェクト指向」だと主張してるやつはいるね>>820 とりあえず1000行くらいベタ打ちでプログラム書いて
書いたのをリファクタリングついでにクラス分けして
またダーッと書いてって繰り返せばいいよね? >>847
今世紀に出てきた様々なプログラミング言語はほとんどがクラスをサポートしていない
クラスは役に立たず害が大きいとの共通認識があるため APIは今でも関数とグローバル変数
stdinとかstdoutとか
グローバル変数が一番最初にオワコン化し、オブジェクト指向は二番目以降と想定された オブシコで書かれたAPIとかライブラリってのならある。ってなら書いた
COMとかね 原理的には、ラッパがあれば、避けることはできる これで動くOSあるなら分からんでもない
OS.boot() >>848
事実認識ができてない
JavaScript、C#、Python、Ruby、C++、Java、Kotlin
クラス扱える言語はいくらでもあるし、そもそもクラスや継承を使えない=オブジェクト指向じゃないって訳では無い
クラスはお前みたいな馬鹿には使いこなせないからクラス以外でオブジェクト指向な書ける方法が模索されたんだよw どの言語かに関係なく
クラス継承でプログラミングするやつはバカしかいない 特定のルートクラスに縛られる継承はだいぶむかしにオブジェクト指向のあまり良くない実装として
仕様を残しながら使わない方がベターになってるわな
使うクラスをオブジェクトとして別個にクラスに組み込むコンポジションの方が主流
「継承というのがオブジェクト指向!」とかいつの時代のおじいちゃんだよ あの当時の人なら一度は、オレオレプロジェクトで継承を使いすぎた経験ってあると思うのね 継承しまくって訳わからん事になるなら新しいクラスにした方がいいと思うけどなあ
File
-◯◯FileBase
--◯◯FileStructure
---◯◯FileModel
----◯◯FileInstance
みたいなのよりFile2を定義し直した方が遥かにマシ ファイル名なんかもそうだが
File_20240219
のようなユニークIDつけておくといくら被っても困らない 重複(安易なコピペ)コードはちょっとでもいけませんってきつく言われて、
それを避けるように継承をテキトーに使いすぎた記憶はあるんだよね
is-a 原則を守って、責任者が正しく設計しましょう 似たようなコードが出るなら、サブルーチンにすりゃよかったんだけどね
あの頃は名前空間をあんまり使いこなせてなくて、なんでもクラスに押し込みゃいいと思ってた >>855
と、継承すら理解できない素人が申しております Rustが重複コードは二度と書かないってポリシーだっけ
最初の一歩踏み出すのにとんでもなく時間かかりそう 何をもって重複コードとみなすのかなぁ
たまたま別の機能で同じコードになったとかは
まとめると後で痛い目に遭うよな? >>864
Rustは書かなきゃいけないボイラープレートが多いから重複コードも多い
コピペ継承とマクロ継承がよく使われてる c++ コンセプトをそのまま変数のインターフェイスに使えればなぁ、と思う事はある。 >>864
Rustも他の言語と同様に重複コードがあれば関数として切り出すだけだよ
その時に異なる型に対してもトレイト境界により安全にジェネリック化がしやすく多用されてるね
>>866
Rustは継承ではなく合成と移譲をするためその宣言は増えるけどそれらを重複コードとみなすのはありえないよ >>868
どういう構造で作られているかは重複コードとみなすかどうかには一切関係ない
変更をロックステップで適用しなければいけないのならどういうものであれそれらは重複コード スマポみたいな機能の重複回避には昔は継承を使った
今はジェネリクスを使う
昔の方法ではスタックのint型とヒープのInt型を統一できない すべての型に対して全て同じ実装でよければジェネリクスで良いが一部の型でカスタマイズが必要になるといろんな障害が出てくる >>871
それは普通によく起こることだが全く問題ない
その型ごとの差異の機能を合成するだけで対応できる
もちろんジェネリクスのままでよい インタプリタならそれでいいんだけどね。。(個人の感想です 一部の型でカスタマイズが必要な場合にジェネリクスを使おうとすると将来を見通したカスタマイズポイントを最初に確定しておく必要があって多くの場合現実的ではない
要はOCPを満たせないので変更に対して弱く保守性の低いプログラムになる
加えてRustではcoherenceの制限だったりspecializationやHKTが未サポートだったりで使える状況がかなり限定されている >>873
Rustでも>>872の「その型ごとの差異の機能を合成するだけでジェネリクスのまま対応」できるよ
Rustは必要な機能のトレイト境界を指定することでコンパイル時点で静的にジェネリクスでも安全に呼び出すことが保証されるよ
呼び出し方法は静的ディスパッチによる単相化またはvtable利用の動的ディスパッチどちらも選択できるよ >>876
大規模開発もできるように作られたRustについて真逆のウソはよくないよ
既に大規模開発で採用しているGoogle Microsoft Amazonといった大手IT企業たちが
共同でRust Foundationを設立して資金を出して安定した環境でさらなる開発が進められているよ 既にクラウドやCDNなどネットインフラは次々とRust製へ変わった
ソース
>【クラウド世界トップシェアAWS】
>https://japan.zdnet.com/article/35183866/
>Rustで構築されたAWSサービスの例としては、
>コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
>「Amazоn Simple Storage Service(S3)」、
>「Аmazоn Elastic Compute Cloud(EC2)」、
>コンテンツ配信ネットワーク「Аmazоn CloudFront」、
>LinuxベースのコンテナーOS「Bottlerocket」などがある。
>【CDN世界トップシェアClоudflare】
>https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html
>CDNプロバイダのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたNGINXに代えて、
>同社自身がRust製のHTTPプロキシである「Pingora」を開発し利 用していることを明らかにしました。 大規模開発以外はオワコンゆえに構造化プログラミングはオワコン
というのがオブジェクト指向の原点なのでオワコン論法を今更やめられない >>877
そのどれもが大規模開発じゃ無いぞ
使われてるがチームは数名だぞ 数名で各ネットインフラをRustで開発できるなら今後はRustでいいな 「うちは大規模開発でやってる」という発言が出ないで、他人の情報に反応してそういう結論に切り替えるってことは
つまり自分らでは使ってないってことかいな 大規模開発は人数揃えるのが何より大切だからな
COBOLかJava以外ありえない MVCで入力処理ってどこにおくべき?
AIとかに聞くとCに置けって言ってくるけど
移植(ライブラリ変更等)時に描画系入力系を
まとめてVに置いておくと楽だと思うんだけど いまだにMVCとかやってるから海外のアプリに勝てないんだよな M: 変数
V: public関数
C: private関数 >>887
MVCといってもクライアントサイドのMVCとサーバーサイドのMVCで考え方が違う
また入力処理と言っても人によって指すものが違うので具体的にどういう処理を入力処理とみなしているか書かないとわからない
さらに移植とライブラリ変更は一般的に違うものなので想定状況が伝わらない M: member
V: virtual
C: constexpr
// 空目 用語や形にこだわるより先に仕様通り動くもの作れ。くだらないこだわりで何も始められないのはただのアホ >>887
元々は移植性のためにモデルはそのまんま環境と切り離した処理そのものを
ヴューは人間の目に触れる画面レイアウト周り、そしてコントローラーは
それらを繋ぐインターフェイスとして実装という考え方なので
ゲームをPC、コンシュマー、モバイルと移植します画面周りはVです
操作されるゲームの中身はMです、つなぐ部分はCです
…ん?マウスと十字キーとタッチパネル対応はどこまでがCだ?ってなるけど
AIに聞けばテンプレどおりそら「Cに分けなさい」言われるわな ゲームとビジネスアプリとでは違って来るよな
ゲームなら🎮や⌨はCだが、ビジネスアプリでは単にVの付属物だったりする うそやん
マウス対応やタッチパネル対応はViewやぞ
AIに聞いてもそう答えるぞ 「入力」の抽象度の違い
ビューに依存した入力とそこから一段階抽象度が上がったビューに依存しない入力がある
それを認識できてればどこに含めるか迷わない https://twitter.com/mayappy0627/status/1725074809883898273
M a y a ♡🏳⚧ヽ(๑╹◡╹)v🏳🌈
@mayappy0627
「シスヘテロ男性が女湯に入りたい目的で嘘をついて診断書を取得し性別適合手術を受ける可能性がある」
という言説がいまだに流れている様だが
女湯入ってオカズ目に焼き付けてもチン◯ないからシコれませんのでね。つまり男性的快楽は得られないという結末の一つさえ想定できないんでしょうかね?
午後5:54 · 2023年11月16日
·
https://twitter.com/thejimwatkins きんたま切り落とした時点で男性ホルモンは著しく減衰して性欲は無くなるよ🥲 class Man(Human):
...
def do_chinko():
if (chinko is None): return None
return finish()
... >女湯入ってオカズ目に焼き付けてもチン◯ないからシコれませんのでね
人間に独立した人格が有るように、チンポにも独立したチン格が有る
これは親クラスと子クラスの継承関係である
チン格とはつまり「愚息」であり、自分にも他人にも成り得る
これがオブジェクトの多態性と表現される
オシッコするときのチンポは随意筋、勃起するときのチンポは不随意筋
このように時と場合によって真逆の性質を併せ持つことができる
随意筋 不随意筋
↖ ↗
チンポ
自然言語処理において語の意味は文脈によって変わるので、Pythonのような多重継承が不可欠ね! 機能するかどうかだけが問題で、欲求があるかどうかはあんまり関係無いよな オブジェクト指向では、オブジェクトの「機能」を意識することが大切ね!
>>903
>機能するかどうかだけが問題で
オブジェクト指向(OOP) は、データとそれに関連するメソッドを 「クラス」という単位でまとめて管理する開発手法です。
このアプローチにより、開発者は複雑な機能も再利用可能なモジュールとして効率的に構築できます。例えば、
新しい機能を開発する際、既存のクラスから必要なデータを取得し、必要に応じて新しい機能を追加することが可能です。
https://zenn.dev/cloud_ace/articles/29748ac0537c7f モダンなプログラミング言語
Go、Rust、Zig、Nim、Julia、Elixirなどは
クラスおよびその継承を言語仕様から排除しておりクラスは存在しない
各々の言語は全く異なる方針を採っている言語だがクラス排除だけは全てが同じ方針である
クラスとその継承は悪手であるとプログラミング言語界では結論が出ている むしろ、何段も継承されてわけわからん事になるのが嫌われてるだけなので
swiftなんかはfinalつけてサブサブクラス禁止できるようにしてるな >>905
クラスと呼ばれるものがないだけで
メソッドを生やせる構造体も継承も
Elixir以外のすべての言語に存在する
君が無知なだけ クラスが存在しないことが最重要だからクラスを採用しない言語が増えてるんだよ
クラスは間違った手法『具象型から具象型への継承』となる禁忌のクラス継承を伴うからね
オブジェクト指向に必要なカプセル化は構造体などでもちろん可能だから
オブジェクト指向にはクラスは不要だよ
そしてインターフェイスや型クラスなどによる正しい手法『抽象型から具象型への継承』が代わりにあればよい
モダンな各プログラミング言語はそれらの方針をとっている
だからクラスが採用されてないんだよ
クラスは悪 継承に親兄弟を殺された人がいるようだが 世界は残酷なのだ 悪い→『具象型から具象型への継承』←クラス
良い→『抽象型から具象型への継承』←インターフェース・型クラスなど 要は個人開発レベル小規模webサイトレベルなら継承の類不要?つうかDIだけでは駄目なん? 規模にかかわらず同じ
抽象型からの継承は問題ない
クラス継承はダメ >>914
「抽象型の仕様が安定している限り」な。
抽象型の改変が入ったらインパクトが大きい。 そこでダックタイピング(の併用)だな
うん、継承一本ってのは、人類には早かった クラス継承は具象型からの継承なので多重継承の問題が発生する悪い方法だが
抽象型からの継承は多数あっても合成となり良い方法
>>915
抽象型は各機能毎に細かく多数用意されて合成して使うためそのような問題が起きない
抽象型の改変とは機能を変えることになるため別の抽象型として並行して扱える >>917
なら設計の初期に細かく多数の抽象型を決めなきゃいけない、ということになるわな。
未来を予測できる天才でもなければ厳しいな。 まあ、たいていのクラス設計は
製造終盤になると跡形も無いんだがな >>918
クラスはピラミッド型の階層構造となり改変で他へ影響が大きく出る問題があり
クラスは具象型なのでそれ自体がメンバ変数(フィールド変数)を持ち途中階層のクラスも持つため改変が非常に大変もしくは崩壊となりがち
抽象型でメンバ変数(フィールド変数)を持たないインタフェイスや型クラスではその問題が起きない
それら抽象型による各機能の合成をとるため改変する場合も他機能への影響が限定的となり問題を分離することができる >>920
メンバ変数の無い抽象型であっても、分離できるのは実装部分でしかなくて、「機能ではなく型の種類&名前で縛られる」という設計の初期の困難さは回避できていないよ。
まぁ、インターフェイスとかトレイル(Rustの偽物は論外)とかでもモジュール境界とモジュール間連携の問題は解決できていないからなぁ。何かいいアイディア無い? レス数が900を超えています。1000を超えると表示できなくなるよ。