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

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

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

あ · 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にしてええんか

**デフォルトの名無しさん** · 2017/05/18(木) 15:26:21.38

>>583
データホルダー
計算役
データ管理役
UI仲介役

抽象的だがこんな分け方だろう

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

小人さんだと思え。「おまえはこれをやる小人さんだ！」って決めろ。

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

>>583
ゲットもセットも要らない
全部パブリックフィールドでダイジョブです
カプセル化はオブジェクト指向に不要な概念と言っていいでしょう

**デフォルトの名無しさん** · 2017/05/18(木) 19:11:55.79

>>583
クラス分けで悩むならグローバル変数なくしてやりすぎなくらいメソッドを細分化してみたらいいよ

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

>>587
なるほど

**デフォルトの名無しさん** · 2017/05/18(木) 23:04:55.06

>>583
世の中の仕組みと一緒だ。
社長が部下に指示を出す。
部下は結果を返す。
社長は、別の会社と連携してサービスを広げていく。

全ては機能を有していて、機能同士が連携してより大きな機能を作っていくだけだ。

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

>>583
日本語的な表現でクラス分けをやるとしたら
「いくつも仕事をしていないこと」というのが目安だろうか

例：　「入力値のバリデーションやる」「設定ファイル読んでパラメータ保持」
怪しい例：　「ユーザー設定をDBから読んでパラメータに基づきUIをイジくって表示する」

数値的な目安が欲しいなら、パブリックメソッドが7以上あったら
そのクラスは複数の仕事を抱えている可能性があるんで、分割を検討する
まあ共通で使うクラスが太ってしまうことはよくあるけど
7ってのは平均的な人間がチラ見でパっと暗記できる事柄のリミット値

**デフォルトの名無しさん** · 2017/05/19(金) 19:43:17.99

>>583
MVCモデルとかアーキテクチャで調べる
依存性の注入で調べる
完全コンストラクタで調べる

この辺り守ってれば自ずと決まる

**デフォルトの名無しさん** · 2017/05/19(金) 20:11:31.04

オブジェクト指向って「学び」がないんだよな
文法が全て同じになって処理のパターンみたいなのが
すべて「名前」で隠蔽されて見えてこない。
処理の委託元のコード追ってもたらい回しにされてる感じで
「実際の処理」がどこにあるのか埋もれてしまってる状態になる。

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

どうやって隠すか
ライブラリ作成側になると学びは多いよ

**デフォルトの名無しさん** · 2017/05/19(金) 22:24:14.23

>>592
スタックトレースを見るんだ

**デフォルトの名無しさん** · 2017/05/20(土) 06:03:34.30

大きなシステムとか組んだ事ないんだろ

**デフォルトの名無しさん** · 2017/05/20(土) 18:54:10.07

まあ実際の処理を隠蔽するのがまさに１つの目的だし
たらい回しというか参照辿って芋づるで引っ張れる設計じゃないし、むしろそこがオブジェクト指向のキモだからな

**デフォルトの名無しさん** · 2017/05/20(土) 19:17:55.25

実際の処理が見れないと困るケースがもしあれば
設計が既に破綻してるって話だわな

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

役員が下っ端社員の細かい作業手順を知る必要ないからな。
ちゃんと結果報告が上がってくれば作業手順は他の人間に影響を与えてなければ関係無い。

**デフォルトの名無しさん** · 2017/05/20(土) 20:38:10.12

オブジェクト指向は総活躍社会

**デフォルトの名無しさん** · 2017/05/21(日) 01:27:28.98

>>597
図面的な意味で設計どうこうじゃなくて「なんかバグ出てるのはわかるんだけど
誰が調べても原因がわからん」系の状況じゃね？

継承四連打キメてて3段目で特定のタイミングのみ変数上書きワロスみたいな……

**デフォルトの名無しさん** · 2017/05/21(日) 04:39:36.10

>>597
無茶いうな

