c言語的にjavaを教えて
仕事でc言語をつめ込まれた直後にjavaやらされて混乱しとるんじゃが、オブジェクト指向とモジュール構造の差異を教えてほしい
いろいろ調べて自分なりの結論として
・オブジェクトとは、操作に対する「一連の手続き」である
e.g.
操作[電源ボタンを押す]→オブジェクト[PC]→起動[画面がつく]
・モジュールとは「機能or部品の最小単位」である( ≒ 関数)
e.g.
引数[電源ボタンを押す]→main[下位モジュール呼び出し]→(モジュールa[PC内の電源を起動]→モジュールb[プラグから電力を給電]→モジュールc... 以下略...モジュールz[ディスプレイに信号送信])→起動[画面がつく]
つまりモジュールは部品に過ぎないから複数個作って繋げて「一連の手続き」にする必要があるけど、オブジェクトは「一連の手続き」単位だからそれ単体で目的が達成ができる
オブジェクトの中身、処理部分でモジュールが使われていて、スーパークラスとサブクラスみたいな親と子の関係性
こういう認識で合ってる? オブジェクト指向と
モジュール構造って
なにがちがうん >>1
細かなイディオムに気を取られるな
CとJavaなんて本質的に何ら違いはない その程度のことも自力で理解できないなら向いてないから辞職しなよ >>4
まあ実際のとこ判らんくても実務ではなんとかなるかもしれんけどjava bronze試験通らんとあかんのよ
どうせ試験までやるならきっちり理解して先進みたいなーと わからないからふんわりした批判しかできない良い例だね オブジェクト指向には色々な要素があるけど、まず構造体と同じようにデータをある単位に分割して、そのデータを操作できる関数をメソッドに限るってのが基本と思っていい
Javaなら後は手続き型と何ら変わりなくて
・オブジェクト(データの塊)を作る
・メソッドを順番に呼び出して欲しいオブジェクトを作る
・適宜出力
これだけ >>8
丁寧にありがとう
今日教科書一通り読み終わって、>>8を見て認識が結構変わった
c言語的に言うなら、モジュールは寧ろクラスに構造が近くて、関数はメソッド
ここだけ見ればやってることはさほど変わりないんだね
じゃあ何が違うのかと言えばただ1点、オブジェクトを作るか否か。
で、オブジェクトをc言語的に表現すると「構造体と関数を目的に応じてまとめたもの」。
こんな感じで合ってるかな ここまで考えてみて、「でもオブジェクトの挙動って全部クラスに書いてあるんだから、一々インスタンス化せんでも全部クラスでやりゃ良くない?」ってとこに戻ってしまった
オブジェクトを作る利点って何があるのかな・・・ そう思うならインスタンスを作らず延々クラスを書き続ければ良い
new禁止な >>10
敵Aと敵BのHPは同じクラスフィールドで管理するより別個のインスタンスフィールドで管理した方が楽でしょ?
Aさんの残高とBさんの残高は別個のインスタンスに分けた方が処理を書くとき混乱しにくいでしょ? クラスはCで言うところの構造体を拡張したもの
中身の変数やインスタンスがメンバー 関数がメソッド
インスタンスは他人が書いたAPIライブラリーから使用したいクラスを選んで
実体化したもの 基本実体化しないと利用できません残念
クラス メンバー メソッド が解ってCの知識があればあとはコードかけるよ
オブジェクトは完成品かしら自分はあんまり使わない言葉だから適当 >>13
メソッドはあくまでメンバ関数では?(メソッドもメンバであるという意)
あえて対称的な用語を用いるならフィールドとメソッドでしょう
インスタンスを他所のライブラリ中クラスの実体化に限ってるのはシンプルに意味不明なんだけど何か理由があるの? >>15
>>13 の前半みたいなのはシンプルに説明してるんじゃなくて間違ってるって言うんだよ
後半についてはまぁ理解はできんが納得はできる うるせえなじゃあお前が説明しろ
ルールは同じ文字数で言葉遊びはすんな
出来なきゃ黙ってろ 俺が間違ってたか
大雑把にメンバー変数メンバーメソッドがクラスの中身な やっぱり、ホリエモンのそっくりさんの社長が出て来る漫画に出てくる
最近の子はオブジェクト指向から入るからうんたらかんたら
っていう悪口が間違っていることがよくわかる
はじめからJavaを学んでオブジェクト指向から入った方が良い そんな本職のプログラマが書いたわけでもないネタ漫画を
真に受けたらアカンと思うよ >>12
あーなるほど
上の例で言えば、例えばインスタンス化せずにEnemyHPクラスで全てのHPを管理しようとした場合「敵AのHPを計算・出力したあと敵BのHPを計算・出力する」って順々の処理は出来るけど、
範囲攻撃して敵AとBのHPを同時に計算しなきゃならない時とか、敵Aを攻撃したあと敵Bを攻撃すると敵AのHPが上書きされちゃうから、一戦闘でエンカウントしうる敵の分、それぞれの状態を保存するようなメソッドなり変数なりなんなりが別途必要になったりする。
でもオブジェクトを適時作る機能 =インスタンス化があれば基本計算・出力機能だけで完結できるってことよね? いやこの場合出力するってのは余計か
メモリ上にデータを展開して都度そのデータを再利用したり加工したい場合、インスタンス化があるとソースコードが随分スマートになるってところが最大のメリットと理解したのじゃが パラメータのintの多次元配列作ってをごちゃごちゃいじるのより
キャラ一体分のクラスを作ってそれを必要数複製した方が記述がスマートになるよってこと C言語が理解できるなら、Xのソースを読んでみよう。
その後、高橋真奈著やさしいJavaを読もう。
あら不思議、スラスラ読めます。
おわり。 Javaとオブジェクト言語を理解するにはRPGで例えると
いちばんしっくり来るのはほんまやな
スッキリJavaが人気本になるわけやで >>23
c言語的なアプローチなら敵状態パラメータをヘッダファイルに構造体として全部書いちゃって、呼出側は その構造体をデータ型としたEnemyAとかEnemyB変数に入れるみたいなやり方であれば、呼出側の負担は殆ど変わらないんじゃないかなって思ったんだけど、
>>13で言ってるようにオブジェクトは構造体を拡張したもの = メソッドまで含んでるってとこが肝なのかな? >>27
その通り
例えばint HPが構造体の要素なら加減乗除何でもできてしまうわけだけどクラスのprivateフィールドだと例えば
enemyA.damage(Power attacked)と
enemyA.heal()とに操作を制限できるんだよね
だから変な操作をしてしまえない ゲームに登場するクラスがEnemyだけだったら
そこまでオブジェクト指向のありがたみは感じないけど
EnemyはそもそもHPやMPみたいなint型のプリミティブな変数だけじゃなくて
SkillとかItemみたいなオブジェクトもフィールドとして当然持つことになるだろうし
そのSkillやItemにもEffectというオブジェクトがフィールドにあるかもしれない
って考えはじめると、手続き型よりコードを書くのが楽にn感じるようになる >>28
やさしいJavaなつかしいな!
おれは初版でお世話になった。何年前だろ。。おれも歳とったなぁ(´・ω・`) >>29
ふむふむ、効果は判った、いわゆるそれがカプセル化ってやつだよね
自分にも、他人にも構造体に対し使える操作を固定化させることで、プログラミングする際のミスを減らせるってことかな >>1
レス読んでないから解決済みかもだが
× オブジェクトとは、操作に対する「一連の手続き」である
○ オブジェクトとは「物」。属性(プロパティ)と操作(メソッド)から成る
で、 切り口が違う。例えば女をイカせたい場合、Cだと op=onna("AV女優"); ikaseru(op, KUNNI); に対し、Javaだと、op=new Onna("AV女優"); op.ikaseru(KUNNI); となるのだが、ニュアンスの違いわかるかな?操作から入るのではなく、物から入る
そうすると、ソフトが複雑にならないって良さがあるんだけど、これも経験をつまないピンとこないと思う
で
× モジュールとは「機能or部品の最小単位」である( ≒ 関数)
○ モジュールとは「機能or部品をある程度まとまった単位でまとめた単位』である( ≒ フォルダ)
で
Javaの場合、パッケージと呼ぶ どうでもいいけどなんでこういうふうにわざわざ下ネタを例にとる奴が定期的にわくんだろうな>>33 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
MHMJT >>1
レス読んでないけどC言語はそれまでのプログラム言語が
プログラマが処理先に自由にgotoしてよかったので
処理が飛びまくって後からの解析がシャレにならなくなっていたのに対して
「関数」として「数値入れると答えが出る」単位でプログラムしましょうという発想
C++などはその関数をクラスという単位にしてパーツの付け替え加工で
使い回せるようにしよう!という発想
Javaはちょっと違う系統のオブジェクト指向から思想を取り込んでるから
「クラス」に「命令を与えると答えが出る」単位にしようという発想
なんだかわからない数値を毎回後から来たプログラマーが
「この数値なんだろう?」って追わなくても
人間にわかる命令で「これをやる」って命令が送られると
プログラムがやはり人間にわかる名前のつけられたデータを取ってきて
自分で命令された処理をやっているというコードが理想。 Cのほうがjavaより簡単明朗。推奨されないメソッドの洪水は、見ていて気分が悪くなるし。
でもWebバックエンドならJava一択になるのかな。最初に覚えるなら絶対Cがおすすめ。
そのあとC++そしてjavaが最高の流れ。そこまでいけば、どんな言語もちゃらい・はずだが
・・ 既に解決してる単発スレでなに言ってんの
ちゃんインシャンにきまってるわ 終わってるスレだが、オブジェクト指向の「考え方」を
知らずに、巨大クラス作るとそれは「グローバル変数と
それを操る関数たち」っていう、最悪の状態になるんだよな。 >>47
OpenGL用のC++ライブラリですね判ります >>47
C だと変数領域を「共有」しているので、誰かがアドレスポインタを
間違えて使うと、酷い目に遭う。
Java だとローカルな変数をオブジェクトが「抱えて」いて、
それをメソッドを使ってどうこうしよう、という形になる。
ただ、それだとグローバル変数を経由しようとしたときに
ややこしい話になるので、シングルトン実装したオブジェクトに
問合せをするとかいったことになる。
ぶっちゃけ C が解ってるんなら Java は難しくない。
ただ。おれみたいな年寄りからすると、可変長のメモリ領域の
扱いが便利すぎて、「ボケるのが早くなりそうだ (-_-!)」という
不安がある。 >>47
所謂、神クラスのことかな。
一つのクラスに何でも詰め込みすぎて、実質、そのグラス内で定義されているメンバ変数がグローバル変数と化している状態って奴でしょ。
責務もハッキリしてないからテストもできない最悪の状態(再利用性・可読性が死んでる)になってることは容易に想像できる。 >>50
それって、C のモジュール化の時点で失敗しているので、
このスレの主旨である Java (あるいは OO)とは
何の関係もないように思う。
いや、言いたいことはわかるんだけど、
その手のとばっちりを喰った経験が多々あって、
トラウマに引っかかるので …… c言語の関数をclass内のmethodに置き換えるだけじゃね
?OOの基本はjava のチュートリアルだっけ原文に書いていた 気合いだ〜 C++的にJavaじゃなくて
C的にJavaってのがミソか