ふらっと C#,C♯,C＃（初心者用） Part130 [無断転載禁止]©2ch.net
レス数が900を超えています。1000を超えると表示できなくなるよ。
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください
>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part129
http://mevius.2ch.net/test/read.cgi/tech/1497000961/
■関連スレ
C#, C♯, C＃相談室 Part94 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1492843013/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/
■情報源
https://msdn.microsoft.com/en-us/library/gg145045.aspx
http://referencesource.microsoft.com/
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured >>847
そりゃそうだよ
無能に決まってるじゃん
そんな問題は10分でできるようになってから入社するのが世界の常識
日本は非常識だから素人でも雇っちゃうけどね >>848
やっぱそーなんですねぇ(´・ω・`)
日曜日1日使って、出来なかったら
向いてないので退職してきます
有難うございます >>847
日付でなく例えば連番で１００から１０００までならできるよな？
日付をDateTimeにして同じようにやればいい
比較演算子普通に使えるし
https://msdn.microsoft.com/ja-jp/library/system.datetime.compare(v=vs.110).aspx
でもいいし好きなほうで >>847
「C# Forms カレンダー」と「C# ファイル 削除」でググれ >>842
C#に決まった由来は気になるので時間あるときにみてみます
>>843
となると遅かれ早かれ必要になりそうですね
学ぶタイミングが難しい気もしますが
>>844
もともとその用途で購入を考えてましたが周りの方が言う通り
ネットの恩恵に預かろうかと思います
>>846
参考になる経験談ありがとうございます
WEBの勉強で不足を感じたら独習→イディオムのように勧めていこうかと思います >>847
勉強の基本なんだけど。
「分からない」時にはなにが分からないかを列挙して、それをさらに細かい要素に分解していく。
分解して考えれば・調べれば分かるようになったら、それをひとつひとつ解決していく。
847 を読んでもなにが分からないのかこちらに伝わらない。
つまり自分でなにが分からないのか分かってないんでしょ。
もっと整理してみたら？
ちなみに新人というか数年程度のヤツにそんなたいしたことは求めてない。
きちんと適切な質問を出来るようになればそれで OK だと思うよ。(ちょー難しい要求だが)
特に１年目なんて、なにを聞いても許される二度とない重要な期間なんだから、それを有効活用しない手はない。
最悪なのは自分で抱え込んでなにも進まない状態だよ。 >>849
今できることよりも
継続して勉強できるかどうかのほうがずっと大事
1~2年継続して勉強すれば周りのやつ全員追い抜けるよ
ただし基礎的な能力が高いやつに限るが
(論理的思考力、自然言語能力、メタ認知能力等) >>849
>>853のアドバイスをよく聞くといい
自然言語能力・メタ認知能力をある程度身につけてる良い手本
勉強の仕方を勉強すること 無能な働き者に分類される人は自然言語に傾倒しがちだよね
ダラダラと長く曖昧でわかりにくい文章が数式なら僅かな記述で明確に表現できることもある
理解するのに時間がかかる難解な文章が図表なら瞬時に把握できることもある
もちろん自然言語を全て否定する訳ではないがバランス感覚は大事なんだな
自然言語はあくまでツールのひとつ 最近、イディオム買って読んでるけど、この本読んでる方って多いんでしょうか？
独習C♯読んでから、独学で色々とプログラム作ってましたけど、
OOPの考え方とかまったく知らないでやってたもので、コードが散らかってます
staticおじさんになってたり、クラス分けても結局再利用しないような内容、関数コピペ
メインメソッドから分離してるだけで、メインメソッドに膨大な量書いてるのと大差無い感じです
再利用の仕方とか勉強する為にイディオム本どうかなって見ましたが、みなさんはどの様に覚えたんでしょうか？ >>849はまだ入って4日目だろ
こんなツール作らせてる教育環境がどうかしてるんじゃないの？ >>860
せめてツール作らせるなら段階的にやらせるわな
クラスやメソッドの組み合わせ考えずに、とりあえず出来ましたで終わりそう >>859
再利用は出来れば良いね程度の気持ちで
クラス分けの目的は色々あるけど主に責務の分割な
例えばパソコンに暖房がついてたら嫌だろ
持ち運びもできず
夏場は邪魔になるだけ
暖房機能が壊れたら壊れてないパソコン部分もまとめて修理に出さないといけない
普通と勝手が違うから暖房の起動方法がわからない(セットのパソコンでコントロール？リモコン？)
パソコンを拡張したいけど暖房機能を壊してしまわないか不安になる
問題だらけだ
だからパソコンとエアコンに責務を分けようってわけ
これなら先に挙げたようなアホくさい問題が全部解決するだろ >>863
機能の分離でクラス分けすると今度は必要なクラス探すの大変になる感じですかね？
後はどこまで繋げてどこから分離するかも中々難しく感じます
例えばエアコンのコレクションを扱うとして、エアコンの寒暖房機能、温度検知機能、タイマー機能、設定
などエアコンの中を細かくするのが苦手なんですよね
自分がよく作るのは株価を扱うプログラムですが・・・ >>863
どうでもいいがテレビデオを思い出した
>>864
>中を細かくするのが苦手なんですよね
それはクラス設計つーより、要件定義の段階でないの
要件が明確なら、作るべきクラスも自然に決まって来るっしょ >>864
オブジェクト指向設計の本質は、設計を人間の感覚に合わせることだよ
分けることを目的にしたらダメ
人間の直感は設計の指針として明確でわかりやすいし、
オブジェクトの単位が直感に合っている限りは破綻しない(というか、少々無理が出ても破綻したように感じない) >例えばパソコンに暖房がついてたら嫌だろ
俺もそう思っていた時期があったけど
Skylake-XとVEGAの組み合わせだと真剣に暖房かもしれない
こういうのも出るし
https://www.apple.com/jp/imac-pro/
後、質問者に何か助言できるなら、オブジェクト指向はそんなに真剣にしなくてもよいよ
大事なのは手続き型プログラミングが
・データ構造
・制御構造
という二大要素で出来上がっていることに気づくこと
データ構造とアルゴリズムともいう
データ構造と制御構造をそれぞれ別々に思い描いて
その上で、データ構造と制御構造の両方を持つ「class」に分割するには
何処で切り分けたら一番「制御構造の見通しが良いか」を考える
大事なのは制御構造について意識することで、というのもオブジェクト指向でやると
データ構造の方は勝手にきれいになるから意識する必要はないのでね
C#のasync/awaitも制御構造をきれいに保つための仕組みだしね
最近の流行りというか、流れ、トレンド なんであまりオブジェクト指向に肩入れしていると
この人はややこしい人だと思われる風潮
オブジェクト指向設計というのは
制御構造とデータ構造という二つのものを考えて
小分けにしてclassという一つのものにまとめる作業
と考えていいと思うよ
二つのものを綺麗に切って一つにして小分けにするのは
高度な作業かもしれないけど、十や百じゃなくて高々二つなんで
まぁ慣れです >>866
設計書を表現することだろ?
直感は人間同士でズレる
過去の自分とも 実装レベルの設計とドメインのモデリングの話がごっちゃになってる気がする
ドメインモデルはまず人間の感覚から入って、そこから実装に落としていく段階で制御構造の観点を入れていく感じだね ありがとうございます
OOPの人間の感覚に合わせる意識が大事であって、分けることを目的にしないってのは大事だなって思います
難しいですが・・・
そういう意味だと、プログラムを少し修正したい、機能追加したいって思った時にバグが出にくい、追加しやすい状態にしたいですね
OOPに拘りは特に無く、あくまでソース管理や生産性の向上が目標です
曖昧な目標なので、実現するための手段で手こずってますが
自分の作るプログラムは目的上、同じデータから色んな値を作ったり検証させるので、使いまわせるところは汎用性がほしいんですよね
毎回別のプログラム作るたびにプロジェクト作って一部関数使いまわし、既存プロジェクトのクラス参照で使ってますが、
いつの間にかプロジェクト別で関数が別物になってしまったり、参照クラスの仕様変更で他のプロジェクトに影響出たり、設計が大変なので・・・ >>847
いまいるおっさんたちは就職する時点でアマチュアプログラマ歴10年以上だよ
新卒でプログラミング経験なしだと無能扱いされて当然
まずは答えを見つけて写経しろ
ペンでもキーボードでもいいから丸暗記するまで書き写せ
話はそれからだ
ちなみにベテランだったら30秒ぐらいで作るぞ コントロールを配置するだけで30秒はかかるんだけど 高校から始めたから、新卒時点で10年以上では無かったな
大学から始める様な人もいるし、適当言い過ぎだろ
新卒未経験は流石に、採用されてもPGじゃなく別部署に回される気がするが 新人は研修する前提だから最初からそんなに高度なことはできなくてもいい
実験データのテキスト読み込んでデータベース化しましたとか
サークルのWebサイトをメンテナンスしてましたとか
論文書くために自力でLinux TeX環境整えましたとか
エロ画像収集ツール自作しましたとか
そういう学生らしい微笑ましいIT体験談を聞ければ充分
あとはやばそうな精神疾患とか障害がなければ合格だね
ただし
何にもしてこなかったけど興味と熱意はありますってやつと
エクセルでマクロ組んでましたをやたら強調する意識たかそうなやつ
プログラムは書かないけどITパスや基本情報をアピールするやつ
これは地雷なのでその場で不採用にチェックします あと彼女いないやつは不採用だな
あれは人間として駄目すぎる 「ぼくにとってはコンパイラが彼女のような存在でした」 オブジェクト指向はプロジェクトが大きくなるほどベストの設計は存在しないんじゃないかと思う
ベストを目指しベターを繰り返していくけど結局正解はないと思い知らされる 成果物に問題がなくて、そこそこ保守性が良ければ
無理にベストを目指す必要も無いからね
ベターをベストにする労力を掛けるより、
その労力で別の事をした方がいい >>879
そういうものだよ
だからカイゼンを繰り返せるように設計する
最悪な設計は間違った設計ではなく変更が難しい設計
現代のOOPの常識だね 変更のしやすさって開発スタイルに依存するからなあ
システムを作る側とそれを利用する側とで責任が分かれてる体制下においては、
綺麗なドメインモデルを継続的に改善し続けるなんて不可能
ひたすらコントローラでSQLを垂れ流す方が遥かに変更しやすい 長大で無数のSQLなんてメンテしたくないよ
リポジトリパターンにしておけば1時間もかからない仕様変更に何日もかかるようになる
テストの工数も考えると辟易するね >>882
コントローラーでSQL垂れ流しって時点で、UnitTest考慮ゼロだな 設計フェーズでちゃんと客と握ってれば仕様変更は客に相応のコストを請求すればいいでしょ
変更にかかる工数はトランザクションスクリプトなら高精度で簡単に見積もれる
変更しない前提ならテストなんか画面でポチポチしてExcelにスクショ貼り付けた方が早い
>>882で変更しやすいと言ったのは運用保守フェーズに入ってからの話ね 簡単に変更コスト見積れるトランザクションスクリプトのシステムなんて見たことないな
どこで何をやってるかすぐにはわからない
SQLが酷いと優しく言っても地獄 > だからカイゼンを繰り返せるように設計する
思いつきで仕様決める奴の理想。現実は一度決めた仕様を捨てることは困難。 >>887
仕様と実装の区別も付かないあたり初心者スレらしくて微笑ましい List<int> suuji に入ってる一桁、数百の整数リストを3個ずつに纏めて新たなList<int> suujibunkatuに入れる作動を希望
C#の仕組みを理解するためにいろいろな方法を試しています
以下ソース
List<int> suuji = new List<int>();
//この後、suujiにはLoopで回した一桁の数字が数百入ります
List<int> suujibunkatu = List<int>();
foreach (var unit in suuji.Chunks(3))
{
Console.WriteLine(unit);
suujibunkatu.Add(unit);
}
//以下ネットからコピペした拡張メソッド
public static class Extensions
{
// 指定サイズのチャンクに分割する拡張メソッド
public static IEnumerable<IEnumerable<T>> Chunks<T>
(this IEnumerable<T> list, int size)
{
while (list.Any())
{
yield return list.Take(size);
list = list.Skip(size);
}
}
} やりたいことはforeachの中でList<int>suujibunkatu に三個ずつに纏められたunitの中身を次々に入れていく作動です
ここで、以下のエラーがでます
引数 1: は 'System.Collections.Generic.IEnumerable<int>' から 'int' へ変換することはできません。
場所はsuujibunkatu.add(unit)のunitに赤線になります
引数1 はList<int> suujiの最初の数字である1だと思います。
どうやって解消したら良いでしょうか？
unitに入ってるのがint[]のような配列だと思うのですが…それが原因なのかもわかりません
int[]に入ってる配列をint化する必要があるという感じでしょうか？
拡張メソッドの中身はまだ理解できてないので、拡張メソッドの方を改造しない方向で、のちのち拡張メソッド内を把握していこうと思っています
3つずつまとめる他の方法は出来るのですが、この拡張メソッドの中身を把握するために、使う部分でのエラーをなくしたいと思ってます
よろしくお願いします >>890
List<int> suujibunkatu = List<int>();にint[]をAddしようとしてエラーになってる
3つずつ格納するならList<int[]>にしないと エラーメッセージに全て書いてあるのに何で読まないんだろ >>891
うぉぉおできました
ありがとうございました
なるほど… リスト入れ子で使ってたけど、最近はクラスで中身決めてから使うようにしてます・・・ ディクショナリリストリストディクショナリディクショナリリストリスト… 女性客はリストの演奏で興奮のあまり失神者多発だったからなあ 練習でコンソールアプリケーションで迷路のようなのを作ってます
開始からゴールまでの時間を表示することはできたのですが、これを毎回記録しつつ、あなたは○○秒です～現在○位です！
のようなランキングを表示できたらと思ってますが、どのような方法が考えられるのでしょうか？ >>906
MySQL使ってDB構築してるわ
DB構築、そこからプレイヤーのidをキーに保持して、秒を保存すればええんでね？
ランキングはListとかでソートしてインデックス＋1で表示
同率とかの処理必要ならメソッド作る感じで
オススメのDBはよく分からないけど >>906
1. 記録はファイル出力/ 順位表示時に毎回ソート
2. SortedList等を使って記録時にソート済みでファイル出力、起動時等にSortedListの構築が必要
3. DBに記録、順位表示はDBからソートした結果を取得して表示
自分だけでプレイするのなら1で十分だと思うが
練習なら上から順番にやっていくのでもいいかもね
DB使うならSQL CEかSQLiteかな ブラウザに記録する、Web Storage
どこかのサイトのランキング・サービスとか つか、その程度のデータならｘｍｌかjson使ってクラスをシリアライズするのが良いよ 適当なBaaS使うのが簡単だろうね
やる気があればAWSで API Gateway + Lambda + DynamoDB ならほぼメンテナンスフリーで余裕で無料枠に収まる ① 記憶媒体からデータを読み込む。読み込んだ順番を保ちつつリストを作成する
② ゲーム開始→終了
③ ①のリストの先頭から見て行き、新しい記録より大きい要素の１つ前に挿入する。(挿入した位置が順位)
④ 表示処理
⑤ リストデータを記憶媒体へ書き込む
ソートは不要。
DBを使う要件がないのであれば記憶媒体はtxtファイルで十分。 >>906
テキストファイル名に名前秒数を適当な区切りを入れて保存
山田,60,田中,75,伊藤,81.scr
エクスプローラーからF2で編集可能
エディタもいらない
もちろんファイル名に使えない文字はあらかじめ除外だ ネットを見ていたら、インターフェースで依存性を排除するコードが
例として出ていたのですが「コンストラクタでengineに実装を注入する」とある部分は、どのように書けるのでしょうか？
インターフェースには実装が書けず、コンストラクタでメソッドを書くこともできないので見当がつきません
よろしくお願いします
public interface Engine
{
void start();
}
public class Car
{
public Engine engine;
public Car()
{
// コンストラクタでengineに実装を注入する
}
public void go()
{
engine.start(); // <- Engineはインターフェースなので依存性がなくなった
}
} Engineインターフェースを実装したエンジンのインスタンスを
何らかの手段で手に入れてengineに代入しろってことだな
つまり、君の買った車にはエンジンが付いてないので
買ってくるか、自分で作るか、好きにしてもらったらよいが
エンジン作る部分までは説明しないよ、ってことだな >>915
CarはEngineに依存してるよ
インターフェース使えばEngineの実装には依存しないようにできるけど
インターフェースなので依存性がなくなったというのは認識として間違ってると思う
んで実装を注入する方法はいくつかあって、例えばコンストラクタ・インジェクションなら
Carインスタンスを生成するときにEngine実装のインスタンスを渡してあげるイメージ
public Car(Engine engine) >>915
依存性云々はとりあえず今は聞き流して、インターフェイスの使い方を覚えるのがいいねw >>915
基本的にフィールドをpublicにしちゃだめ
メソッド名はPascal
質問とは無関係だけど >>915
なんで依存性を無くしたいの?
変更が必要になったら変更に必要なお金を貰えばいいじゃない?
君が依存性を無くした機能が将来的に役に立つ可能性は100%なの？ >>921
こういう質問からズレた的はずれなこと言うやつってどこにも湧くよな
yahoo知恵袋とかにも多いけど 初心者スレだし
意味のないことをやってる人間を止めるのも優しさだろ
明らかに意味がない >>921
将来保守される保障あんの？
で、突き詰めたらメインメソッドだけで良いという結論に行き着きそうだな >>924
実際、機能10個作って10年で内３つしか変更が入らないときって
残りの7つに費やした依存性解消の時間って無駄じゃね?
いつ精算できんの？
変更することになってからゆっくり金貰って変更すればいいよ
予めやっておく必要も金も時間も欠片もない >>921
え？ユニットテストしないの？
まじかよ >>915 を書き直すとこういう感じだろうか
public class Car
{
private Engine engine;
public Car(Engine engine)
{
// engineのインスタンス生成は外部で行い、
// その参照をEngineインターフェースの変数として保持する
// （渡されたクラスにEngineインターフェースが実装されているか
// どうかしか感知しない）
this.engine = engine;
}
public void go()
{
// コンストラクタで渡されたEngineを使うので、
// インスタンスの実装には依存しない
// （実際に渡されるクラスで変更があっても、
// それがEngineインターフェースに関わらない部分なら影響がない）
engine.start();
}
}
あと、↓に従ってくれると、他の人からも読みやすい
インターフェイスの名前付けのガイドライン
https://msdn.microsoft.com/ja-jp/library/cc433279(v=vs.71).aspx
"インターフェイス名には、この型がインターフェイスであることを示すために、プリフィックス I を付けます。"
メソッドの名前付けのガイドライン
https://msdn.microsoft.com/ja-jp/library/cc433282(v=vs.71).aspx
"Pascal 形式を使用します。" >>927
命名規則持ち出すんなら、メソッド名もPascalにしろよ
それからフィールドはreadonlyにして_engine、thisは消せ >>926
依存先を先に作ればいいだけだよ
まさかDI使うプロジェクトは作るクラス全部疎結合にするとでも思ってるのか? 下位のモジュールを結合した状態で単体テストするのはおかしなことではないでしょ
MSだって普通にクラスの中でnewしてるよ
見境なくDIすると結合したときとのギャップが大きくなりすぎる
○○サービスと呼べるような粒度の低いクラスだけにとどめるのがいいと思ってる >>930
こいつUnitTestしたことないだろ 粒度も基準としてはあるが
自前のコードで完全に制御できないものはどこかで注入したほうがいいな
注入は別にインターフェースでなくてもいい
単にoverrideでもdelegateでも用途(今の文脈だとユニットテストか)に合えば良い
古い言語だとテスト用のモジュールをリンクしたり
マクロやインクルードで注入することもある >>934
単体テストと結合テストの違いはテストケース
単体でも通るテストか、結合してないと通らないはずのテストか、それだけのこと
開発順序の都合とかネットワークに依存しててクソ遅いとか意図的に発生させるのが難しいエラーがあるといった特別な理由がない限り、
単体でも通るテストを結合して動かすことはなんら単体テストの意義を損なうものではないよ 職場はユニットテスト何それ？だから1メソッドが数百行どころか千行超えるコードざらに見かけます・・・ >>936
結合してテストして失敗したら
テスト対象が悪いのか依存先が悪いのか切り分けが面倒だろ
やれやれだぜ >>939
よく考えよう
それ結合テストで起きる問題を先送りにしてるだけだろ?
むしろ単体テストレベルで見つかったほうが範囲が絞られてる分原因を特定しやすいよね ﾜｯﾁｮｲ b769-ZN1Y)
ﾜｯﾁｮｲ 236e-nkYL)
ﾌﾞｰｲﾓ MM26-nkYL)
ｗ >>938
わかる
汎用機型のプログラミングから抜け出せなかった企業はこれからどんどん終わってくよね >>926
それしないとユニットテストってできないの?
無駄なことやってない?
使い方知らないの? 質問者そっちのけで盛り上がってるねw
>>915が読んだ記事の著者のいう依存性の排除っていうのは恐らく、
Enineのコードが修正されてもCar側のコードがその影響を受けないようにする、
っていう程度の意味。（CarとEngineは別の人やチームが書いてると考えて）
そのための手段として、Carのコードでは具体的なクラスEngineではなく、
Car側のコードを書いている人、または第三者が定義したIインターフェイスEngineを使い、
EngineにはIEngineの実装を強制する。
そうすればEngineを書いている人はIEngineによって拘束され、
Car側（Engineを使う側）のコードが動かなくなるような変更はできなくなる。
まあたぶんこんな感じ。
だけど、下位の側のコード（この場合はEngine）を拘束するために
わざわざインターフェイスを使って抽象度を上げる（つまり可読性は下がる）必要が
本当にあるのかは、個人的にはかなり疑問。鶏を割くのに牛刀を使う感がある。
まあ質問者に確実に言えるのは、上にも書いたけど
依存性云々なんて理解しなくても問題ないから安心して読み飛ばしていいよってことw 依存性をどっかで断ち切らないと、変更の影響が波及し過ぎるからだよ
その例で言うなら、Carの実装内容がEngineに直接依存してると
Engineを修正した時に、Carも修正しなくちゃならなくなるので、それを断ち切りたい訳だ
実際には、その2クラス間にしか依存関係が発生しないなら纏めて修正でもそこまで困らないんだけど
クラスAにクラスBが依存、クラスBにクラスCが依存、クラスCにクラスDが依存……って連鎖してく様な形になってると最悪で
クラスAを修正した結果、クラスB～Dも全部修正とかになる可能性がある レス数が900を超えています。1000を超えると表示できなくなるよ。
