オブジェクト指向って自然な文法だな 3 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/04/02(日) 16:30:38.65

前スレ
オブジェクト指向って自然な文法だな 2
http://echo.2ch.net/test/read.cgi/tech/1490506257/

**デフォルトの名無しさん** · 2017/04/21(金) 18:30:38.43

>>483
……

**デフォルトの名無しさん** · 2017/04/21(金) 18:30:56.12

俺のことは寡黙な人と呼んでくれ

**デフォルトの名無しさん** · 2017/04/21(金) 18:31:20.37

>>485
黙ってねーじゃねーか

**デフォルトの名無しさん** · 2017/04/21(金) 18:32:01.93

>>486
クソレスすんなハゲ

**デフォルトの名無しさん** · 2017/04/21(金) 18:33:35.27

>>487
ごめんね
ハゲでごめんね^^

**デフォルトの名無しさん** · 2017/04/21(金) 18:36:02.42

ハゲもプログラム書けんの？
書けるんだったらオブジェクト指向でキャットドア問題に調整してほしい

あ · 2017/04/21(金) 18:39:02.82

あのドアってこういう話の発端から出てきた問題だったんだな。
オブジェクト指向で、ってそういう事か、なるほど。
ナンセンスだな。

何を以ってドアと成立するか定義できてるようで出来てない。
定義1を死守したければ、俺なら定義1は定義0の子クラスにして、定義2は定義1を継承せずに定義0から作るわ。
定義0は最終的にObjectに収斂する。

クラス設計を破壊せずに性質を追加ってのが矛盾してる。
ワイン樽と泥水の問題。

**デフォルトの名無しさん** · 2017/04/21(金) 18:42:27.87

↑こうやって仕様に文句を付けて
コードから逃げる人間は飽きるほど見てきた

オブジェクト指向のコードをかける人間はいないのか

あ · 2017/04/21(金) 18:45:08.24

>>491
俺どっかで書いたぞ

**デフォルトの名無しさん** · 2017/04/21(金) 18:46:48.77

>>492
それどこよ？　どれよ？　どこなのよ？　どこーーー！！

**デフォルトの名無しさん** · 2017/04/21(金) 18:47:06.08

取り乱してしまいまして

あ · 2017/04/21(金) 18:48:45.01

もちろん、オブジェクト指向が役に立ちづらい、リアルな機械はそもそもコンポーネント指向で作るとも書いたし、コード自体適当なのも確かだが。
860 あ sage 2017/04/14(金) 08:00:23.71 ID:6kAIEFCu
ゴルーチンでドアとノブとストッパーとオートクローザーと個々に置いて、Channelで疎通させたらgoっぽい現実解になった。
ドアノブがあるとは限らんし、ドアノブとは別に鍵があるかもしれんし、とか思うと埋め込みではうまくいかんな。
この辺は機械と同じでコンポーネントにしとかないと後でわけわからん便利ボタン作られたときに面倒くさいと構えてしまったわ。
ラダーのほうがわかりやすいのかけるかも。
しかしideoneすげえな。
866 あ sage 2017/04/14(金) 10:26:30.48 ID:6kAIEFCu
>>862
http://ideone.com/yvttId

あ · 2017/04/21(金) 18:53:00.35

何でわざわざ関数作ったのに放棄してクロージャ変数にしてるか見たら、カプセル化がオブジェクト指向の専売でもなけりゃ普遍的に便利なものか気づくだろ。

**デフォルトの名無しさん** · 2017/04/21(金) 18:59:03.34

>>496
クロージャがカプセル化じゃないとしたら
カプセル化害悪論には賛成していただけるよね？

あ · 2017/04/21(金) 19:05:27.23

>>497
クロージャはカプセル化で、カプセル化害悪論には大反対だ。
カプセル化されてるから、ドアは責任を持ってイベントに対して好きなことを好きなだけできるし、他人はそれに関与せずにイベントの投げ合いで済む。
鍵のないドアだってあるんだから。

あ · 2017/04/21(金) 19:06:54.30

見せたくないものを隠すんだけじゃない。
見て不快なものが目に入らないようにするためにも使えるんだよ。
NHKの入らないテレビみたいなもんだ。

**デフォルトの名無しさん** · 2017/04/21(金) 19:27:31.37

>>499
具体的に誰に対してやってるの?

**デフォルトの名無しさん** · 2017/04/21(金) 19:29:06.55

>>498
カプセル化害悪論に反対しているとのことだけれども
もしクロージャがカプセル化ではないと仮定したら
カプセル化害悪論に反対する理由もなくなると思うんだよ

