実行側でのコード構造の組み合わせ方 [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/09/03(日) 02:53:52.62

アルゴリズムとかデザパタを覚えたりJavaScriptのライブラリを
練習しまくると

・配列や連想配列ほかデータ構造や制御構文、オブジェクト、関数、メソッド、
をどうやって「どうやって組み合わせるか」がなんとなくコツが掴めてくる。
(でもこれらの公式みたいなのは出来上がってなくて、自分と違う組み合わせ方
をしている人のコードを見てしまうと混乱する。)
・つまり、「呼び出し側で変数、関数、配列、制御構文、オブジェクト、メソッド」をどうやって配置するのかって、「絶対の公式」が規定されていないから、組み合わせは人それぞれなのかな？
→一度変数に保持してからその変数を使う人もいるし、
　　if文の条件分岐や関数呼び出しの () の中で更に別の式をごっそり詰め込んで
　　その内部の() の中に更に別の式を詰め込んでしまう人もいる。
配列の[] 内に結構長い式を詰め込む人もいる。
オブジェクトのクラス定義だと、メソッドやコンストラクタに渡す「引数名」
とクラスの「メンバ変数名」が同じで、
メソッド内の内のローカル引数名とメンバ変数がどっちなのか混乱することが
　よくある。
・デザインパターンを覚えたことでこれらの組み合わせのコツをなんとなく掴んだが、今度は「複数のデザインパターンを組みわせて」もっと大きなものを作るときの
「組み合わせ方」が上手くつかめない。
・そこで、これらの「組み合わせ方」について議論するスレを立てました。

**デフォルトの名無しさん** · 2017/09/03(日) 03:15:35.12

>>1
もうちょっと議論のテーマをまとめて欲しい

＞「複数のデザインパターンを組みわせて」
＞もっと大きなものを作るときの
＞「組み合わせ方」

これがテーマかな？

あとサンプルコードがないと
具体的にどんなケースなのか分かりにくい

**デフォルトの名無しさん** · 2017/09/03(日) 03:29:04.15

>JavaScript
混乱してるようだけどほぼこれが原因

**デフォルトの名無しさん** · 2017/09/03(日) 03:54:35.42

>>2-3
いや俺一人の悩みの相談じゃないよ。
例えば俺の場合だと、結城浩著者のデザインパターン入門で
23種のデザインパターンを勉強した。
すると演習問題の最後で、GoFの「Interpreter」と「Facade」「FactoryMethod」
を組み合わせたちょっと複雑なプログラムを試しに書いて動かした。
(動いたのでこれ自体に困っているわけではない。)
サンプルコードはクラスのファイルが17クラス分もあって2chに書くと大変だよ。
だけど、これを応用する時単体のパターンではなく「組み合わせ」るという発想はどうすれば
いいだろうと思って、スレを立てた。

パターンだけじゃなく、基本的な関数やメソッドやif文 for文なんかも、
「単発で書く」のは構文を覚えて慣れれば誰でもできるけど、
「組み合わせて目的を達成する」のって結構自分で考えるのが難しくて、
何らかの「お決まりのパターンを真似る」しか無いけど、参考になるものが
いつも簡単に見つかるわけじゃないし、真似ればうまくいくと思ってたのに
実際全然的が外れることもある。

これは別にJavaだろうがJavaScriptだろうが C, Python, シェルスクリプト
関係なくどの言語でも当てはまることだから、それについて議論するスレを
立てたいと思って建てた。

**デフォルトの名無しさん** · 2017/09/03(日) 04:07:12.78

「絶対の公式」みたいな考えをまず捨てる必要がある
アルゴリズムやデザパタを勉強したのならそんなもんあり得ないって理解できるはず
その上でコードをたくさん読んで自分の審美眼を磨いていくといい

**デフォルトの名無しさん** · 2017/09/03(日) 04:07:30.66

わかったこうしよう。
いくらプログラミングの基礎の勉強をしても、
「アメブロで自分のアカウントでログインして、他の人のブログのいいね!を
自動でクリックするツールをGUIで他人も使えるようにして、配信して、お金を
入金させる仕組みを作ろう」ってなったときに、

「このライブラリやモジュールを importして、このクラスやインタフェースを
extends, implementsして、このクラスのインスタンスを委譲で保持して、
こういう配列構造を作って、こういうコンストラクタにして、こういう
メソッドの呼び出し方をして、こういうときは条件分岐して、
こういうときはfor文でループ」

みたいなのがスッと思いつくまでには至っていない。
だから「組み合わせて目標を達成するやり方が分かっていない」という状態。

**デフォルトの名無しさん** · 2017/09/03(日) 04:15:16.16

>>4
パターンの表面だけ見てその背後にある原則を理解してないからでしょ
問題は組み合わせに有るんじゃないと思うぞ

**デフォルトの名無しさん** · 2017/09/03(日) 04:25:07.90

>>7
背後にある原則って「リスコフ置換原則」とか「オープン・クローズド原則」
とかそんな感じ？

**デフォルトの名無しさん** · 2017/09/03(日) 04:57:03.17

>>8
それはもう少し抽象度の高い原則だね
デザインパターンの背後にある原則はもう少し実装よりのやつ
「変化する部分をカプセル化する」とか「継承よりコンポジション」みたいな

各パターンについてなんでこのパターンがあるといいのかっていうWhyを理解して
パターン間で共通する設計原則を理解するといいと思う
結城本はそういう部分の説明がないからあまりいい本ではないよ

**デフォルトの名無しさん** · 2017/09/03(日) 05:55:16.95

>>9
じゃあどんな本がおすすめですか？

**デフォルトの名無しさん** · 2017/09/03(日) 07:01:50.47

Stoyan Stefanov 著
JavaScriptパターン ―優れたアプリケーションのための作法、2011
オブジェクト指向JavaScript、2012

JavaScriptデザインパターン、Addy Osmani, 2013

今は、GoF よりも、20年以上経っているから、
ほとんどのデザインパターンは、フレームワークが実装していて、
プログラマーが書くことは無い

今は、XML の設定ファイルから、クラスを動的に作る、DI が流行ってる

**デフォルトの名無しさん** · 2017/09/03(日) 07:48:03.86

> 今は、XML の設定ファイルから、クラスを動的に作る、DI が流行ってる
DIでXML使うとか何年前だ？

Javaでだってアノテーションを使う
XMLは使わない。

それにクラスは動的に作らない。
いや動的に何も作らない。

インスタンスの生成をDIがやってくれるだけ

**デフォルトの名無しさん** · 2017/09/03(日) 07:58:18.36

とはいっても今ならXMLはJSONとかYMLに置き換わるってのは分かるな。
古い本でも、「考え方だけ」は吸収できるなら読んでみてもいいかも。
今のツールは便利すぎて、なんでも自動でやってくれるから逆に
「何やってるかわからない」状態になってるし古い本から学習するのも
悪くはないな。

**デフォルトの名無しさん** · 2017/09/03(日) 11:21:57.76

>>11
XML地獄になってたのはいつの時代だったかな

**デフォルトの名無しさん** · 2017/09/03(日) 15:23:45.09

>>10
デザインパターンについて理解したいなら以下の2冊がオススメ
1. Head Firstデザインパターン
2. オブジェクト指向のこころ

どちらも古い本だけど言語に依存しないオブジェクト指向の原則を学べる
各言語でのデザインパターンの使われ方や実装方法、頻出のイディオムみたいなのは
原則を学んでから別の本を当たるといいと思う
(>>11が紹介してるJavaScriptパターンやJavaScriptデザインパターンとかね)

**デフォルトの名無しさん** · 2017/09/03(日) 15:50:10.73

結城さんのJava入門本が親切で分かりやすかったから
昔デザパタ本も買ったんだけどこっちの方は
たしかに原則の説明がぜんぜん無いんだよな
なんでこうなってるのっていう

本が出た当時にそこまで詳しく
自信持って説明できないとかあるかもしれないが
そういう原理原則はやはり元祖の
GOF本の方が圧倒的に詳しい

**デフォルトの名無しさん** · 2017/09/03(日) 16:57:51.40

>>6
これはデザインパターンやコードの組み合わせみたいな実装レベルの話ではなくて
実現したいことをコードにするまでに必要な要件定義や設計レベルの話
Amazonの例でスレ立てしてたのと同じ人でしょ？

実現したいことをコンポーネントに分解して考えて
コンポーネント単位の組み合わせで目的を達成できるように考える
コンポーネントへの分解は再帰的に徐々に細部へ向かって行う

家を部屋に分解して考えて、部屋を床・天井・柱・壁・ドア・窓に分解して
柱を素材、長さ、径、接合方法みたいに分解して考えるようなもの
柱の細部が決まれば身につけた木材加工技術をどう使えばいいかイメージできる

ソフトウェアをどういう風に分解して考えればいいかは経験によるところが大きいけど
まずは一般的な設計手法を学んでそれを適用していけばいいと思う
ユースケースを洗い出して機能面から構成要素を整理する方法とかね

**デフォルトの名無しさん** · 2017/09/03(日) 17:08:39.98

>>6

1. 自動いいねクリックツール
2. 配信
3. 決済
4. ライセンス管理

1. 自動いいねクリックツール
　1-1. アカウント管理
　1-2. ブログのURL管理
　1-3. 巡回機能
　　　　- ログイン機能
　　　　- ブログページ遷移機能
　　　　- いいねクリック機能
　　　　- …
　1-4. スケジューリング機能
1-5. …

例えば上みたいに分解して考えて
いいねをクリックする機能だけを考えれば、
DOM要素の取得方法やクリックイベントの発火方法っていう
JavaScriptのプログラミング本読めば理解できる詳細度になるから
どうプログラミングすればいいかわかるでしょ？

**デフォルトの名無しさん** · 2017/09/04(月) 01:11:23.53

>>6
その例を作る時に自分がどう考えるかを以下に書くと

まず
1. いいね！を自動でクリックする仕組み
2. GUI
3. お金を入金させる仕組み
くらいに分割してそれぞれの部品を作って組み合わせようと思う。

ここで、それぞれの部品ごとに更に細かく分割できるものは分割していく。
例えば1は
1-1. 自分のアカウント情報を取得する(GUIから？データベース？)
1-2. 自分のアカウントでログインする
1-3. 特定の記事の「いいね！」を押す
のように分割。

1-1.でアカウント情報を取得するけど、初回はGUIで入力させて
次回からは自動ログインさせたいなと思えば、

1-1-1. 初回の場合は以下を実行
1-1-1-1. GUIからアカウント情報を取得
1-1-1-2. アカウント情報DBに保存
1-1-2. DBからアカウント情報を取得

というようにブレークダウンしていく。

1-1-2. DBからアカウント情報を取得
くらいまでいけば、DBモジュールが必要で、アカウントクラスを作ったほうが良さそうというのが見えてくる。