業務でにわかプログラミングやってんだが「クラス」ってこれ必要か？関数でいいじゃん
■ このスレッドは過去ログ倉庫に格納されています
functionで出来ることをイキってクラスとか難しくしてんの？
NewとかOverridesとかInheritsとか覚えれんわ使いも千野に
NexSeed、小中高生向けのプログラミング×英語スクール「ヴィムテックキャンパス by NexSeed」を9月3日に開校
https://edtechzine.jp/article/detail/1271 マリオでもドラクエでもボンバーマンでもいいからそれぐらいのゲームを設計してみろ。ありがたみがわかるから。 phpやってるけど一覧の数字
合計したりするだけで大変なのに
ファミコンのマリオとかどんだけ
プログラムかかなきゃいけないんだ
ゲームプログラマーってすごい まぁ、君の言ってることは、
「東京から大阪まで歩いていけるじゃん」
と同じ。
どうぞどうぞ、好き勝手にやれ。
聞く耳持たんヤツは、自滅するだけ。 >>3
初代ボンバーマンはBASICだぞ
クラスなんてない頃だぞ まあ難しいことはどうでもええ
全く関係ない関数がバラバラになって存在するなら
クラスに突っ込んで管理したくなるわな クラスも使うし関数も使う
lambdaも使う
甘えんな クラス化しておけばポンポン使えるうえにポンポン破棄出来る >>1
別に無理に使う必要はないぞ。
そのうち必要になる時が来たらでいい。 クラスはPGじゃない限り使う必要ないだろうな
構造体程度かね 小学生レベルのプログラミングなら必要ないよ
お前がやってるのはその程度ってだけ >>14
関数をまとめた関数を作るだけじゃ
だめなんです？ 色々な切り口の整理方法があるって事だ。
オブジェクト指向信者の言うことは聞くな。 いや、まあ一人で作ってるうちはかまわんけど
仕様変更も少ないだろうし nameA=カツオ
ageA=12
speedA=3
nameB=ワカメ
ageB=10
speedA=1
time=0
name=カツオ
if(name==カツオ)
speed=speedA
else
speed=speedB
walk_distance=speed×1
time=1 >>13
あれに突っ込み入れてた連中もニワカなんだよ
副作用について何もわかってない >>3
ハードウェア制約がきつくてパフォーマンス重視の要件で oop は採らんだろ
ps2ぐらいから oop 主流？ マジで常々思う
誰でも読めるソースが第一だと思うんだよな プログラミングのクラスに関しては英語圏特有のネーミングセンスの弊害的産物で在って
本来はルーチンの類に含められるべき 1つのクラスに売上処理とか仕入処理とかごっちゃになってたらわけわからんやん 関数の亜種みたいなもんだろ
使えれば便利な場面もあるけど使えないなら使えないなりのやり方もある //おにいちゃん…キスしていい…？///////// ラムダ式なんか関数に関数を詰め込むのを許可してるようなもんだし
クラスとの境がようわかんなくなった 俺もにわかだけどVBAのsubとfunctionなんで一緒にしねーのかと思った
あと配列を定数に出来ないのが納得いかん クラスはメソッドだけじゃなくて、プロパティもあるんやで
ていうかプロパティにメソッドが付いてるイメージ
アルゴリズムにデータを渡すのではなく、
データにアルゴリズムを持たせて、データの振る舞いはデータに聞け、ってイメージ ヒューマンリソースマシーンやったら、高級言語の有りがたさが、痛いくらい解ると思うのw なんでもいいからさっさとキチガイ大出品して死ね新宿古着屋ワタナベダイバクショウ クラス何ていらねーよ。何でいっぱつでアクセスできるのに何十もの関数通さないと出来ないのが意味不明、おなに言語 大規模システムで固定変動設計しようとするとあった方が楽という程度 >>36
このイメージは的確だな
この考え方で設計するとクラスが綺麗にまとまる まぁ、ポリモーフィズムの恩恵に浴さないと、oop の良さはわからんわなぁ カーゴカルトプログラミング
実際の目的には役に立たないコードやプログラム構造を儀式的に含めておくプログラミングのスタイルである。
カーゴ・カルト・プログラミングは主に、プログラマが解決しようとしているバグか解決策のいずれかかまたは両方を理解していない場合に見受けられる。
他にも、スキルの低い、ないし新人プログラマが、そのコードが何をしているか理解が足りないまま、またはもしかしたら新しい場所にも必要なのではないかと、別の場所から関係ない部分も含めてコードをコピーしてしまうことで発生する可能性がある。 カーゴ・カルトという語句は、元々は第二次世界大戦後の南太平洋で見られた先住民の宗教に由来している。
これらの人々は、戦時中素晴らしい積荷をもたらしてくれた神のような飛行機を呼び出そうと、一心不乱に精巧な飛行機の模型や滑走路を作り上げた。
コンピュータプログラミングにおいてこの語句が使用されるようになったのは、
おそらくリチャード・P・ファインマンのカーゴ・カルト・サイエンスから派生したものと考えられる クラスが分からない人は
構造体を配列化してみるとよい
あーら不思議、クラスっぽく使えてしまう >>1
文字数多い方が儲かるからな
ドカタはスキあらば値段釣り上げようとする意地汚い連中だよ
わかりやすければなんだって良いよ >>56
それやってからそのまんまクラスに変更したら動かなくてビビったわ インスタンスを複数作る必要がある場合と、機能間でのデータの受け渡しをする場合に最低必要だろ >>54
if ("true" === "true") {
return false;
}
なんだよこのコード・・ まあ、>>1の言ってることも解らんでもない。
小難しいことはコンピュータが勝手にやってくれればいいのに、
なんのためのコンピュータなんだよとは思う。 Excelの関数20個くらい使えるレベルなんだがアンドロイドで簡単なツール作るとしたら何の言語覚えればいい？ 30歳でプログラミング学びました。アプリ作って稼ぎます
って言語を舐めてるw クラスは便利だぞ、元のクラスを変更すればそれを使ってる派生クラスが全部変更されるからな。
クラスがないと、いちいち全部を変更しなければならない。 発想の原点はLOGOの亀
亀に移動や描画を命令する
その方法を一般化して
あらゆるオブジェクトを亀みたいにしちゃおう
これがオブジェクト指向プログラミングです(適当) >>65
エンタメアプリなんて、動けば良いやってなもんだから
5000時間もかければそれなりのもん出来んじゃね？
本気でやればね。
まぁエンタメはグラフィックのセンスないときびしいがな 広告がうざいゲームはマジクソ
すぐに消すからもう作るな よく分かんねーよ
具体的に教えてくれヨ
クラスにする理由しない理由 >>70
まあ「構造体に関数のポインターを用意して」でも出来るけど、
これをやると超醜くて、追いかけにくいプログラムになる。決してやるな。 プログラム作成も初期は、データ構造と処理関数の
分類だった。ただしプログラムの規模がデカくなると
バカが多くて管理出来ない状況になったんだよ >>75
サンクス
ちょっとしたツールだから勉強してみる 結局クラス使うのは名前衝突避けるためってのが一番の理由でオッケー？ クラスはなぁ。便利だけとメモリーのリークが怖い。パソコンソフトならいいけど、高信頼の組み込みじゃつかわらいなぁ。 学校のクラスと同じなんだって。
文系と理系はクラスが違うだろ？履修する教科も違えばセンコーも違うし、それぞれが使う教科書も違う訳だ。
じゃあクラスを分けて管理したほうが楽だろう？そういうことだよ。 >>73
うーん、自分も正確なことをいえるか難しいが、
オブジェクト指向をフルに活用するにはクラスが必要なんや
例えばあらゆる機能で使うような処理を静的な関数としてもっておいた場合、
その関数を変更した時あらゆる機能のコードに多大な影響が生まれ著しく保守性が悪い
また、大部分は共通しているが微妙に異なる処理をしたい場合、条件分岐が複雑になりコードの見通しが悪くなる
一方、共通している部分を基底クラスとして作り、それぞれの機能の実装は継承先に委ねておくと、
一つの機能を変更した時に変更するクラスは継承先のサブクラスだけで良くなる
クラスの理想はそのクラスの中身を利用者が知らなくても安全に簡単に使えることだ
エクセルのVLOOKUP関数は引数だけ正確にいれれば利用でき、
セルの値を指定範囲の中で検索するアルゴリズムなどユーザーは全く知る必要がないがあんなのを自分はイメージしてる
オブジェクト指向の実装方法はデザインパターンやSOLID原則を参考にすると分かりやすい
自分もマスターしてるわけではないので偉そうなことはいえないが >>74
それを駆使して、ただのCでC++的なことをするのが昔流行った
会社でやらされたけどクソみたいなトレンドだった
誰だよあんなの流行らせたの・・・・ >>79
お題目的には再利用性が主眼だと思うんだな
名前空間はクラスじゃなくても実現できるし 俺もクラスの概念がわかってない
全て関数で対応してるわ
一人で作って一人で管理してるから
今のところこれで問題ないし新たに覚えるつもりもない >>1
ていうか関数もいらないよ
ロード/ストア命令と四則演算、条件ブランチ命令だけでプログラミングできるよ 大事なのはグラフィック
ここで詰んだ
ゲーム作れない >>84
そうだよね。インスタンスが並列になるから、状態もデータも並列管理ができる。 機種の基本設計に対して機種固有の変動部分の対応をするときに
オーバーライドして置き換えれるので機種展開はしやすいな クラスも関数も管理してないとゴミになる
忙しくなると似たようなもんが増殖していく >>88
インスタンスの並列だけじゃなく、
インスタンスの並列を横の再利用とするなら
継承やポリモーフィズムという仕組みは設計の再利用として
縦の再利用性を目的としている クラスを鯛焼き製造で例えられてもなんのこっちゃわからん。もっとわかりやすく解説してみろ >>73
一連の動きをする命令に汎用性を持たせるって言えばいいのかな
基本は同じ動きでプロパティで内容を帰る
それを何層にも出来るから一つのクラスが
値を自由に付ける事の出来る関数のように使える 必要かどうかは、プラットフォームやフレームワークや規模によるよ
AndroidやMFCやらでAPIがクラスを前提とするし、ユーザーコードも規模が大きくなってくるとクラス等のOOP的な仕組みのありがたみがわかる これから泥やるんたらコトリンだよな
javaなんていうクソ言語は捨てておしまいなさい >>82
>>95
なかなか難しいね・・
ありがとう クラス内が独立してるからグローバル変数モドキとか何も考えずに脳死状態で作れて楽ちんなんや
依存関係の有るサブルーチンとかも内部関数として持たせとけばいちいち覚えとかんでもええんや
優秀な人はクラス活かしてより高度な事してるのかもしれんが
俺みたいなのは自分がどんどん馬鹿になってるなーと思ってるぞ、でも楽だからやめられぬ >>102
ファイルダイアログを立ち上げて「選択されたファイルを読み込む」
例えばこんな動作があったとして抽象クラスとしてファイルを選択するコードは実装しておき、
ファイルを読み込む部分は抽象メソッドにしておく
実際に読み込むファイルはエクセルやcsvやXML,JSONかもしれない
ファイルの種類によってどうやって読み込むかは抽象クラスを継承したクラスで
抽象メソッドをオーバーライドして書けばいろいろなファイルに対応できる
それにエクセルファイルの読み込みメソッドを変更しても、XML読み込みメソッドには何の影響もない クラス知らなくてもいいんじゃん。君はその程度だから。 >>105
誰がハゲじゃボケ
美少女クラスはアブストラクトクラスにするか、コンクリートクラスするか、から検討しやがれクソハゲ！ >>91
うまいこと言うねw
たしかに、クラスは本来的にはそれが主目的なのかもね。
ただ、モデリングする時に、そのソフトウェアでどこまできっちり縦の再利用性を求めて設計するか、というところもあるよね。
ソフトウェアの目的に応じてイベントドリブンな関数志向やアスペクト志向という手もあるし、オブジェクト志向がいついかなる時でも正義というわけではないけど、とにかく、便利だよねw >>1
知ってへんと、他の人のプログラムいじられへんやん >>1
殴り書きの走り書きでいいシステムならいらない
ライブラリなんかを作って提供する立場になったら必要性が分かる
人がごちゃごちゃ使う事を想定して設計するにはベターなんだよ 本やWebを見ると車や動物が例えに出てくるんだがピンとこない
唐突にインヘリタンスとか持ち出すのもイラっとくる
こんなレベルでAndroidのアプリ作ったことがあるが脳死寸前だった 子供から論理的思考が身についてしまう。。俺の馬鹿さ加減がバレる。。。やめろ。やめろ。 >>112
ざっくり言うと二次元から三次元になったみたいなもん
考えが立体的 >>18
その関数を再利用とかしないのなら別に関数でもかまわん。
関数を再利用したり、その関数を少し変えただけの関数をいくつも使うのならクラスを使えばいい。 ポリモーフィズムやカプセル化を簡単に使いたくなったときに使えばいい にわかプログラミング程度でクラスなんか必要無いだろｗ
昔みたいにMFCとか使うわけじゃなけりゃ、よっぽど複雑でめんどくさい
プログラム組む時以外、普通はクラスなんかいらんわｗ 生産性が違うだろ。
言語にやらしたほうが安価に実装できる。 自分用にVBA勉強したときにネットのサンプル見てパクってクラス使ってみたけど丸写しでよく分からず終わった >>112
動物とかの例はよくない。
コードを見て書いて理解すべき。 >>61
画面下にあるjqueryってことはクライアント側か・・
確かにやべぇな ファミコン時代のプログラマーって
どういう思考でプログラム組んでたんかな？ >>121
これな
未だに車のパーツとか動物とか絶望するわｗ
車で例えたいならせめてユースケースだわ >>124
使えるなら言語はあまり関係ないと思うが
そう考える理由はなんだい？ >>125
当時はまともなC言語すら無くてゲーム機はマシン語が主流だったんで
頭の中がCPUと化してて、ニーモニック（16進数のコマンド）だいたい暗記ｗ >>73
ベースとなる処理があって、異なる2つの処理を付け加え、2種類のベース処理を作るとしよう。
オブジェクト指向でなければ、ベースの処理に異となる2種類の処理を付け加える。
オブジェクト指向なら、ベース処理に対して2つの差分部分だけ書けばいい。 >>128
あの頃の人達は機械と直接お話できたんだな >>125
CPUが今何をしてるかって完全に把握してプログラム出来るからむしろわかりやすいぞ そういう馬鹿がいるので再生産性とかデバッグが大変になる、プログラマにならなくて良かった クラスのメンバーAをプライベートにして
パブリックなsetA、getAを作る意味は有るんかえ。 >>134
クラスのメンバーへのアクセス経路を統一して不正な値への変更不可としたり、
値が変えられたときにそれを通知することができる
最初からAがpublicだと他から好き勝手に変えられて、
クラスのメソッドでメンバーを利用する際のバグになり得る >>134
あとからset「あ、これ代入されるときに範囲オーバーみとこ」とか、
get「あ、これ値返すときにアレ判断してコレ返しとこ」ってのを
急な仕様変更なんかで付け足すときに手間がはぶける。
あとpublicなメンバにしとくと、多人数で作るときに、いついかなるときに
勝手に中身変えられて想定外の値入れられても、publicにした以上は文句言えない
一人で全部作る分にはどうでもいいかもね >>134
観点の違いだね
システム全体を管理するなら必要
開発でもテストでもトラブルでも代入を検出するより呼ばれたメソッドを追う方がいい
さらに思わぬ汚染は絶対ゼロである状態が担保されたい
一人で学習してるならいらん
他にも理由があった気がするけど忘れた >>134
どこの馬の骨とも分からない人がクラスのメンバー勝手にチェンジして、ヤバい奴等だらけになりかねないから >>136
A=不正な値
とするか
setA(不正な値)
とするかの違いにしか思えないんだけど。。。
昔から、脅威のハッカーを心配してるのか？と疑問に思ってました。
煽りではなく。 >>131
プロ将棋士の頭の中に盤があるみたいな感じで、頭の中にCPUとメモリがあったｗ
当時は8bit CPUだったんでそれが可能だったけど、16bit CPU以降は頭の中が
飽和状態になるんで C言語に頼らざるを得なくなり、OSみたいな大規模開発では
C言語ですら飽和状態になるんで、高速化と実行効率化を犠牲にしてクラスという
メンテナンス性の高い実装手法が産まれた
このクラスは当時異常に肥大化し複雑化したOS（WindowsやMacOS）を使うためには
必須の技術となり、その効果は凄まじく開発効率が大幅にアップした
でも最近はプログラム自体が簡易化されてるんで、大規模開発以外はあんま必要
無いんよねｗ
なので、（最近はあんま見かけないけど）たまに何でもかんでもクラスにしてしまう
プログラマとか見ると、あーあって思うｗ >>134
お前の財布Aはお前がget/setしたいだろ？
他人にされたいか？ >>137
setter,getterにさせちゃ、影響範囲大きすぎないだろうか。。。 >>134
家に出入りするのに玄関ではなく、窓から入られたら困るやろ
データaをアクセスする方法を統一することで、変なアクセス方法を防ぐ >>139
どこの馬がGetterに、なにか仕込むのがオチかと。 >>134
フィールド1個ずつにgetter、setterを用意するのってそもそもオブジェクト指向的に設計がおかしいと思うんだよね >>142
逆に言うと、財布が札を食べに来て、オエッと吐き出す絵しか浮かばないよ。 >>144
下品な言い方すると、肛門は1つしか無いってことかなぁ。
場合によっちゃ致命傷に、なることもないかなぁ。 >>140
set A(不正な値)
にした時にset の処理に不正な値だったら例外投げるようにしとけばいいし、
クラスにバリデーション用のメンバー持たせといて不正な値がきたら、
バリデーション用ののメンバーに不正の種類と値をもたせといて
バリデーション用のメンバーに何も入ってない時にメソッド実行可能とかにしとけばいい
A=不正な値やったら素通りだから、何かしら対策が立てられるのが重要なんや 最近は使わないけど、宗教に近いものがある
でも、悪くはないよ。 >>150
逆に、「getterに余計な処理書くな」とか「チェックはチェックって名前でやれ」とか
言わない？ >>147
基底のクラスに名前も引数に与えるメソッド作ったら2つで終いやろ
下位クラスオンリーや例外やスペシャルなプロパティは独自メソッド用意したらいい 個人的には、単なるsetgetの機能実装時点ではありがたみを感じたことはない
デバッグのログ吐き出しだったり、設定変化に連動する処理を追加したいケースにおいては、価値を感じた バッチ処理とかやってる分にはほとんど活かせないよな
それより関数型プログラミング的な考え方のほうが役立つかも 大体インスタントの初回生成時から変更するようなフィールドって1/3にも満たないと思うし
値を取得するのにも連想配列的な使い勝手の方がいい場合が多い >>153
入力値検証が余計な処理とか言うやつはさすがにヤバい
それにその辺の似たような処理の実装を省力化するヘルパークラス作ったり、
それ用のライブラリがあったりする 学習本の良くないのはいきなりオブジェクトの詳細の説明から入るからな
車の例とか出して
理解においては、あれは後付みたいなもんで
そもそもは実用の観点からこうなってた方がいいってのが実際
ゲッターセッターみたいに何でって？そりゃなるわ
実用の観点から捉えないと意味不明だと思う
例外は極力排除したい、ゼロイチどっちかに寄せたい、ルールを遵守すべきとかの考え方がベースにあってクラスの有り難みがわかる
つまり初学者本を書いてるやつがバカ というか最終的なアウトプットで出力するもの意外をgetする必要ってあんまないし
個別の操作って継承クラスの中で閉じてても大体問題ないんだよね >>158
Viewとの連携とか、フレームワークのルールでは生きますな。
と思ったけど、最初からルールが違えばやっぱり要らないような。。。 >>1
俺と同じだ。
職業プログラマーじゃねーんだから。
VB6復活キボンヌ。 昔々、まだ C++ があまり使われず、 C が主流だったころ。
「グローバル変数は管理しにくいからできるだけ使うな」と、ことあるごとに主張していたのだが
なかなか賛同されなかった。
現在、 C++ ではグローバル変数はほとんど使われなくなっている。
しかし、クラスのメンバ変数の乱用で、結局似たような状況になっている。
「メンバ変数は管理しにくいからできるだけ使うな」と主張しているが、
なかなか賛同されない。
ちなみに、そのおかげで私の書くコードは引数だらけとなる。
理想と現実のバランスが必要だ。 >>163
メンバ変数もいいけど、クラスの中にあらゆる処理突っ込んじゃうと
結局グローバル変数と変わんなくなるよねｗ
なんというか結局、クラス使っても書く人の能力次第でしかないというｗ >>159
その通り。
ずっとCで書いていて、最初は車とかの説明が書いてあった本を読んだ。
初心者があの説明でわかるはずがない。
理解するにはコードを読め。
簡単なソースを1ステップごと実行させて、何をやっているか調べれば理解できる。 >>164
Cの時代に1ファイルになんでもかんでも突っ込んできた人にその傾向がある
もともとファイルを分けて実装してきた人は、クラスをうまく使える印象 PHPとJavaとJavascriptの勉強をやってみたが、すぐ忘れてしまうわ。 >>75
xamarinも忘れんといて
c#の知識だけでandroidと遊べて幸せや 構造化
int Add3( int x, int y, int z){
return (x + y + z);
}
int main(){
return Add3(3, 5, 8);
}
オブジェクト
Public class Add3{
public int x;
public int y ;
public int z;
public int execute() {
return (x + y + z);
}
}
int main(){
Add3 add3 = new Add3();
add3.x = 3;
add3.y = 5;
add3.z = 8;
return add.3.execute;
} >>172
フィールド変数はプライベート原則
メソッド実行は（）つけろ >>173-174
出てきたw
じゃあ、これでダメな理由をこのクラスを使って具体的に言ってみろw
コードの書き方に感じを書いただけだw >>172-175
簡単なプログラムだったら構造化で十分ということがよく分かった。 クラスじゃなくて、そこからの変数であるインスタンスという概念が大事なんだが >>170
PHPは、perlやrubyに比べて、データベース使ったWebプログラムを組みやすい気がする。
もうプログラミングなんて、10年以上やってないが・・・ >>175
この例だとクラスをインスタンス化する必要もメンバ変数で保持する必要もないから、
静的クラス静的メンバでメソッドコンテナにするべきじゃね？
Mathクラスみたいな感じで。 >>180
インスタンス化する必要かどうかなんて設計の話だよ。
servlet の様に一つのプロセスに複数スレッドで動かす場合だと、静的か動的生成で結果が変わってしまう場合もある。 c++11をチームで使うことになってるのにnewとポインタ渡し大好きでいくら言っても使い続ける人がいて困ってる
ちなみに研究職だから開発に渡すには短く分かりやすいコードの方がいいんだがコンパイラの最適化がーって譲らない 美少女クラスも俺と同じ排便メソッド継承してるかと思うと胸熱だわ。 public class BiSyoujyo : Syoujyo
{
override public Unko
Haiben ()
{
// return new Unko(Unko.Type.Normal);
// return new Unko(Unko.Type.Gold); // 価値を付ける場合はこちら
// △月△日：仕様変更：美少女はうんこ出さない
// return null;
// ●月〇日：ミーティングでnullでなくType.Ghostになった
return new Unko(Unko.Type.Ghost);
}
} >>123
某所でちょっと話題になった糞コード
1500人程度のユーザのいるサービスだったらしい
イントラネットとかクローズドな環境だったので長らく問題が顕在化しなかったのではという見解 オーバロードオーバライドしないなら何が書いてあってもいいけどな
とは言ってもC++のclassとstructの違いがわからない奴が多くて嫌だ 構造体はただの変数で寿命はスコープによる
インスタンスは寿命をプログラマが制御する クラスやオブジェクト指向は鶏卵だろ
開発や運用の過程でこうなってたら使いやすいって経験を言語仕様化した訳だ
だから初学者にいきなり教えたってその経緯分からんから常に>>1の様な疑問を持たれる
細かい屁理屈並べるより単なるルールとか言っといた方がマシ いや、俺はC/Objective-Cの話をしてる
マイナーですまんねw
C++の構造体ってnewするんだっけ？ >>172
executeがダサいと思いました
runの方がカッコいいと思います クラスってコンセプトは継承とインスタンス化じゃね？ C++の違いは基本暗黙の宣言がprivateかpublicなだけ
structはclassと同じでありc++において構造体と呼ぶのも気が引ける 別に無くても同様のことは実現できる
継承やインスタンス化もそう
じゃー何で存在するか
あった方が便利だから設計実装されてるだけ
単なる整理整頓管理のし易さだけ
プログラミングなんて大半がアホみたいな整理整頓とその保全だね
こんな理由なのに初学者の敷居を上げてしまうのはいけない
ちゃんとまずは別にいらねーよ、知らなくても問題ない事を教えてあげないと プログラミングパラダイムって、究極にはコード自体をどう構造化するかって事だ 他人が作った機能を使い回すのに必要
クラスなんか必要ないって言うやつは必ずボッチ javaから勉強しはじめたからクラスがあるのは当たり前って感覚なんだけど
どのクラスに何を入れるかでいつも悩んで結局網の目状になっちゃうわ
できれば魚の骨みたくメインのクラスを軸にして他のクラスはそのメインだけに繋がるようにしたいんだが・・・ >>18
関数をまとめた構造体を作って、云々。Cで組み込みやるときは記述がだるいけど、必要に応じて。
抽象化なんてアセンブラの時代から必要かつ意識高い系はなんらかやってたわけで。 関数の数が増えてくると自然にクラスを使うようになるぞ 増えすぎたプログラマをふるい落として
単価上げるためだけに複雑化してる
って白状してるからな。 >>209
図星付かれて言い返せないんだよ、ダサいよね >>205
メインのクラスとか考えると手続き型を分割しただけになるから細部から考えたほうがええで。オブジェクト指向エクササイズとかで少し大きめのプログラム書いて見たらええ。
関数型の世界だとクラス/オブジェクトみたいなステートフルなのは好まれない雰囲気もあるし、OOP捨ててコード組めるぐらいの実力ないと今後は辛そうねぇ。 クラスは必要だ。
ふつうにプログラムしてればたどり着く考え。
たとえば、aという変数もグローバルだと衝突してしまうが。
あるまとまり(クラス)の中だけで通用するようにするなど。 とりあえず何でもブチ込める神クラスを作ります（生え抜きのC書き） 一時期オブジェクト指向オブジェクト指向ってうるさかったけどあれ今もあるの？
web2.0とかもうるさかったな オブジェクト指向に少なくとも2通りはあって。
C++のはクラス型で。Javascriptのはプロトタイプ型。
Javascriptの方がある意味徹底されてるという認識。最初からすべてがオブジェクトで。
C++だとオブジェクトはプログラマーが明示したときだけ。 >>215
ポインタ勉強しろよ、自分で寿命って言ってるのに分からんとかw >>215
構造体だってアロケーションできるって話だよ
構造体の真価はそういう事じゃなくてbit単位で通信するデータをブロック化できるってところだと思うんだがね >>218
>>219
そりゃ構造体だろうがなんだろうがヒープに確保できるがなw
実際そうやってCでクラス実現したのがObjCだw
ポインタとかそういうレベルの話をしてるんじゃないw クラスってコンセプトのカナメは継承とインスタンス化だろうと言ってる なんでその言語仕様が生まれたのか？
そのほうが便利だから
では、それはどういった点で便利だからなのか？
みたいな逆算より、普通にCからやったほうがいいのは、その不便さを身を持って体感できるから おれはお前らが嫌いなニッカポッカ土木作業員だけど昼休みにオブジェクト指向の本を読んでいる。
クラスが必要か？関数でいいじゃん？
クラスの理解の前に、関数の理解をしようぜ。おそらくお前はそこを理解出来てないと思う。
関数の役割としては、処理の共通化が挙げられるよな？そこは分かってるはず。
そしてその関数を呼ぶ側が引数を渡して（引数があれば）結果を得る。
問題はこの時に「関数を使う側」が引数に渡す値を用意する部分。ここにクラスを使うための答えの1つがあると俺は理解した。
お前も考えてみてくれ、問題を理解しないと解決策であるクラスは理解できないぜ 60年代ぐらいにプログラムが肥大化したときに、どう解決しようとしたかなんだよな
OOPも構造化も関数型もその頃に生まれたコンセプト >>214
それっぽいものを作る人、何十人か知ってます この世界がオブジェクト指向で出来てる以上、クラスは必要だわ。 >>220
objective-cの事言ってるんなら全然別もんだろあれは >>229
寿命は寿命だよ
mallocからfreeまでだが プログラミングが簡単単純になるから
気に入らないならすべて機械語で自分でコーディングすればなんでもできるぞｗ クラスってのは「分類」だよ
なんの分類かというと、クラスの要素である変数とメソッド
変数とメソッドはデータと処理だ
プログラムやシステムというのはデータと処理の集合な訳で、これが肥大化したときにどのようにモジュールとして分割するか？というのが大きなテーマになってくる。一度に全てを見渡す事ができないからね
このモジュール分割や分類というのが厄介で、理路整然と体系化された分類もできるし、
複雑で例外だらけの分類もできるわけだ
そこでシステム化対象領域の「モノ」=「オブジェクト」と、その関係に着目して分類をすると割と体系的な分類ができますよ、というのがオブジェクト指向設計 >>230
構造体使うのにわざわざそんなことやってんのか？ 組み込みとかローレベルな通信のプログラミングをしない限り構造体の意義は多分分からないと思うよ >>191
構造体でもポインタにNULLぶち込めば殺せるし、
プログラマが制御できるじゃん >>237
freeしなきゃポインタにNULL入れても確保されたままだぞ クラスはとても難しい概念なんだ。理解できる人を選ぶ。素人さんが生齧りでやらないほうがいい。
プログラミングのことはプログラミング屋さんに任せないってこった。 なんかクラスを使わないとマルチスレッドのプログラミングが大変だった記憶 >>243
C#でやれば楽だけどね
まぁそういう話じゃないんだろうけど 俺の親父huge始めてるけどめっちゃいいclassしてるわ >>240
>191 名前：名無しさん＠涙目です。(やわらか銀行) [US] ▽2件 投稿日：2018/08/21(火) 03:27:19.34 ID:v1/Jj0sb0
>構造体はただの変数で寿命はスコープによる
>インスタンスは寿命をプログラマが制御する
なんで変数の話してんのにfreeがでてくんの？
逆にいえばインスタンスだって寿命は最大でもインスタンス変数のスコープの範囲内じゃないの？ >>247
簡単に言っただけだぞアスペかよ
あとインスタンス変数の使い方間違ってないか？ クラスの概念は普通の人には何がなんだか考えも及ばないものなんだよ。プログラマーはクラスを理解するために、10年はクラスのないc言語とかで修行しなければいけない。
とりあえずプログラミングをやってみたいなーなんていう素人さん以外はクラスに携わっちゃいけないよ。 にわかなのに関数とかいう単語を知ってるとは
クラスは関数ポインタ(メソッド)の構造体と考えればいい 情報をまとめる時にクラスって概念を使う
CADにもクラスあるだろ 今、golangやってるが、なんでポインタ復活させたんだｗ
>>254
これやな100行くらいの一回通すだけのものならいらんかも クラスAでクラスBを呼び出す
こんなプログラムを作っていて、あるとき
クラスAの中で作ったクラスBでクラスAを呼び出す必要が出てきた
これが可能なのだがなぜ可能なのかわからん
例えばc#
Form_mainの中でForm_subのインスタンスを作ったのだが、
Form_sub fm = new Form_sub(Form_main);
なんでこれができるの？ >>125
シングルタスクちうて、「処理の途中でOSに処理を返す」と言う概念が根本的に無かった、始まったら全部俺のターン
ただ普通に「イベントでの司会進行」みたいに考えられるから、今よりは理解はしやすい、その後は複雑だけど
つまり、ファミコンのキャラを動かす部分はOSが受け持つ感じになって、そこだけ聞くと楽になったん？って気もするのだが
そうでもない
クラスは、専用変数＋汎用関数のセットだっけ
ゲームキャラ一体に一つのクラス、でも「プログラム部分は共有出来る」から、効率化と汎用性が高まるが
何か机上の理想論なんだよなあ(+_+) >>185
Public Class 美少女
Public Overrides Sub 排便
肛門.排出.ファンタジー
End Sub >>264
言語によるが、或いは「キャラは番号で呼んではいけないが、゛同じキャラ゛なら番号で呼んで良い」みたいなルールがクラスにはあって
それがどうにも馴染めなかった思い出がある。敵は全部で1000体まで出せます
ではなく、敵Ａは200体まで、敵Ｂは1000体まで、弾Ｃは300体まで、みたいな組み方を強いられてしまい
つまり出現してない時、敵の保持領域には゛かなりの無駄がある゛事に
そういう話が動物がどうたらみたいな説明になるのかね >>50
バグの有無とか性能は
コンパイルしたら一緒という事にはならない >>134
Aの上限値がオブジェクトによって違うような場合
（デフォルトでは上限値がなくていちいちチェックしないような場合） >>8
最初のボンバーマンは確かMZ-700版だと思った >>191
構造体へのポインタをグローバル変数にして
構造体の実態メモリを確保したり解放したりしたら
構造体の寿命をコントロールできるんじゃね 構造体は宣言順にデータが列んでるっていう性質が重要なんだがな >>7
多分、peek pookだけで アセンブルされたマシン語の書き込み・読み出し位置の部分だけだと思うぞ。 小規模だったらクラスとか要らん
でも拡大させるベースだったら
あなたは役所
あなたは車屋さん
あなたは衛生局と
役割を細分化して
直感的に再利用でくるような
組織体系になってないと
その度に車の発明から定義していかないとあかぬ クラスの超！目的は変数のカプセル化だからな
ほんとほっとくとグローバル変数だらけにするバカがほとんどだから >>134
脳死でアクセサを作ると、
インスタンスフィールドをpublicにするのと何も変わらん
アクセサは必要に応じて作れ
コピペで使いもしないアクセサ作るな、バグの原因だ >>156
オブジェクト指向ではインスタンスがメソッドと共に状態を持つのが特徴
一方、バッチ処理は普通状態を持たない
だからバッチ処理でオブジェクト指向のありがたみを感じない
という感覚は正常だと思う
構造型プログラミングでいいだろって話になる >>163
クラス内でしか使わない処理なら、
privateでstaticなメソッドをガンガン作って、
インスタンスフィールドも引数で渡してやる、というやり方に賛同する
引数だらけ？
問題だと思わないね
それよりグローバル変数に近い邪悪さをもつ
フィールドをクラス中でドンドン参照してしまうほうが悪
結局自分の知らんところで値が変わってたりとかもうね >>83
未だにLinuxドライバとかでは現役バリバリの設計手法だけどな。
と言うかインターフェイスとして決められてる。 >>194
Cからこの業界に入ってJavaやったんだが、
「ああ、Cのような構造化プログラミングの限界を突破するために
こういう考え方を導入したのか」
とわかるようになった。
初学者には演繹法より帰納法のほうが学習効果が高いと思う。
「とにかくJavaではこう書くんだよ」程度で最初はOK
いきなり「哺乳類クラスを犬クラスが継承して・・・」なんて話しても混乱するだけ。
単体レベルから開発に携わって、
だんだんシステムになれてくると、
「ああ、だからオブジェクト指向って必要なのか」とじわじわわかってくる
初学者用の小さなプログラムでオブジェクト指向もどきやっても、
「 >>205
>>212も書いているけど、「メインのクラス」という発想自体が
オブジェクト指向と合わないかな
クラスはそれぞれ独立していて結合が疎、
必要な時だけつなげる（インスタンスを作る）という発想かな
例えていうならホストコンピュータの世界からインターネットの世界に飛び出せってことだな
メインのいない世界 >>276
コンパイラとCPUの組み合わせでは一意だよ
でなきゃ何のためにビットフィールドとか共用体があると思ってるんだよ？ >>276
アライメント値によって隙間空くことはあっても順序は変わらんよ クラスと構造体は仕様上たまたま構成要素が似てるってだけで用途とかコンセプトは全く別 >>284-285に答えが書いてあるのに一切理解できてなくてワロタ >>1
必要なきゃ使わなきゃいいだろ
わざわざスレ立てんなカス >>288
コンパイラとCPUの組み合わせ → エンディアンを参照
アライメント値によって隙間空く → パディング・処理効率を参照
簡単に言うと、こんな感じだと思う(うろ覚え) そう言えばC#だと、なんかおまじないを付けないと構造体のメンバーの配置が固定されなかったような…
構造体の定義の頭に[なんちゃらシーケンシャル]って感じでやってた覚えがあるな ググったら出てきたから書いとくわ
C#は[StructLayout(LayoutKind.Sequential)]を付けると順序が変わらなくなる >>212>>271>>283
ありがとう
自分で見易いからメインを作って・・・と思ってたけど
たしかにそれだとメインクラスの役割分担でクラス分けしているだけで
それなら関数でもいいじゃんって話しになっちゃうもんなあ
ルールだけ覚えて本質的なことを理解してなかった
もう一度最初から勉強し直してみます オブジェクト指向を使ったベスト・プラクティスと使わなかった場合が
体感できるような良書はないかな
入門書にあるような文法説明だと結局、ありがたみがわからないし
かと言ってデザインパターン入門のような本も難しすぎた >>288
環境依存があるものに保証があるとは言わない 戻り値のある関数もいらないな
グローバル変数を使えばいいわけだし クラスはぼんやり理解できるとしてもサッパリ使い道が分からんのが「インターフェイス」だな
カプセル化に必要とか書いてあるが具体的なメリットがなんなのか理解できん みんな何の言語の話してるのかよーからんところがなんともw
Javaのインターフェースであれば、基本はクラスから機能を落としたもの、
メソッドの実装がなく、サブクラスでの実装を強いるもの
コンポーネント間の境界でよく使うもので、
お互いの実装を意識しなくて済む・・・
なんて抽象論を語っても頭に入らないだろうけどな
複数人でクラスを分担して作ってみないとわかりにくい
ただMapインターフェースとかは誰でも使う
例えば外部からデータを取り出す（そしてその外部システムは自分では触れない）ときに、
Mapが指すサブクラスがHashMapなのかTreeMapなのか意識しないといけないような状況だとして、
例えばアップデートされてて外部システムの実装が切り替わったら
自分担当のクラスのコードまでいじらなければならなくなる
引数やフィールドの型をいちいちHashMapからTreeMapに修正するのかよ？ってことも起きる
「インターフェースの向こう側で何をやってようが気にしなくていい」
クラス間の結合を疎にする、という言い方もするが、これがメリット
ただ自分一人でとか、小さなシステムを作る際にインターフェースを導入するメリットはあまりないだろう
カプセル化はどちらかというと、構造体からクラスに進化する際に強調された概念で、
インターフェースの説明の時はあまり使わない概念な気がするけども インターフェースってのはな問い合わせ窓口みたいなもんだよ
そこ自体に何かがあるわけではないね >>304
カプセル化とかオブジェクト指向は、構造体を進化させるときに発生したわけではなく、先にその概念があって適用しただけかと。
関数型プログラミングはオブジェクト指向の正当な後継である
https://qiita.com/retemo/items/d251f0b558a3ebf1d720
Smalltalk - Wikipedia
Smalltalk とオブジェクト指向
アラン・ケイが「オブジェクト指向」という言葉を創った当初は、Smalltalk システムが体現した「パーソナルコンピューティングに関わる全てを
『オブジェクト』とそれらの間で交わされる『メッセージ送信』によって表現すること」を意味していた。
しかしのちに、C++ の設計者として知られるビャーネ・ストロヴストルップが（自身、Smalltalk の影響は受けていないと主張する）C++ の設計を通じて整理し発表した
「『継承』機構と『多態性』を付加した『抽象データ型』のスーパーセット」という考え方として広く認知されるようになった（カプセル化、継承、多態性）。 プログラマ5年目程度が偉そうに講釈垂れるスレはここですか？ >>303
使い方が分かってたら実装なんてどうでもいいだろ？
そういうことだ 初学者だけど自分も>>1と同じ感覚だわ
別ファイルで変数や関数を定義してメインでインクルードして使えば同じじゃんって思う。
全部メインに書くレベルでクラスいらないってのはさすがに思わないけどクラス作ってインスタンスを作る意味が解らないわ。
インスタンスいらなくねって思うわ。 昔MS-DOSの頃にプログラマーやってた時があってC言語を使ってたが
クラスがなんなのかさっぱり分からん
構造体の中に関数が入った感じなのかな
しかもC言語すらもうほとんど忘れてる
あれだけ勉強したのに 今冷静に考えるとクラス使わずに
プログラム書ける自信全くないな。
始めた頃はベタがきでこねくり回して
必死で作ったものだが
要するにオブジェクト指向は人間の思考回路を
破壊していることになる。 ちなみにクラスも関数も所詮手段であり
目的にあらず。
だからクラス使っても使わなくても
最終的には同じ物はほぼ出来る。
ただし作ろうとしているシステム規模や
機能拡張や保守性を考えた時に、
クラスを使う使わないで雲泥の差が出るのは間違いない。 業種によるんじゃないかな、パフォーマンスが要求されてる場面でクラス化するのもアホだし、UI作るのにクラスなしでは辛過ぎるし、ただしoop厨は総じてうざい クラスなしだと処理が無駄に複雑になる。
STLとかに慣れたあとCで文字列やらlistやらmapやら使うの大変だし、あとスマートポインタとか、クラスがないと実現出来ないんじゃない？
I/Fが同じで、処理もほとんど同じ関数とかの場合、基底クラスが使えんから最初の何バイトまではデータ構造が同じといった構造体使ったりせにゃならんし…。 STLは、クラスやテンプレートが使用され作られているが。
そもそも、STLを実装するためにC++が作られたようなもので。
だが、STLを使用することでクラスが使いこなせたり、理解できるわけではないかと。
スクリプト言語とかも実装でクラスやテンプレートで使われていても、利用時にはそうでもない。 >>278
バッチ処理でも状態は考慮することあるんじゃね
開始時刻になったとき
処理を開始できる状態になっているか判別してからじゃないと不整合が起きそう >>285
バイトオーダが変わる事があると思うけど お前らすぐ早口でディテールの議論するよな
このスレのテーマは初学者だろ
お前らだって経験の背景があってクラスやOOPの恩恵を理解したくせに
そうやって初学者にプレッシャーかけて喜んでんだよね
初学者はそんな機能「も」あるって理解で十分
そもそも言語なんて機能を提供してるだけで使い方は自由
クラスなんて最初はグルーピング用途で使っといていいよ ちゃんとカプセル化してあるクラスだったら
それを再利用できるのがメリットなんじゃね？
継承して一部メソッドを上書きしたり拡張したり
使う側はインターフェースを知ってれば
機能を提供する側のクラスが
別のクラスに置き換えたって構わない >>320
言語とオブジェクト指向は別の概念じゃね？
オブジェクト指向の概念を取り入れた言語とか
そうじゃない言語とかあるわけで >>322
ああ全ての言語がOOP的機能持ってるわけじゃないな
でもどうせそんな機能を求めてしまうだろ
開発運用するならクラス型OOPが結局我々は取り扱いやすいのだろう
JavaScriptなんていい例で
非クラス型でもパターンやルールでそんな風に取り扱うのが主流だし カプセル化って結局、そのクラスがどんなメソッドを公開してるのかは
そのクラスの実装部分を読まないと分からないから意味なくね？ C/C++に触れる何年も前から
構造化BASICとか意識してたから
クラス無くても書けなくはないけど
やっぱりあった方が楽だよ カプセル化は作ってる側にとっては意味あるだろ? 利用するだけにもあるだろうが特に。
カプセル化 - Wikipedia
カプセル化（カプセルか、encapsulation）とは、オブジェクト指向を構成する概念の一つ。
オブジェクト内部のデータを隠蔽したり(データ隠蔽)、オブジェクトの振る舞いを隠蔽したり、オブジェクトの実際の型を隠蔽したりすることをいう。 >>324
それはマニュアルとか仕様書から読み取るものだろ。
Win32 APIとかリファレンス読めば使い方が書いてあるけど
ソースは公開されてないだろ(一般的には)それと一緒 >>327
とある誰でも名前を知ってるところのサービスのAPIを触ったが
マニュアルが不十分で結局ソースから読み取るしか無かったわ
他のクラスのメソッドから、おそらくこちらのクラスでも同じ名前のメソッドがあるだろうって
想像して対応したり、実はちょっと名前が違ったりで大変だった >>87
その先があるのだよ少年
データ作成のハードルもあるけど
エディターを作れなければ途中で積む 広大で全自由的であるメモリ空間に秩序をもたらすもの、それが言語仕様なのであり、クラスもまた然りなのである。
行くあても無くエントロピーを拡大せしめられるビット列を変数と関数で差別し、これらを自然発生的な秩序と呼んだ。
そして、どこからともなくやって来たクラスは、その秩序に対して序列と管理を要求し、さらに、その統治における監督官をやろう、と言い出した。
最初は誰しもが賛成という訳では無かったが、皆々、なんの気なしに動いているうちに、それが実は自分たちの世界に必要であり、それ無しではもはや戻れないところまで文明化が進んでしまっていることを敢えて議題に挙げるものすらいなくなってしまったのだ。 >>329
それはカプセル化とかオブジェクト指向とか関係なく、
そのサービスを作った連中がアホなだけ
C言語だとprintfのソースコードをいちいち見なきゃ使えないですっていっているようなもんだ
仕様見ただけでは使えないようなアホなシステム作るなやって言っとけ >>332
2Dならフリー画像はいくらでもあるし、それなりの料金でイラストを書いてくれる半プロの人もたくさんいるよ >>333
そしてエンジニア達に転機が訪れる。
ビジネスだ。
秩序によって統制され始めた世界に客をという無秩序が突如現れた。
客が吐く仕様という名の炎が世界を覆い尽くす。
そしてジリジリと焼き尽くすような炎の中で育ったレッサーエンジニアが世に放たれ、世界は混沌の只中にあるのだった。 >>310
動的なメモリ割り当てがいらないならインスタンスはいらないよ
組み込みとかそういう場合が多い
C++は使えるけど、ランタイムは無いのでそもそもnewはできませんとか >>337
あごめん、インスタンスはいらない、って表現はおかしいか
staticでないならインスタンスは必要です
メモリ上に配置しない事には使えないのだから ソースコードをより読みやすく・より保守し易くする仕組み 女がこのスレみたら全員気持ち悪！って思うだろうな
嫌われる性格を自覚しろ >>324
その為にインターフェースがあるんじゃないの このスレにあるような事祥説C++って古い本に書いてあったな。 組み込み系で２０年くらいプログラム作ってるけど、ずっとＣだけで作ってる。
メーカー付属ライブラリもＣで書いてあるし、
メモリ管理とハードアクセス、構造体と関数だけで十分だけどな。
でも、会社が傾いててヤバい。 こんな私でも何処か転職出来るだろうか？ >>345
PLCやシーケンス制御それに繋ぐセンサ等の勉強かな
それなりに需要はある 自分が理解できないからと言って
「必要ない」という結論が間違ってるだけ C言語やっててOOP分からん人は、FILE*を扱う一連の標準関数について考えてみると良いよ
あれが実ファイルでもパイプでも同じように扱えるのがオブジェクト指向的なやり方 ソースコードを見なくて済むかどうかとoopとして優れた設計かって関係ないんじゃないか？
「ソースコードが仕様書」という考えがあるようにソースを見れば仕様が容易に把握できるというのが理想的ですらある
oopの隠蔽で大事なのは、そのオブジェクトが宣言する通りの振る舞いを約束してくれることで、
オブジェクト内部で完結すべき事情をその表面にむき出しにしない事だと思うぞ >>3
これだよなあ
俺も研修受けてた時はオブジェクト指向とか理解できなかったよ >>351
grepの結果を他のコマンドに渡してあれこれしたり >>349
「FILE*をさらに抽象化してインターフェースにして、指す先が実ファイルであろうがパイプだろうが一切気にせず操作出来るようになったら素敵だと思わないか？」
こんな説明で通じるかな？
抽象概念はどうしても伝わりにくい
CとUNIXをやってる人なら、そこを説明の出発点にしてみると具体的で分かりやすいかもしれない >>351
シェルコードの流し込み実験のときに活躍するよ >>354
>>356
ぜんぜんわからん
grepはわかる >>357
マジレスすると、そっちのパイプじゃないから。 だいたいクラスって英単語の幅が広すぎなんだよな
WEBサイトで書式適用するのも「クラス」
ロープレで職業決めるときも「クラス」
プログラミングで使う目的別関数の親玉みたなのも「クラス」
しっくりくるのはRPGの職業くらい
あと分かりにくい用語が「名前空間」
空中に名前が浮かんでるシーンしか想像できない >>209
馬鹿が>>210で自演擁護w
書き込む時間ずらせよ無能www 空間をイメージすれば良いんだぜw
メモリも空間、そこの一点を指すのがポインタ >>334
まぁ世界に公開するAPIならともかく、ローカルで開発するものだと結局そこまでのマニュアルを書けずに結局内部ロジック追いかけるってよくあるよな。 そうや、名前空間とクラスって何が違うんや？って感じ >>364
それも使い方の一つでいい
きっともっとイケてる使い方すべきなのだろうと勝手に不安に思ってはいけない
開き直ってもいけないが
提供されてる機能の使い方は自由だ >>364
ああ間違った
クラスを名前空間として使ってるのかと思った
名前空間とクラスは違うね >>13
スタティックおじさん＋関数ポインタが最近の流行りだからな。 >>62
コンピュータに命令しなくても動き出したらそれはもうすでに生物だろ >>355
そうそう、そんな感じ。
っていうかもとの書き方がちと悪かったが、標準関数のFILE*は既に十分抽象化されている。
ソケットからfdopenで作り出したFILE*を与えれば、ファイルに対する入出力と同じソースコードでネットワークに対する入出力ができる。
…と思ってたが、昔の記憶なんで分からんくなってきた。正しいかな？ S： 最初はほんの冗談のつもりでね、みんながあの本を真に受けるとは思ってもみなかったんだ。
脳みそが半分でもあれば、オブジェクト指向プログラミングが非直感的で、非論理的で、非効率なことくらいはわかるよね。
I： え？
S： それに「コードの再利用性」ときたら…。どこかの会社がコードを再利用したなんて話を聞いたことがある？
I： いや、実はないんだけども、でも…。
S： ほらね。言っておくけど、はじめの頃、努力した連中がいなかったわけではないんだ。
オレゴン州の会社――確か Mentor Graphics という名前だった――が、90年か91年頃に何もかも C++ で書き直そうとしてひどい目にあったんだ。
悪いなとは思ったけど、彼らの間違いを見ればみんな気がつくだろうと思ったんだ。
I： でも気づかなかった、というわけだね。
S： まるっきりね。
問題はね、たいていの会社は大失敗を隠そうとするし、3000万ドルもの損失を株主に説明するのは至難の業だということだ。
でも彼らが偉いのは、最終的にはなんとか動いたということだね。
I： 本当に？ じゃあ、それが証拠だ、オブジェクト指向は使えるわけでしょ。
S： 使えそうなんだけどね。
実行ファイルがあまりに巨大だったんで、128MB の RAM を積んだ HP のワークステーションで読み込みに5分かかったんだ。
読み込んだら、今度は死ぬほど遅い。
実を言うと、これで策略は失敗するんじゃないか、1週間で化けの皮がはがれるんじゃないかと心配したんだけど、誰もそんなことを気にしなかったんだね。
びっくりするほど強力なマシンを Sun や HP が喜んで売ってくれて、その莫大なリソースを使って大したこともないようなプログラムを実行する、というわけだ。 I： うん、でも C++ は基本的にはしっかりした言語だと思う。
S： それ、本気で信じてるね。
実際の C++ プロジェクトの経験はある？
どうなるかって言うとね、まず第一に、いろいろワナを仕掛けてあるから、よほど小規模なプロジェクト以外は一発では動かないようになっているんだ。
たとえば演算子のオーバーロードがそうだ。
たいていの場合、プロジェクトの終わり頃にはほとんどのモジュールで演算子をオーバーロードしている。
プログラマの連中が、トレーニングコースで教わったとおりにやらなくちゃいけないと思うからだ。
つまり、1つの演算子の持つ意味が、モジュールによってまったく異なることになる。
モジュールの数が100かそこらあるときに、これをまとめあげようとしたらどうなると思う？
データ隠蔽もあるね。
モジュール間の連繋にどこかの会社が苦労しているなんて話を聞くと、笑いを抑えられないときがあるよ。
「Synergistic」という言葉は、プロジェクト管理者の胸に刺さったナイフをグリグリ回すためだけに発明されたんじゃないかと思うな。 S： そうでもない。選択の自由は誰にでもある。こんなに話が膨らむとは思わなかったんだ。
ま、いずれにしても、基本的に僕の策略は成功したんだ。
C++ は今や消え去りかけているけど、でもプログラマの給料は高いままだ。
特に、糞みたいな C++ コードをメンテナンスしなきゃならない哀れな連中はね。
大規模な C++ モジュールなんて、自分で書いたのでない限りメンテナンスできないことは理解してる？
I： どうして？
S： 現場から離れて長いんだな。typedef はわかるよね。
I： うん、もちろん。
S： RoofRaised って何だと思って、長い時間をかけてヘッダーファイルを調べてみたら、ただの double だった、なんてことがよくあったでしょ。
大規模なプロジェクトのすべてのクラスで暗黙の typedef を見つけ出すのにどれくらい時間がかかると思う？ I： 策略が成功したと判断する根拠は何かな。
S： 平均的な C プロジェクトの長さをおぼえているかな。
だいたい6ヵ月だ。
家族を抱えた人間がまともな水準の暮らしを維持するには短すぎる。
で、同じプロジェクトを C++ でやったらどうなる？
教えてあげよう。
1〜2年だ。
素晴らしいね。
たった1つの判断ミスで、安定した仕事が確保されるんだよ。
それともう一つ。
大学が C を教えなくなってからずいぶんたったから、最近ではまともな C プログラマが不足しているんだ。
特に、Unix のシステムプログラミングのわかる人間がね。
もうずっと new を使っているものだから、malloc をどう使っていいかわからないし、戻り値もチェックしないんだ。
ほとんどの C++ プログラマは戻り値を捨ててしまうんだよ。
昔懐かしい -1はどこへ行ったんだろうね。
少なくともエラーが発生したことはわかったし、throw だの catch だの try だのに悩むこともなかったんだ。 I： 悪いけど、これはとても掲載できないと思う。
S： でもこれは世紀の大スクープだよ。
僕はただ、ほかのプログラマに忘れられたくないんだ。
彼らのために僕がしたことをね。
C++ プログラマの最近の給料は知ってる？
I： 最後に聞いたところでは、本当に有能な人間の場合、1時間あたり70〜80ドルだ。
S： ほらね。
で、給料分の仕事はしているはずなんだ。僕
が C++ に仕掛けたワナを全部おぼえておくのは並大抵のことではないんだよ。
それに、さっきも言ったように、C++ プログラマというものはね、どういうわけか、どんなプロジェクトであろうと C++ のあらゆる要素を片っ端から使わなきゃいけないと信じ込んでいるんだ。
実を言うと、時々頭に来ることもあるくらいだ――僕の本来の目的にはかなうことなんだけれどね。 日本語を母国語にしているかぎりオブジェクト指向を理解するのはほぼ無理だぞ。 一視点で全体を制御できる規模ならクラス使わない方が多分スッキリする
ただ群制御などではクラス使えないと地獄を見る
極端な例だけど、複数キャラをぶつからないように動かしたいとき、指揮官的な人がAはここに動け、Bはここ、Cは…、ってやるより、それぞれのキャラが自分で周り見てぶつからないか確認しつつ動いてくれたほうが有難い(場合が往々にしてある >>362
おぉ！
ポインタってそういう意味だったのか！ みんな実践でどういう書き方してるか気になる。
クラスがない言語だってクラスっぽく書くのが普通じゃないのか？
最近C言語いじったときは文字列構造体1つ定義して、
char*やら長さやら文字列ハッシュ値をメンバ変数として持たせてた。
メンバ変数を直接いじるのは禁止で、連結(に伴うメモリ再確保とかも)とか比較とかは、メンバ関数相当の専用関数内で行う。
毎回引数でthisポインタ渡すようなイメージ。 >>382
言いたいことはわかるけど、
どうしてもそういうルールを守らない馬鹿が混ざるんで
上の方にC++の偽造コピペ貼られているけれど、
「言語仕様上、できることは何でもしてしまえ」
っていう人間はある程度混ざる
コーディング規約？何それ美味しいの？っていう人
だから言語仕様レベルで縛りを入れないとあかん 構造体のポインタを不透過型にすればいい
メンバーに参照カウントを追加してcreate,retain,releaseで寿命を制御すれば尚可 >>349
ファイルのキャッシュとかの恩恵の説明が無いと意味がわからないんじゃないかな 「継承」ってのが未だによくわからん。
いや、概念は分かるんだけど、使い所がわからんと言うか、一度も使ったこと無い・・・ >>386
同じものを２回作るのは面倒
作られた資源を再利用するような考え
しかも、序列があるので構造的に綺麗
ごめん 説明する自信ない 継承はあまり良いパターンじゃないと思うぞ
is-aよりhas-aにしたほうが良い 俺のわかりやすいポインタ
◆ポインタがない場合の荷物配送
倉庫→俺んち→転売先
◆ポインタがある場合の荷物配送
俺→倉庫に「転売先の住所（ポイント）はここ」と教える
倉庫→転売先 >>386
MFCで言うなら
CDialog がダイアログの表示、移動、閉じるとかの基本的な動作を持つクラス
class CXXXDlg : public CDialog
で上記のダイアログの基本的な動作を持ちつつ、必要な処理を付け加えることができる Servletを使うと、問答無用でHttpServletを継承させられることになるな
習うより慣れよとはいうが、
わからないなりにいじってみるってのもやり方としてはアリなんじゃね >>386
アクションとかシューティングゲーム作るときに便利 >>386
見積書と受注書に共通する処理はないか？
あるならそれは、個別に定義するのではなく、
じょういクラスの帳票に定義して継承すれば良いのではないか？ >>386
聖闘士クラスってのがあって、
ブロンズやシルバー、ゴールドは所詮そこから派生したもの。なら聖闘士クラスを継承して、ゴールド聖闘士クラス作ればいいじゃん。
っていうこと >>362
そもそもCのポインタの難所とされるのは文法のせいだから
int const * const * p;
const int * const p;
const int * const * const p;
みたいなぱっと見では修飾関係の謎なやつら void (*signal( int sig, void (*func) (int) )) (int);
標準ライブラリがこんな暗号みたいなんじゃ、
そりゃ「Cのポインタは難しい」といわれてしまうわな。 >>382
そうやって作ったルールは年月とともに忘れ去られ、ドキュメントも失われ、メンバーも入れ代わり、その場しのぎで拡張した機能のせいでソースコードが魑魅魍魎になる。
そういうプロジェクトを幾つも経験すると、結局はCの基本機能やライブラリででできることは素直にそれを使うべきと考えるようになる。 >>386
そりゃそうだ
それは実用の観点から考案や実装されてんだから
机上で学ぶ時には仕組みを理解できても有用性なんて分からなくて当たり前
だけどこの手の職種は性格悪い奴が多いから単なる経験値の違いでマウント取って悦に入る
それを初学者がプレッシャーに感じてるだけ
複数人、大規模、継続的な運用、公に公開とかを経験するうちに理解するから安心しろ >>396
それ分けわからんよなあ
学習サイト血眼で何度も読んでようやく理解って感じだったわ
でもC++でそれをしばらく使わないと忘れてしまうという
えーと、この場合はポインタ(アドレス)が定数で、ポインタのアドレスに
書き込んである値は定数じゃなくて、この場合は値も定数で…
…そして、頭爆発寸前という >>386
C#で8割くらい共通だけど2割くらい違う画面ってのを複数作ってたら継承の優位性が分かってくるんじゃないかと思う
共通2割、個別8割でもいいけど C++なんてのは、プログラマの脳を破壊する黒魔術になっているからあんなものは捨てろ。
機能がたくさんあればいいってもんじゃねーんだよ。
やろうと思えば＋演算子で引き算もできてしまうような言語など要らぬ！ >>402
C++は自由過ぎてカオスなんだよな
もっとカオスがC++/CLI、ヒープ領域がアンマネージドとマネージドに分かれているという
アンマネージドに確保する場合はnew、マネージドの場合はgcnewと使い分ける オブジェクト志向は良いんだけど、
継承（しすぎ）はあんまりオススメしない。
作りやすい（同じコードを2回書かなくて済む）が
読みにくい（どのコードがどの順番で実行されるか
直感的にわかりにくい）。
結果、保守性が下がる。
誰かが書いたコードを別の誰かがメンテする。
その前提で作ると、多重継承とかやりすぎない
方がいい。
わかりさすさは冗長さより優先すべき。 >>403
C++/CLIはなんの為に作られた言語か知らんけど
C++からC#呼ぶ時とかのラッパーにしか使ってないわ 継承とか演算子のオーバーロードとか要らんからクラスだけ追加したC+位のが欲しいんだけど。 >>395
それだとシルバー聖闘士やブロンズ聖闘士は一生ゴールド聖闘士になれないけどあってる？ >>407
要は
人間クラス
身長プロパティ
体重プロパティ
年齢プロパティ
性別プロパティ
筋力プロパティ
食べるメソッド
寝るメソッド
走るメソッド
跳ぶメソッド
うんこをするメソッド
etc.
クラス終わり
聖闘士クラス
人間クラスを継承
クロス階級プロパティ
星座プロパティ
コスモプロパティ
コスモを燃やすメソッド
コスモを感じるメソッド
etc.
クラス終わり
こんな感じやろか？ 仕事で他人の書いたコードをたくさん見るが、クラスにしてかえって読みにくくなってしまってるのはよく見る。
センスの良い人が書いたのはそんなこと無いけど >>407
キャラクタークラスが人間インターフェースと聖闘士インターフェースのプロパティを持つんじゃね
キャラクタークラスのインスタンスとして星矢
星矢is人間 且つ 星矢is聖闘士
聖闘士インターフェースを持つ抽象クラスを継承して
ブロンズ、シルバー、ゴールドを作る
星矢からブロンズやゴールドのクラス
から作ったインスタンスを
星矢が持っているプロパティから参照すれば
星矢はブロンズにもゴールドにもなれる キャラクタークラスから犬インターフェースを参照すれば
犬の聖闘士キャラができる >>371
名前空間はクラスの親玉って思ってる
関数や変数を複数まとめたクラスってのあって
そのクラスをさらにジャンル別にまとめたところの総元締めが名前空間 ゲームにはタスクシステムで十分
オブジェクト指向など不要 名前空間がかなり柔軟な言語ってある？
Pythonの引数名指定のメソッド呼び出しの、引数名を文字列で動的に変えれたり、クラス名の文字列の一部を文字列のリストで動的にしたり。 純粋なオブジェクト志向で書こうとすると糞コードを生産してしまう残念プログラマだが、Classは必要だわ。
メソッドだけだとごちゃごちゃになる。部屋の整理を考えてみろ。小物入れだけじゃ部屋は整理整頓できん。
あ、関数型言語は知りません。 >>1は30年前のC言語から、いきなり現代に飛んで来たの？ 時代遅れのオブジェクト指向おじさん「クラスは必要」 オブジェクト指向の概念を産み出したアラン・ケイはC++はオブジェクト指向では無い！と断言してたな クラスなんていらん。
C言語ににメンバー関数とコンストラクタとデストラクタとインヘリタンスとポリフォーミズムとオーバーライドとオーバーロードとエクセプションとテンプレートとラムダさえ追加してくれるだけでええ。 クラスなんていらん。
構造体に関数ポインタ突っ込むから。 クラスがないと元ソルジャーと言っても強いか弱いかよくわからないじゃん >>410
今もてはやされてる関数型プログラミングはそのオブジェクト指向プログラミングの欠点を克服するためのものなんだよね >>427
関数が増えたらポインタだらけで重くなるぞ
そうならないようにしたのがクラス ■ このスレッドは過去ログ倉庫に格納されています