クロージャってどちらかというとローカル変数じゃない？
クロージャオブジェクトを使うところって関数内に限られると思うんだよ
そう考えるなら結局クロージャってローカル変数ってことになるわけじゃん？
だからクロージャを使ってもカプセル化害悪論には反しないんだよ

あ · 2017/04/21(金) 20:03:29.23

>>500
自分かも知れないし、他人かもしれないけど、それを考えたくない場面でそれが目に入らないようにしてる。
その関数以外書いてるときに、その関数なんて考えたくないじゃん。

>>501
だからクロージャは一つのカプセル化だって言ってるんよ。
ローカル変数って言葉が良くないが、ローカル変数には違いない。ただ、お前が思ってるローカル変数よりも限定的で、そして並行的だよ。
関数内に限られるわけではない。mallocして何かに帰そうが勝手だよ。
クロージャの中でいくつかのコールバックに渡したりするならなおさら。
つまるところ、オブジェクト指向のインスタンスのメンバ変数とあまり変わらん。

**デフォルトの名無しさん** · 2017/04/21(金) 20:07:05.07

>>502
はぁ?
ちゃんと設計書は書いてる前提でいいんだよね?

あ · 2017/04/21(金) 20:17:17.21

>>503
うん。書いてるから何？
書いてるから触ってはいけないとわかるはずだ、なら、無意味かつ実務知らなすぎだな。
書いてて触ってはいけないならば、触れることができてはいけないんだよ。本来は。
AppleのMacOSのUIのデザイン規約くらいの時代から書いてた話。
感電するよって書いてたら覆いをしなくたって良いなんて機械はありえないのと同じ。

**デフォルトの名無しさん** · 2017/04/21(金) 20:22:47.97

包丁は料理にのみ使われるものだから傷害事件で扱われる刃物は包丁以外であるって理屈

**デフォルトの名無しさん** · 2017/04/21(金) 20:32:03.02

>>504
じゃ、君の想定してる環境って

本来なら設計書を記述してから修正すべきなのに
それがやりにくい現場ってことでいいのかな?

カプセル化は設計書を記述する手順を踏んだとき役に立たない?

**デフォルトの名無しさん** · 2017/04/21(金) 20:45:20.00

車のブレーキだけを踏んでたら全然進まないのでプレーキを踏んでもちゃんと進むように修理する工場だな

**デフォルトの名無しさん** · 2017/04/21(金) 20:51:25.16

カプセル化の意義を誤解するものはfriendの意義も誤解する

あ · 2017/04/21(金) 21:04:20.97

>>506
本来なら設計書を記述するどころか設計変更申請出して承認を経て設計書と設計変更書を出して、実装を変更して設計変更書から起こされた上がってきたテスト仕様書でテストして完了するけど、何もやりにくくないでしょ。

カプセル化は役に立つよ。担保となる元の設計書で使ってる部品の設計書を出来る限り見ずに済むし、
なんなら部品ごと新しく変えてもIFさえあってれば良い証左になるんだから。

>>507
プレーキとやらの定義が、踏めば進むというものであるならそう治すべく修理なり改修なりするわな。
このパンチメタルで穴が空いてる部品は共有部品で、AT車ならフットレスト、MT車ならクラッチペダルにつける部品の首がよく腐るから設計変更するなら、
押してクラッチが切れるかもしれない部品であり、押しても何も起こらない部品を同時に設計変更してる事になるが。
お前らのドアってこのパンチメタルの板くらいフワフワした定義。

**デフォルトの名無しさん** · 2017/04/21(金) 21:09:39.74

>>509
設計書書いてるんだよね?

だったら今回の開発でそのメソッドを呼び出す奴は決まってる
今後増える予定を想定することの記述も設計書にはないでしょ?

この状態でprivateとpublicになんの意味があるの?

**デフォルトの名無しさん** · 2017/04/21(金) 21:11:56.33

>>509
全面的に同意
ふわっふわしまくってるせいでカプセル化が害だとか言うバカみたいな考えなしの意見が出てくるんだと思う

あ · 2017/04/21(金) 21:16:51.77

