新しいソフトウェア構築論を考えついた
■ このスレッドは過去ログ倉庫に格納されています
結局のところ、目的があるわけだろ?
ならその目的をAnswerと仮定して
それに紐づくロジックをクラス内に規定し、外部要因をテンプレート化すればいいと思うんだ たとえば
アクセルを踏むと走る車
オブジェクト指向だと想像つくだろ?
これは
class Answer :motor
answer():motorpower × torq
こうなる すまん、仕様変更でAnswerの型が変わったんだわ これはmotorが変わってもロジックは変わらないんだよ >>8
どこが仕方ないのか分からない
スマホでも打てるけど…… たとえば、社員クラスが単価を持ってて、労働時間クラスに登録されたら、労働表に社員クラスの単価と労働表クラスの時間をかけて給与クラスの……みたいなオブジェクトに縛られることがなくなる
金払うanswer:社員,労働時間
answer=単価×時間
こうなる
templateですべてをつけて返すんだ >>11
関数型プログラミングでもオブジェクト指向プログラミングでも構造化プログラミングでもないから
回答はオブジェクト指向になりえず
テンプレートを使えない関数型プログラミングでもなく
内部にロジックを持たない構造化プログラミングでもないから新しい オブジェクト指向だと社員クラス、給与クラス、会社グラス
社員クラスと給与クラスのインスタンスをもつ会社クラスの給与振り込み関数、みたいな感じになる
実体を持つものがクラスになる
それに対して、給料は社員単価かける時間って事実、fact要素と、その回答、Answerはメソッドになれてもクラスになれない
だから、逆にAnswerをクラスにして、factをtemplateにする手法を取るべきなんだよ >>17
Answerはユーザ型のクラスになる
それを用いるクラスのtemplateになる >>20
その場合は不明確目的型、UAnswerを使うんだ。
UnknownAnswer型は不明確なままAnswerになる わけのわからない計算 UAnswer
わけのわからない計算2 UAnswer
UanswerQueに突っ込んで、UanswerとUanswerを使い計算してUanswerを作る
目的まで行けばAnswerにすればいい 例えば
鉄鋼クラス派生のニッケルクラスの素材比重計算メソッド
鉄鋼クラス派生のアルミクラスの素材計算比重メソッド
こういうのから開放され
素材計算クラス、テンプレートにアルミをつけるようになる factor templateの切り口は普通のプログラミング経験者は思いつかないと思う 例題として
型番をユーザーが入れると、アマゾンと楽天市場から最安値を持ってきて表示するソフトがある
これのクラス構成を考えてみてよ 最安値を取得するクラス
テンプレートに楽天やアマゾンをつけれ ショップクラス
virtual 情報取得
最安値サーチ(型番)メソッド
派生→アマゾンクラス
派生→楽天クラス
アマゾンクラス
情報取得メソッド
楽天クラス
情報取得メソッド
最安値計算ソフトクラス
ショップインスタンス配列
全店舗最安値表示メソッド
こうなるだろ? これが今回の構造だと
UAnswer アマゾン取得クラス
UAnswer 楽天取得クラス
Answer 最安値取得 template アマゾン、楽天
こう書ける >>37
全部を共用体で抱いたUAnswerとAnswerに、内部構造は通常組込型 >>38
インターフェースは楽天とアマゾンの処理の振る舞いを分けるための機構で
Answer,UAnswerは回答を得るための機構 使ってる言語機能と構築論は別物だよ
構造化プログラミングでもオブジェクト指向プログラミングでも抽象クラスは使うが構築方法が違うだろ いや、シンプルになると思うよ
クラスが1/10になると思う Unknown
Answerではないが、Answerとして処理すべきもの まずクラス連呼してるってことはオブジェクト思考が必須条件なの? >>46
実装のときにってこと?
もっといいパターンあると思うよ >>48
いや、オブジェクト指向ができるだけの言語知識があればいい まぁ、中途半端に知った気になってる無知にはいろんなことが新しく感じる時期があるから生暖かく見守ろうや OOPというかインターフェイス志向と何が違うんだ? あー分かった
プログラミング習いたての超初心者が作った全部入りの巨大クラスに比べてってことか
最安値計算ソフトクラス
ショップインスタンス配列
全店舗最安値表示メソッド
こうなるだろ?
↑
少なくとも俺はこうならない >>55
いや、そうなってないなら厳密なオブジェクト指向になってない オブジェクト指向はルールが遭って、アクセサを通してそのグラスが持つ属性しか置いてはならないんだよ
だからそうならないなら完全なオブジェクト指向になってない 最安値計算ソフトクラス←ソフト本体の定義
ショップインスタンス配列←ショップの最安値メソッドをforeachで呼び出さないと得られない。なぜならソフト本体はショップクラスを持っているわけで、ソフトが最安値を持っているわけではないから。
全店舗最安値表示メソッド←ソフトの機能として、全店舗最安値をどう操作するかの機能は最安値計算ソフトクラスを持つ必要がある。
こうなるだろ?
少なくとも俺はこうならない
↑オブジェクト指向はデメリットもあって、より効率的なコードはルールを破れば書けるよ。だがそれは初心者だからではなく無法なコードを書くバカのせいだから 実装をテンプレートに移譲しただけ
馬鹿でかテンプレートができて保守できなくなるね オブジェクト指向は、1960,70年代のソフトウェアクライシスの時にデータとメソッドが別々だったものを、データ側に着目してデータにそれ自身を操作するメソッドを追加しよう、そうすればデータの修正はデータと付随するメソッドのみになるから保守性上がるねという考え方で、そのために各オブジェクトが疎結合になるようにアクセッサ等が考え出された
そうして先人たちがソフトウェアクライシスを乗り越えたのに、またその時代に戻ろうとしてる愚策 >>62
結局テンプレートがいっぱいできるししかも実装が自明じゃなくなってる
実際answerの引数のパターンもいっぱいあるだろうし
メリットがよくわからない こういうマニアックな会話でも付いて行ける奴がこの時間帯にいるのすげぇ ■ このスレッドは過去ログ倉庫に格納されています