**デフォルトの名無しさん** · 2017/05/21(日) 10:57:27.44

>>600
597じゃないけどそういうのは設計が破綻していると言うと思う
図面の設計て意味じゃなくて作成者のプログラミング設計って意味で

**デフォルトの名無しさん** · 2017/05/21(日) 12:54:25.54

世の中のソースコードの90%の多段継承は既に破綻してる、もしくは今後するけどな
つまり仕組みが糞

**デフォルトの名無しさん** · 2017/05/21(日) 17:51:03.66

>>600
結局、オブジェクト指向ってただ作るだけなら得意なんだけど
正しく作っているか確認することは苦手なんだよね

そりゃあ設計はあるだろうし、設計通りに作られていれば問題ない。
でも設計通りに作られているのかの検証は、より困難になっている。

**デフォルトの名無しさん** · 2017/05/22(月) 12:24:20.53

なんか"経理部に領収書出して「清算お願いします」ってシステム"に
延々「経理部が不正やってないとも限らないよね！検証できないよね！」って
無根拠にただ喚いてる奴がいるみたいになってて相手のしようがないんだが、おまえ。

**デフォルトの名無しさん** · 2017/05/22(月) 12:36:09.78

>>605
アホ

**デフォルトの名無しさん** · 2017/05/22(月) 19:27:44.11

>>586
カプセル化が一番重要と思ってたんですが違うんですか?

**デフォルトの名無しさん** · 2017/05/22(月) 19:30:22.25

ソース付のライブラリ使えば？

**デフォルトの名無しさん** · 2017/05/22(月) 20:40:23.17

>>607
カプセル化が修正の閉鎖をもたらし
インターフェースが拡張の開放をもたらす
両方いる

**デフォルトの名無しさん** · 2017/05/22(月) 22:48:06.26

やっぱりどっちもいらない

**デフォルトの名無しさん** · 2017/05/24(水) 19:52:46.15

>>607
ゲッタセッタが生えてるプライベートフィールドはパブリックと変わらないってことだろう
要するにそれはカプセル化とは言わない
それやるぐらいならむしろパブリックの方がゲッタセッタの裏で余計なことしてない保証になる

**デフォルトの名無しさん** · 2017/05/24(水) 20:02:53.29

>>607
俺も重要だと思ってるけどその話題は荒れるので出さないようにしてる

**デフォルトの名無しさん** · 2017/05/24(水) 20:51:58.45

カプセル化の話だとデータの隠蔽のことばかりになってしまうのは残念じゃのう

**デフォルトの名無しさん** · 2017/05/24(水) 22:22:46.76

メソッドオーバーライドやインターフェース実装（具体例はJavaのinterface)も一応カプセル化の範疇だろうが
どっちかってと「継承」とか「クラス図」とか「デザパタ」の文脈で話す場合が多いかも

**デフォルトの名無しさん** · 2017/05/24(水) 23:27:44.78

>>614←こいつわかってなさそう

**デフォルトの名無しさん** · 2017/05/25(木) 00:11:42.62

詳細を隠し、結合度を弱め、変更に強くする、だっけか？
ただ、まあ面倒い

C#の新しいプロパティ構文がJavaでも使えればいいのにな

**デフォルトの名無しさん** · 2017/05/25(木) 07:20:20.62

哲学やると頭腐る

**デフォルトの名無しさん** · 2017/05/25(木) 07:29:05.76

最初から？

**デフォルトの名無しさん** · 2017/05/25(木) 14:20:37.34

>>611
データの整形はいずれにしても必要なわけで問題はどこで整形するか
クラス外で何カ所も整形の処理書くよりプロパティ内に書いた方がいいよね

**デフォルトの名無しさん** · 2017/05/25(木) 21:00:55.82

>>619
ゲッタセッタで公開されたプライベートフィールドと、書式化された文字列を返すプロパティって全然別物じゃんアホなの