>>510
呼び出すやつは決まってる、今後呼び出し方が変わる予定も無い。
ならばそいつはそれがインターフェイスで良いと思うけど、インターフェイスが無いわけではない。そいつがそのものであるだけで。
その上で、疎通にはこれを使おうね、これは使ってくれるなよ、と言う設計は無為味だし、むしろそうならばモジュラーにせずにそれごと機械に埋めてしまえとなる。
そうでは無くて、壊れたらこれだけ変えられるようにしとこう、とか、これだけを改良できるようにしよう、とか、
不具合が出たときに特定しやくすしとこうとなると、ある意味不自由を強制する形で決まった形で疎通させるのは当然でしょ。
お前のパソコンがノートパソコンならタッチパッドは前者、USBマウスは後者だよ。

**デフォルトの名無しさん** · 2017/04/21(金) 21:25:56.38

>>512
何?次の開発を想定してるの?
よくわからないんだけど?

問題があったら設計書を修正してレビューしてソース修正する流れでいいんだよね?

**デフォルトの名無しさん** · 2017/04/21(金) 21:29:21.44

ここまでの流れで面白いのは>>414の視点だけ
カプセル化がどうの
その是非がどうのとはさんざん繰り返されがちだが

アクセッサ自体が意外と臭いよねって観点まで到達できる人は少ない
また、そこから先の議論についてもあまり見かけない

**デフォルトの名無しさん** · 2017/04/21(金) 21:31:37.27

>>514
そもそもアクセサなんてものはモダン言語では自動生成なので論外

**デフォルトの名無しさん** · 2017/04/21(金) 21:33:08.50

>>513
いつもよくわかってないな

**デフォルトの名無しさん** · 2017/04/21(金) 21:34:14.81

その自動生成ってのを嬉しがる精神性が問題
アクセッサなんか書きにくいほうが健全
きみにはまだ伝わらないと思うし
これ以上言葉費やす予定もない

あ · 2017/04/21(金) 21:35:03.27

>>513
一般的に開発ってこんなもんだろ。
物理的な製造業から何まで、本来は。

問題があったら、設計変更の起案からだよ。
設計変更より作り直したほうが安くつくとか考えないといかんだろ。
ソース修正した後に、何を担保にしてその修正が妥当か、どういうテストが妥当かを定義するときに、組み合わせ爆発が起こらんようにIF定義するんじゃん。

>>514
アクセサのあるprivateなメンバなんか、ちょっと運が良ければチェックロジックなんか入ってるかも？運が悪ければ違う値まで変わっちゃうかも？みたいな、余計に面倒くさい奴だしな。

**デフォルトの名無しさん** · 2017/04/21(金) 21:40:55.19

>>518
修正した設計書通りでしょ?
これがすべてに優先されるんでいいんだよね?っていうかそうじゃなかったらびっくりだわ

前のソースは関係ないよ
privateやpublicに意味なんかないよ

あ · 2017/04/21(金) 21:44:00.25

>>519
修正した仕様書の妥当性はどう計測して、修正したソースの妥当性はどう計測するの？
インアウトが確実に2つずつなら、ステートマシンでも組み合わせ数は知れてるだろうが、
インアウトの数が担保できなければそんなもの検証しようがない。

あ · 2017/04/21(金) 21:46:20.92

逆に言うわ。publicなものの組み合わせを検証する必要が本当に正しいと証明するためにはある。それはnCmで増える。
だから、組み合わせを減らしたい。

**デフォルトの名無しさん** · 2017/04/21(金) 21:47:22.88

>>517
いーやわかってないのはおまえ
アクセサの必要性が低いなんてことは歴史的背景ふまえググれば中学生でもわかること
ではなぜ事実上、必須になっているか
そこまで考えてはじめて俺と同じ土俵に立てる
出直せ

あ · 2017/04/21(金) 21:51:18.83

>>522
アクセサは自動生成されるべきじゃないし、される言語も少なくないか？アクセサ作ったらメンバが生えるのはあるだろうけと。

**デフォルトの名無しさん** · 2017/04/21(金) 21:51:19.37

publicフィールド = 何の制限もかけられないアクセッサだよ

つまりいずれにしろアクセッサ相当のものを使っているわけで、
問題はアクセッサがいるかどうか？ではなく、
制限をかける必要があるかどうか？

で考えたほうが良い。

あ · 2017/04/21(金) 21:52:38.91

>>521
意味わからん文になってた。証明するためには全パターンを網羅する必要がある、だな。

**デフォルトの名無しさん** · 2017/04/21(金) 21:58:52.01

>>523
されるべきなんだよ
何故なら90%のメンバ変数はアクセサなんて必要としないから
残り10%のために手書きなんてバカらしいだろう

**デフォルトの名無しさん** · 2017/04/21(金) 21:59:11.05

>>520
設計書通りに動くことを確認するよ

