実行側でのコード構造の組み合わせ方 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
アルゴリズムとかデザパタを覚えたりJavaScriptのライブラリを
練習しまくると
・配列や連想配列ほかデータ構造や制御構文、オブジェクト、関数、メソッド、
をどうやって「どうやって組み合わせるか」がなんとなくコツが掴めてくる。
(でもこれらの公式みたいなのは出来上がってなくて、自分と違う組み合わせ方
をしている人のコードを見てしまうと混乱する。)
・つまり、「呼び出し側で変数、関数、配列、制御構文、オブジェクト、メソッド」をどうやって配置するのかって、「絶対の公式」が規定されていないから、組み合わせは 人それぞれなのかな？
→一度変数に保持してからその変数を使う人もいるし、
if文の条件分岐や関数呼び出しの () の中で更に別の式をごっそり詰め込んで
その内部の() の中に更に別の式を詰め込んでしまう人もいる。
配列の[] 内に結構長い式を詰め込む人もいる。
オブジェクトのクラス定義だと、メソッドやコンストラクタに渡す「引数名」
とクラスの「メンバ変数名」が同じで、
メソッド内の内のローカル引数名とメンバ変数がどっちなのか混乱することが
よくある。
・デザインパターンを覚えたことでこれらの組み合わせのコツをなんとなく掴んだが、今度は「複数のデザインパターンを組みわせて」もっと大きなものを作るときの
「組み合わせ方」が上手くつかめない。
・そこで、これらの「組み合わせ方」について議論するスレを立てました。 >>1
もうちょっと議論のテーマをまとめて欲しい
＞「複数のデザインパターンを組みわせて」
＞もっと大きなものを作るときの
＞「組み合わせ方」
これがテーマかな？
あとサンプルコードがないと
具体的にどんなケースなのか分かりにくい >JavaScript
混乱してるようだけどほぼこれが原因 >>2-3
いや俺一人の悩みの相談じゃないよ。
例えば俺の場合だと、結城浩 著者のデザインパターン入門で
23種のデザインパターンを勉強した。
すると演習問題の最後で、GoFの「Interpreter」と「Facade」「FactoryMethod」
を組み合わせたちょっと複雑なプログラムを試しに書いて動かした。
(動いたのでこれ自体に困っているわけではない。)
サンプルコードはクラスのファイルが17クラス分もあって2chに書くと大変だよ。
だけど、これを応用する時単体のパターンではなく「組み合わせ」るという発想はどうすれば
いいだろうと思って、スレを立てた。
パターンだけじゃなく、基本的な関数やメソッドやif文 for文なんかも、
「単発で書く」のは構文を覚えて慣れれば誰でもできるけど、
「組み合わせて目的を達成する」のって結構自分で考えるのが難しくて、
何らかの「お決まりのパターンを真似る」しか無いけど、参考になるものが
いつも簡単に見つかるわけじゃないし、真似ればうまくいくと思ってたのに
実際全然的が外れることもある。
これは別にJavaだろうがJavaScriptだろうが C, Python, シェルスクリプト
関係なくどの言語でも当てはまることだから、それについて議論するスレを
立てたいと思って建てた。 「絶対の公式」みたいな考えをまず捨てる必要がある
アルゴリズムやデザパタを勉強したのならそんなもんあり得ないって理解できるはず
その上でコードをたくさん読んで自分の審美眼を磨いていくといい わかったこうしよう。
いくらプログラミングの基礎の勉強をしても、
「アメブロで自分のアカウントでログインして、他の人のブログのいいね!を
自動でクリックするツールをGUIで他人も使えるようにして、配信して、お金を
入金させる仕組みを作ろう」ってなったときに、
「このライブラリやモジュールを importして、 このクラスやインタフェースを
extends, implementsして、このクラスのインスタンスを委譲で保持して、
こういう配列構造を作って、こういうコンストラクタにして、こういう
メソッドの呼び出し方をして、こういうときは条件分岐して、
こういうときはfor文でループ」
みたいなのがスッと思いつくまでには至っていない。
だから「組み合わせて目標を達成するやり方が分かっていない」という状態。 >>4
パターンの表面だけ見てその背後にある原則を理解してないからでしょ
問題は組み合わせに有るんじゃないと思うぞ >>7
背後にある原則って「リスコフ置換原則」とか「オープン・クローズド原則」
とかそんな感じ？ >>8
それはもう少し抽象度の高い原則だね
デザインパターンの背後にある原則はもう少し実装よりのやつ
「変化する部分をカプセル化する」とか「継承よりコンポジション」みたいな
各パターンについてなんでこのパターンがあるといいのかっていうWhyを理解して
パターン間で共通する設計原則を理解するといいと思う
結城本はそういう部分の説明がないからあまりいい本ではないよ Stoyan Stefanov 著
JavaScriptパターン ―優れたアプリケーションのための作法、2011
オブジェクト指向JavaScript、2012
JavaScriptデザインパターン、Addy Osmani, 2013
今は、GoF よりも、20年以上経っているから、
ほとんどのデザインパターンは、フレームワークが実装していて、
プログラマーが書くことは無い
今は、XML の設定ファイルから、クラスを動的に作る、DI が流行ってる > 今は、XML の設定ファイルから、クラスを動的に作る、DI が流行ってる
DIでXML使うとか何年前だ？
Javaでだってアノテーションを使う
XMLは使わない。
それにクラスは動的に作らない。
いや動的に何も作らない。
インスタンスの生成をDIがやってくれるだけ とはいっても今ならXMLはJSONとかYMLに置き換わるってのは分かるな。
古い本でも、「考え方だけ」は吸収できるなら読んでみてもいいかも。
今のツールは便利すぎて、なんでも自動でやってくれるから逆に
「何やってるかわからない」状態になってるし古い本から学習するのも
悪くはないな。 >>11
XML地獄になってたのはいつの時代だったかな >>10
デザインパターンについて理解したいなら以下の2冊がオススメ
1. Head Firstデザインパターン
2. オブジェクト指向のこころ
どちらも古い本だけど言語に依存しないオブジェクト指向の原則を学べる
各言語でのデザインパターンの使われ方や実装方法、頻出のイディオムみたいなのは
原則を学んでから別の本を当たるといいと思う
(>>11が紹介してるJavaScriptパターンやJavaScriptデザインパターンとかね) 結城さんのJava入門本が親切で分かりやすかったから
昔デザパタ本も買ったんだけどこっちの方は
たしかに原則の説明がぜんぜん無いんだよな
なんでこうなってるのっていう
本が出た当時にそこまで詳しく
自信持って説明できないとかあるかもしれないが
そういう原理原則はやはり元祖の
GOF本の方が圧倒的に詳しい >>6
これはデザインパターンやコードの組み合わせみたいな実装レベルの話ではなくて
実現したいことをコードにするまでに必要な要件定義や設計レベルの話
Amazonの例でスレ立てしてたのと同じ人でしょ？
実現したいことをコンポーネントに分解して考えて
コンポーネント単位の組み合わせで目的を達成できるように考える
コンポーネントへの分解は再帰的に徐々に細部へ向かって行う
家を部屋に分解して考えて、部屋を床・天井・柱・壁・ドア・窓に分解して
柱を素材、長さ、径、接合方法みたいに分解して考えるようなもの
柱の細部が決まれば身につけた木材加工技術をどう使えばいいかイメージできる
ソフトウェアをどういう風に分解して考えればいいかは経験によるところが大きいけど
まずは一般的な設計手法を学んでそれを適用していけばいいと思う
ユースケースを洗い出して機能面から構成要素を整理する方法とかね >>6
1. 自動いいねクリックツール
2. 配信
3. 決済
4. ライセンス管理
1. 自動いいねクリックツール
1-1. アカウント管理
1-2. ブログのURL管理
1-3. 巡回機能
- ログイン機能
- ブログページ遷移機能
- いいねクリック機能
- …
1-4. スケジューリング機能
1-5. …
例えば上みたいに分解して考えて
いいねをクリックする機能だけを考えれば、
DOM要素の取得方法やクリックイベントの発火方法っていう
JavaScriptのプログラミング本読めば理解できる詳細度になるから
どうプログラミングすればいいかわかるでしょ？ >>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モジュールが必要で、アカウントクラスを作ったほうが良さそうというのが見えてくる。 >>19
ナイストライ
分割の切り口や抽象度がバラバラなのがちょっといただけないかな
意識して揃える努力が必要
機能分割は垂直方向の切り口、GUIやDBは水平方向の切り口なので方向が全く違う
それにこのレベルでどういう機能が必要かを考えている時にはGUIやDBみたいな実装の詳細を混ぜるのは良くない
そっちに気が取られて本当に必要な機能を考えられなくなるから。
入力方法や保存方法はもっと詳細段階で検討して決めていけばいい内容
あと機能の単位はユーザーから見てまとまった一つの仕事を最小単位として考えたほうがいい
「アカウントを登録」と「アカウント情報をDBに保存」の違い
DBに保存やDBから取得というコードは必要かもしれないけどそれはプログラム内部の事情
$ add_account <account/email> <password>
$ save_account_to_db
例えばコマンドラインツールで書いた場合に
save_account_to_dbはadd_accountの内部で呼び出されるかもだけど
自分で直接呼び出して使いたいコマンドではないよね
少し細かいと思うかもしれないけど
上で書いたような部分を意識していくと抽象化思考が鍛えられると思うよ >> 20
つまり「引数をユーザーが指定するかしないか」で
コマンドとかメソッドは分割せよってことかな。
下の「save_account_to_db」は、「ユーザが与える引数がない」から、
「ユーザは自分で使いたくない」従って「内部に隠蔽されるべき」であると。
あぁ、でも「ls」みたいなのは例外だね。
引数なしだけど「現在の情報を表示して確認したい。」ものは隠蔽しない
という訳だ。 >>21
コマンドやメソッドの分割につながることはつながるけどそれはここでの本質とは関係ない
それに引数の有無もこの場合ほとんど関係ない
自分の作るソフトウェアの境界がどこにあって
その境界を挟んでユーザーとソフトウェアにどういう抽象度でインタラクションさせたいかが大事
一度命令を覚えさせればほぼ何でもできる使い魔がいるとして、そいつに
「このアカウント情報あとで使うから覚えといて」って命令したいのか
「このアカウント情報をあそこの本棚にある2番目のファイルに綴じといて」って命令したいのかの違い
下の擬似コードみたいに実際のコードでも骨格になる部分は
GUIかどうかやDBかどうかには依存してない
一般的にはそのほうがコードの質も高くなる
「〇〇さんのブログ、いいねをクリックしといて」のコマンド例
$ click_nice <blog_name>
擬似コード例
click_nice(blog_name){
login
visit url[blog_name]
click nice_button if updated
} >>22 あ~それUMLの本とかにそんなこと書いてあったような・・
ちょっと見返してみるわありがとう。
使い魔っていうのはすげえよく分かるわ、たまにコマンドとかライブラリを
さん付けで呼ぶ人要るけど、そんな感じだよね。
自分のやりたいことを2chに書くのは恥ずかしいけどその分、具体的な
アドバイスを貰えるもんだな。参考にさせて頂きます。 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
VXVZ7 ■ このスレッドは過去ログ倉庫に格納されています
