1
デフォルトの名無しさん
2018/05/08(火) 22:54:32
ID:
仕事でc言語をつめ込まれた直後にjavaやらされて混乱しとるんじゃが、オブジェクト指向とモジュール構造の差異を教えてほしい
いろいろ調べて自分なりの結論として
・オブジェクトとは、操作に対する「一連の手続き」である
e.g.
操作[電源ボタンを押す]→オブジェクト[PC]→起動[画面がつく]
・モジュールとは「機能or部品の最小単位」である( ≒ 関数)
e.g.
引数[電源ボタンを押す]→main[下位モジュール呼び出し]→(モジュールa[PC内の電源を起動]→モジュールb[プラグから電力を給電]→モジュールc... 以下略...モジュールz[ディスプレイに信号送信])→起動[画面がつく]
つまりモジュールは部品に過ぎないから複数個作って繋げて「一連の手続き」にする必要があるけど、オブジェクトは「一連の手続き」単位だからそれ単体で目的が達成ができる
オブジェクトの中身、処理部分でモジュールが使われていて、スーパークラスとサブクラスみたいな親と子の関係性
こういう認識で合ってる？
2
デフォルトの名無しさん
2018/05/08(火) 23:08:05
ID:
すまんが3行で
3
デフォルトの名無しさん
2018/05/08(火) 23:38:30
ID:
オブジェクト指向と
モジュール構造って
なにがちがうん
4
デフォルトの名無しさん
2018/05/09(水) 00:31:03
ID:
>>1
細かなイディオムに気を取られるな
CとJavaなんて本質的に何ら違いはない
5
デフォルトの名無しさん
2018/05/09(水) 07:25:01
ID:
その程度のことも自力で理解できないなら向いてないから辞職しなよ
6
デフォルトの名無しさん
2018/05/09(水) 12:17:55
ID:
>>4
まあ実際のとこ判らんくても実務ではなんとかなるかもしれんけどjava bronze試験通らんとあかんのよ
どうせ試験までやるならきっちり理解して先進みたいなーと
7
デフォルトの名無しさん
2018/05/10(木) 14:33:47
ID:
わからないからふんわりした批判しかできない良い例だね
8
デフォルトの名無しさん
2018/05/10(木) 19:25:10
ID:
オブジェクト指向には色々な要素があるけど、まず構造体と同じようにデータをある単位に分割して、そのデータを操作できる関数をメソッドに限るってのが基本と思っていい
Javaなら後は手続き型と何ら変わりなくて
・オブジェクト(データの塊)を作る
・メソッドを順番に呼び出して欲しいオブジェクトを作る
・適宜出力
これだけ
9
デフォルトの名無しさん
2018/05/10(木) 21:10:01
ID:
>>8
丁寧にありがとう
今日教科書一通り読み終わって、>>8を見て認識が結構変わった
c言語的に言うなら、モジュールは寧ろクラスに構造が近くて、関数はメソッド
ここだけ見ればやってることはさほど変わりないんだね
じゃあ何が違うのかと言えばただ1点、オブジェクトを作るか否か。
で、オブジェクトをc言語的に表現すると「構造体と関数を目的に応じてまとめたもの」。
こんな感じで合ってるかな
10
デフォルトの名無しさん
2018/05/10(木) 21:46:33
ID:
ここまで考えてみて、「でもオブジェクトの挙動って全部クラスに書いてあるんだから、一々インスタンス化せんでも全部クラスでやりゃ良くない？」ってとこに戻ってしまった
オブジェクトを作る利点って何があるのかな・・・
11
デフォルトの名無しさん
2018/05/11(金) 07:32:08
ID:
そう思うならインスタンスを作らず延々クラスを書き続ければ良い
new禁止な
12
デフォルトの名無しさん
2018/05/11(金) 08:56:48
ID:
>>10
敵Aと敵BのHPは同じクラスフィールドで管理するより別個のインスタンスフィールドで管理した方が楽でしょ？
Aさんの残高とBさんの残高は別個のインスタンスに分けた方が処理を書くとき混乱しにくいでしょ？
13
デフォルトの名無しさん
2018/05/11(金) 13:02:07
ID:
クラスはCで言うところの構造体を拡張したもの
中身の変数やインスタンスがメンバー 関数がメソッド
インスタンスは他人が書いたAPIライブラリーから使用したいクラスを選んで
実体化したもの 基本実体化しないと利用できません残念
クラス メンバー メソッド が解ってCの知識があればあとはコードかけるよ
オブジェクトは完成品かしら自分はあんまり使わない言葉だから適当
14
デフォルトの名無しさん
2018/05/11(金) 13:48:41
ID:
>>13
メソッドはあくまでメンバ関数では？(メソッドもメンバであるという意)
あえて対称的な用語を用いるならフィールドとメソッドでしょう
インスタンスを他所のライブラリ中クラスの実体化に限ってるのはシンプルに意味不明なんだけど何か理由があるの？
15
デフォルトの名無しさん
2018/05/11(金) 14:01:37
ID:
ごちゃごちゃ言うなC的にシンプルに説明してる
16
デフォルトの名無しさん
2018/05/11(金) 14:14:25
ID:
>>15
>>13 の前半みたいなのはシンプルに説明してるんじゃなくて間違ってるって言うんだよ
後半についてはまぁ理解はできんが納得はできる
17
デフォルトの名無しさん
2018/05/11(金) 14:27:50
ID:
うるせえなじゃあお前が説明しろ
ルールは同じ文字数で言葉遊びはすんな
出来なきゃ黙ってろ
18
デフォルトの名無しさん
2018/05/11(金) 14:42:53
ID:
俺が間違ってたか
大雑把にメンバー変数メンバーメソッドがクラスの中身な
19
デフォルトの名無しさん
2018/05/11(金) 18:39:30
ID:
やっぱり、ホリエモンのそっくりさんの社長が出て来る漫画に出てくる
最近の子はオブジェクト指向から入るからうんたらかんたら
っていう悪口が間違っていることがよくわかる
はじめからJavaを学んでオブジェクト指向から入った方が良い
20
デフォルトの名無しさん
2018/05/11(金) 18:43:45
ID:
そんな本職のプログラマが書いたわけでもないネタ漫画を
真に受けたらアカンと思うよ
21
デフォルトの名無しさん
2018/05/11(金) 22:18:36
ID:
>>12
あーなるほど
上の例で言えば、例えばインスタンス化せずにEnemyHPクラスで全てのHPを管理しようとした場合「敵AのHPを計算・出力したあと敵BのHPを計算・出力する」って順々の処理は出来るけど、
範囲攻撃して敵AとBのHPを同時に計算しなきゃならない時とか、敵Aを攻撃したあと敵Bを攻撃すると敵AのHPが上書きされちゃうから、一戦闘でエンカウントしうる敵の分、それぞれの状態を保存するようなメソッドなり変数なりなんなりが別途必要になったりする。
でもオブジェクトを適時作る機能 =インスタンス化があれば基本計算・出力機能だけで完結できるってことよね？
22
デフォルトの名無しさん
2018/05/11(金) 22:46:01
ID:
いやこの場合出力するってのは余計か
メモリ上にデータを展開して都度そのデータを再利用したり加工したい場合、インスタンス化があるとソースコードが随分スマートになるってところが最大のメリットと理解したのじゃが
23
デフォルトの名無しさん
2018/05/11(金) 22:49:14
ID:
パラメータのintの多次元配列作ってをごちゃごちゃいじるのより
キャラ一体分のクラスを作ってそれを必要数複製した方が記述がスマートになるよってこと
24
デフォルトの名無しさん
2018/05/11(金) 23:01:59
ID:
C言語が理解できるなら、Xのソースを読んでみよう。
その後、高橋真奈著やさしいJavaを読もう。
あら不思議、スラスラ読めます。
おわり。
25
デフォルトの名無しさん
2018/05/12(土) 00:04:42
ID:
Javaとオブジェクト言語を理解するにはRPGで例えると
いちばんしっくり来るのはほんまやな
スッキリJavaが人気本になるわけやで
26
デフォルトの名無しさん
2018/05/12(土) 00:11:01
ID:
Javaは意図的な分割が行える
27
デフォルトの名無しさん
2018/05/12(土) 08:27:18
ID:
>>23
c言語的なアプローチなら敵状態パラメータをヘッダファイルに構造体として全部書いちゃって、呼出側は その構造体をデータ型としたEnemyAとかEnemyB変数に入れるみたいなやり方であれば、呼出側の負担は殆ど変わらないんじゃないかなって思ったんだけど、
>>13で言ってるようにオブジェクトは構造体を拡張したもの = メソッドまで含んでるってとこが肝なのかな？
28
デフォルトの名無しさん
2018/05/12(土) 08:34:41
ID:
29
デフォルトの名無しさん
2018/05/12(土) 09:32:11
ID:
>>27
その通り
例えばint HPが構造体の要素なら加減乗除何でもできてしまうわけだけどクラスのprivateフィールドだと例えば
enemyA.damage(Power attacked)と
enemyA.heal()とに操作を制限できるんだよね
だから変な操作をしてしまえない
30
デフォルトの名無しさん
2018/05/12(土) 19:34:10
ID:
ゲームに登場するクラスがEnemyだけだったら
そこまでオブジェクト指向のありがたみは感じないけど
EnemyはそもそもHPやMPみたいなint型のプリミティブな変数だけじゃなくて
SkillとかItemみたいなオブジェクトもフィールドとして当然持つことになるだろうし
そのSkillやItemにもEffectというオブジェクトがフィールドにあるかもしれない
って考えはじめると、手続き型よりコードを書くのが楽にｎ感じるようになる
31
デフォルトの名無しさん
2018/05/13(日) 08:49:36
ID:
>>28
やさしいJavaなつかしいな！
おれは初版でお世話になった。何年前だろ。。おれも歳とったなぁ(´・ω・｀)
32
デフォルトの名無しさん
2018/05/13(日) 13:02:55
ID:
>>29
ふむふむ、効果は判った、いわゆるそれがカプセル化ってやつだよね
自分にも、他人にも構造体に対し使える操作を固定化させることで、プログラミングする際のミスを減らせるってことかな
33
デフォルトの名無しさん
2018/05/21(月) 01:41:35
ID:
>>1
レス読んでないから解決済みかもだが
× オブジェクトとは、操作に対する「一連の手続き」である
○ オブジェクトとは「物」。属性（プロパティ）と操作（メソッド）から成る
で、 切り口が違う。例えば女をイカせたい場合、Cだと op=onna("AV女優"); ikaseru(op, KUNNI); に対し、Javaだと、op=new Onna("AV女優"); op.ikaseru(KUNNI); となるのだが、ニュアンスの違いわかるかな？操作から入るのではなく、物から入る
そうすると、ソフトが複雑にならないって良さがあるんだけど、これも経験をつまないピンとこないと思う
で
× モジュールとは「機能or部品の最小単位」である( ≒ 関数)
○ モジュールとは「機能or部品をある程度まとまった単位でまとめた単位』である( ≒ フォルダ)
で
Javaの場合、パッケージと呼ぶ
34
デフォルトの名無しさん
2018/05/21(月) 05:28:33
ID:
35
デフォルトの名無しさん
2018/05/21(月) 23:15:24
ID:
どうでもいいけどなんでこういうふうにわざわざ下ネタを例にとる奴が定期的にわくんだろうな>>33
36
デフォルトの名無しさん
2018/05/23(水) 19:08:29
ID:
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
MHMJT