これができなくなっちゃうって言ってる?

あ · 2017/04/21(金) 22:07:30.53

>>526
メンバ変数を見ればいいなら、メンバ変数見れば良くない？
アクセサがない限り、見れない書けない方が健全だとは思うが。

>>527
似てるようで違う。
設計書が正しいかが組み合わせ全てを用いないと証明できないし、設計書通りかどうかも同様に証明できない。
インが4本なら16通りだけど、10本だと1024通りだよ。

**デフォルトの名無しさん** · 2017/04/21(金) 22:11:46.98

設計書が正しければ、正しいプログラムができるはずだ！

**デフォルトの名無しさん** · 2017/04/21(金) 22:15:10.16

設計書が正しいことをきちんとテストする必要がある。

つまり、設計書のテスト仕様書が必要だ。

そしてそのテスト仕様書通りに設計書が
正しいかをテストする人間も必要になる。

そこで重用なのは、テストの手法である。
設計書が正しいことをどうやってテストするか？
つまり設計書を書いた人間への聞き取り作業である。

設計書に書き漏れがないか？設計書に書かれた言葉に矛盾がないか？
テスト仕様書に従って設計書を見ながら設計者を問い詰める。
これが設計書に対する優れたテスト方法である

あ · 2017/04/21(金) 22:21:07.33

揶揄してるようだが、設計書をテストする設計書にあたるものが、設計変更申請書だよ。
それはヒアリングやら検証実験やら、承認者の首やら、人の手で担保するもの
大規模開発した事ないのかな。

**デフォルトの名無しさん** · 2017/04/21(金) 22:22:18.55

>>528
アクセス制限をするのはアクセス修飾の役割だしアクセサがあろうと無かろうとそれは必要
だからモダン言語にはプロパティというものがある
プロパティに出来てpublic変数に出来ないことを考えればおのずとプロパティでいいよねという結論にたどり着くと思うがね

**デフォルトの名無しさん** · 2017/04/21(金) 22:23:36.50

うーん
ぶっちゃけそれとカプセル化との関連が不明
もはや何を主張したいのか滅茶苦茶な気がするんだけど

**デフォルトの名無しさん** · 2017/04/21(金) 22:24:22.02

> 設計書をテストする設計書にあたるものが

意味わからん。

設計書をテストするものは、設計書のテスト仕様書だ。

つまりその設計には、○○の場合の処理は抜けていないか？
○○の場合に不整合は起きないか？
などというものが書かれいいるもので無ければ、
設計書のテスト仕様書とはよべない。

**デフォルトの名無しさん** · 2017/04/21(金) 22:25:20.57

>>520の発言内容はカプセル化と関係ないよね?

**デフォルトの名無しさん** · 2017/04/21(金) 22:26:41.05

>>532
> アクセス制限をするのはアクセス修飾の役割だしアクセサがあろうと無かろうとそれは必要

アクセッサはアクセス制限ではなく、アクセスした後に入れようとした値が
正常値かどうかを判断するもの。
型だけでは表現できない特殊なルールを記述する所
アクセス修飾子は単にアクセスできるかどうかしか記述できない。

**デフォルトの名無しさん** · 2017/04/21(金) 22:32:34.16

>>536
それは俺にレスするな
>>528の疑問に答えただけだから>>528にいえよ

俺の主張はgetter、setterの是非なんてものは時代遅れもいいところでその解がプロパティだろってことだけだ

あ · 2017/04/21(金) 22:32:51.15

>>532
プロパティはメンバ関数だよ。
C#ならIL見ればわかるけど、確かアンスコついた変数出来てる。
プロパティ自体もフツーに関数。
何で見えない変数が必要なのか、ってのは、副作用があるプロパティを書くことが出来る限り不必要にならない。
Queueみたいなもののgetのアクセサが、デキューして返すみたいなコードだと、デキューせずに先頭を見る方法が無くなる。

>>534
段取りがおかしい。「設計書のテストの仕様書」が成立するためには、「設計書の設計書」が必要。
なぜならば、テスト仕様書は実装からではなく、設計書から作られなけれいけないから。
「xxの処理は漏れていないか」は「xxの処理が必要だと定義されている」から書ける。
そのための要件は、すり合わせと設計変更申請のレビューと相手方、担当者の連名の捺印で担保する。

>>535
あるよ。
組み合わせが妥当な手段ではこれ以上ないと言う事が、数が少なくなればなるほど簡単になる。

**デフォルトの名無しさん** · 2017/04/21(金) 22:34:09.19

>>538
> なぜならば、テスト仕様書は実装からではなく、設計書から作られなけれいけないから。

設計書を書く → その設計書のテストを書く
何の問題もないじゃないか

あ · 2017/04/21(金) 22:34:35.69

>>537
getter,setterとプロパティってシンタックスシュガー以上の違いある？Kotlinとか、getterとsetterを暗黙のプロパティに変換してくれるが。

あ · 2017/04/21(金) 22:35:44.20

>>539
おまえふざけんなよw

あ · 2017/04/21(金) 22:37:04.70

実装してからのテスト作成って何の意味があるのか意味がわからん。

**デフォルトの名無しさん** · 2017/04/21(金) 22:42:23.85

>>542
確認作業だろ？

そもそも似たようなことは検収作業でやってるだろ

**デフォルトの名無しさん** · 2017/04/21(金) 22:43:24.15

カプセル化は不要でおｋ?

**デフォルトの名無しさん** · 2017/04/21(金) 22:44:14.67

>>544
カプセル化は必要でおｋ

**デフォルトの名無しさん** · 2017/04/21(金) 22:45:28.27

>>538
んなことはわかってるっつーの
だからなんだよ
getter setterなんていらねーよという話から始まってる議論になんの関係がある

**デフォルトの名無しさん** · 2017/04/21(金) 22:49:35.08

>>545
じゃあどうして>>506からの流れでカプセル化必要派は壊れてしまうん?

**デフォルトの名無しさん** · 2017/04/21(金) 22:51:43.93

>>547
そうか
理解できないから壊れた判定して逃げるんだな

**デフォルトの名無しさん** · 2017/04/21(金) 22:52:25.01

おまえら相変わらず低レベルな会話してんなww

**デフォルトの名無しさん** · 2017/04/21(金) 22:54:33.29

アクセッサの記述性は、下に行くほど上品とする
すでに酒飲んでこれ書いてるから、異論の必要は無い

public string Name {get; set;} // C#
public string Name {private get; set;} // 多少制限
public string Name {get; private set;} // 多少制限
attr_accessor :name # Ruby
attr_reader :name # 多少制限
attr_reader :name # 多少制限
public int getName() {return name;} // Java
public please forgive me int getName() {return name;} // 仮想OOPL-A
puloccinaucinihilipilification int getName() {return name;} // 仮想OOPL-B
// ↑インテリセンス的なものも当然禁止、emacsのabbrevもなぜか効かない設定

**デフォルトの名無しさん** · 2017/04/21(金) 22:56:49.22

>>549
ぜひ収拾つけてくれ
俺にはどーもできん

**デフォルトの名無しさん** · 2017/04/21(金) 22:57:14.58

至高の言語はswiftだよ
swiftが全ての正解

**デフォルトの名無しさん** · 2017/04/21(金) 23:05:20.32

>>552
#ifdefのくせになまいきな

**デフォルトの名無しさん** · 2017/04/21(金) 23:07:41.24

>>548
じゃあ、設計書をかく前提の開発でカプセル化が必要な理由を説明してよ

**デフォルトの名無しさん** · 2017/04/21(金) 23:15:04.82

実際に不正な操作がされていないということを保証できるから

設計書ベースだと、オブジェクト使うときは
規約をしっかり読んで、それに抵触しないよう用心してコーディングし、
変なことが起こった時
設計書の記述みて、コード上でオブジェクトの使用箇所全部洗って、
操作の規約が守られてるかどうか逐一人間がチェックして、
それではじめてprivateの一言と同じ成果となるのだ

やってられんしそもそも間違えるし

**デフォルトの名無しさん** · 2017/04/21(金) 23:16:10.52

利用者はちゃんと設計書を確認しながら使うとは限らないって何度も言えば、、、

**デフォルトの名無しさん** · 2017/04/21(金) 23:16:16.72

>>378
たとえば、インスタンス変数aに依存＆結構コストのかかる計算で決まる値bがあったとき
bをインスタンス変数bにキャッシュしておくほうが得だよね？
publicにしたaの変更をどうやってフックするの？

**デフォルトの名無しさん** · 2017/04/21(金) 23:22:50.81

>>555
バカなんだね
君はもうレスしなくていいよ

**デフォルトの名無しさん** · 2017/04/21(金) 23:24:54.21

>>551
普通の人間には無理w
ID:rPWpf+kQは頭の出来が異次元すぎるwww

**デフォルトの名無しさん** · 2017/04/21(金) 23:26:01.68

バカじゃない人間なら
機械語とバイナリエディタでOS作れてもおかしくない

**デフォルトの名無しさん** · 2017/04/21(金) 23:27:08.71

ただの煽りかげんなり
ほんとに信じて言ってるのかと思ってた

**デフォルトの名無しさん** · 2017/04/21(金) 23:28:45.45

>>559
そーだよなぁ
ただ喚くだけだしね

**デフォルトの名無しさん** · 2017/04/21(金) 23:34:32.77

>>393
dllやクラスファイルの形で、コードの無いクラスもあるんやで？
クラスやメソッドは紙やWebのみってのが。

**デフォルトの名無しさん** · 2017/04/21(金) 23:38:07.22

>>563
それとカプセル化になんの関係があるの?
よく考えて発言してねバカなんだから

**デフォルトの名無しさん** · 2017/04/21(金) 23:48:31.04

>>557
ずれたコメントさせてもらうが、俺ならそのbを計算した都度出力して、自らはキャッシュしない方策を考えるな。

**デフォルトの名無しさん** · 2017/04/21(金) 23:52:18.75

>>564
よく考えて発言してね
まぁ自分がバカと認識してるだけマシだけど

dllで提供されたものが他のものに依存してて単体で動かないとか、動くけど他のdllで得るはずの値を利用すること前提だとしたらその前提を知らない奴はうまく使えない
内部の処理を隠蔽し独立した動きを提供すればいいだけなんだよ

**デフォルトの名無しさん** · 2017/04/21(金) 23:53:01.61

ん？
カプセル化でprivateしてないと勝手にフィールド書き込んでしまう恐れがある。
コード無いからprivateにする意味ある。
そんな例。

あ、publicなフィールドを紙やWebに書かなければいいと言うのはなしね。
ツールが抽出するんで。
手書きじゃ無いんで。

**デフォルトの名無しさん** · 2017/04/21(金) 23:54:06.38

エンジニアガイジさあ…… 住処が荒廃したからってここに雑魚狩りに来るのやめなよ

**デフォルトの名無しさん** · 2017/04/22(土) 00:12:26.79

日を跨いだら突然おとなしくなったなぁ

**デフォルトの名無しさん** · 2017/04/22(土) 00:28:58.48

>>554
設計で呼び出し元に制限を規定するのであれば、試験仕様書には制限外の呼び出しはNGの試験が用意される
上記を満たす実装はカプセル化と呼ばれるのでは？

**デフォルトの名無しさん** · 2017/04/22(土) 01:06:43.76

>>570
呼ばない

**デフォルトの名無しさん** · 2017/04/22(土) 02:31:18.17

>>569
なんかわからんけど、このバカも睡眠という概念がなさそうだな。

**デフォルトの名無しさん** · 2017/04/22(土) 09:50:00.49

>>565
ずれるにしてもほどがある

あ · 2017/04/22(土) 11:07:46.29

>>568
うーん、ノセられてしもたわ。そもそも論で焼け野原にするのは好ましくはないな。
気をつけよう

**デフォルトの名無しさん** · 2017/04/27(木) 12:52:25.26

部品として使う場合、知識が要求されるのが、ちと時代おくれかなー

**デフォルトの名無しさん** · 2017/05/02(火) 18:17:11.49

カプセル化、継承、オブジェクト指向設計論に熱が入るやつは
そろそろ自分が動的言語童貞だと熱弁していることに早く気がついたほうがいい

**デフォルトの名無しさん** · 2017/05/02(火) 18:21:39.30

>>576
動的言語が得意な人は、オブジェクト指向にとって大事なことは何だと思うの？

**デフォルトの名無しさん** · 2017/05/02(火) 19:36:25.52

Objective-Cって動的言語だったのか

**デフォルトの名無しさん** · 2017/05/02(火) 19:36:57.13

てっきりオブジェクト指向言語かと思ってた...ん？

**デフォルトの名無しさん** · 2017/05/06(土) 04:26:04.66

それにしても(Javaの)クラスのインスタンス化の勉強がすごく楽しい。

**デフォルトの名無しさん** · 2017/05/06(土) 09:08:09.40

はい

**デフォルトの名無しさん** · 2017/05/06(土) 09:48:33.69

局所的すぎてわろ

**デフォルトの名無しさん** · 2017/05/18(木) 13:53:51.24

マジでクラスの分け方教えてくれどう分ければいいんだよ
分けたとしてもどのクラスにどうデータ持たせて
クラス間の受け渡しとかどうすんだよ全部ゲットセットでpublicにしてええんか