ふらっと C#,C♯,C＃（初心者用） Part130 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
「どんなにくだらない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 同じGetDataメソッドで別のデータ取得させたいのはなんか理由あるのかね
hogeとfugaが抽象化できるならともかく typescriptやjavascriptから流れてきたんだろうな
と勝手に妄想 >>784
戻り値の型だけ違うシグネチャは判定ができないから設定できない 関係ないけど戻り値はインタフェースで返してくれよな >>788
他言語で実現できてるのは戻り値型の共変性ってやつなんやね。
勉強になったわ。ありがと。 本来は継承で解決すべき事柄じゃないものも何でも継承で
解決しようとする 一見>>785でよさそうに思えるが
よくよく考えると使い道が分からん
Base<hoge> と Base<piyo> は違う型になるので
それらを継承したクラス同士も違うクラスから派生しているっつーことで
統一的には扱えなくなる
差分プログラミングがしたいならそれでよいが
なら、Baseクラスのabstractの意味は何だ？ 783ですが、抽象化したテーブルクラスを作って、テーブル単位で選択結果を返す具象クラスを作りたかったのですが、Dapperを使うのでメソッドの戻り値がList<T>となり戻り値の型が具象クラス毎に違っています
こういう例が無さそうということはアンチパターンやってるでしょうか >>795
interface IDao<TEntity, TId> {
TEntity ReadOne(TId id);
IEnumerable<TEntity> ReadPage(int pageSize, int pageIndex);
void Create(TEntity e);
void Update(TEntity e);
void Delete(TEntity e);
}
class FooDao : IDao<Foo> { ... }
これじゃいかんのか？ >>797
テーブルのみを扱うので同様の属性という意味で抽象クラス使ったのですが、インターフェイスで選択したデータを返す機能として定義した方が良いでしょうか
抽象とインターフェイスの使い分けに今ひとつ自信がなくて >>798
使い分ける必要はない
is Aだのcan Aだの言ってたのは昔の話で、今時はどうしても実装を継承する必要がある場合以外は基本的にインターフェースを使う
もっというと、実装継承のために抽象クラスを使う場合はインターフェース継承とは本来区別して考えるべきで、
インターフェース←抽象クラス←具象クラス
という継承関係にするのが理想
抽象クラスはあくまで実装の共通化のためのツールに過ぎない Table<T>を作ってGetData<T>
それ以上の機能を使いたかったら適当なクラスを作ってTable<T>をコンポジション >>799
何が良くてそんなことやってんの?
変更があったら変更すればいいじゃん >>799
それはDIってデザインパターンでしょうか
なんか教科書のインターフェイスと使い方が違うので理解出来なかったのですが インターフェースは、has-a、部品化。車とハンドル。
抽象クラスは、is-a、継承。車と消防車
継承は、クラスに親子関係がある。
非常に似ているもの同士
部品化は、全く異なるもの同士
DI は、XMLなどの設定ファイルから、クラスを自動的に作る、ジェネレーター >インターフェースは、has-a、部品化。車とハンドル。
↑これマジ？
でも>>799では「can A」って書いてあるよ
大マジ？
そんな説、聞いたことないんだけど てかそんな(脳の)状態でプログラム書けるものなの？
C#優秀すぎだろ スッキリわかる Java入門 第2版、2014
Javaの人は皆、この本で、オブジェクト指向を学ぶ。
というか、日本では、この本しか無い
だから皆、C#をやる前に、Javaから勉強する
オブジェクト指向の最初のクイズが、is-a, has-a の例題 >>808
外国人みたい言葉遣いしてんな
いつの間にか2chもグローバル化してたのか
そして謎の熱いjavaのステマ付き で、最初のクイズで間違ってたら、どうしようもなくね？
has-aはコンポジションであってインターフェースは関係ない この人あちこちのスレに突如出現しては的外れで一方的な持論とともに書籍を紹介する変な人だよね
書籍宣伝のボットなんじゃないかという気もするけど、もし人工知能だとしたらかなり優秀だと思う 「たのしいRuby」「みんなのPython」とか、
掌田津耶乃の「はじめてのJavaScript」では、
オブジェクト指向の説明は、数十ページ
一方「スッキリわかる Java入門」では、250ページ！
他を圧倒してる
漏れは、10言語・数十冊以上は読んでる
本を読む順番は、
1. スッキリわかる Java入門
2. たのしいRuby
3. みんなのPython
C# なんかは、後の方 >>812
文法解説ばっかりで作って覚える系の本が無いな
なんか具体的にアプリケーション作れる本があった方がいいんじゃないか? >>812
>10言語・数十冊以上は読んでる
バカじゃねぇの？ java,ruby,pythonの入門書に共通してるのが作って覚える系の本があまりない
javaはandroidのアプリの本が数冊だが出ているがandroidなんだよね
エミュでしか動かせなかったりイマイチ
そういう意味で入門書にはc#をオススメしたい
これならwindowsアプリが具体的に作って動かせるので絶対に初心者にはこちらのがいい
csvやxlsファイルの処理やDB接続の処理が書いてあったりするのもGood スッキリは詳しい説明をはぐらかして初心者を誤魔化そうって思惑が透けて見えんだよね >>812
ちゃんとコテハン登録しとけよ
NG登録しとくから >>806
has-a capability
部品化とは違うけどね UnityのためにC#もちょこちょこ勉強し始めたけど、Javaと大分似てるんだなこれ
本買おうと思ったけど、完全な新規向けのじゃなくて
言語仕様についてわりとがっつり書いてあるような本でお勧めってあります？ 求めているものとは違うかもだけど
だいぶん古いけど
連載 改訂版 C#入門
http://www.atmarkit.co.jp/ait/subtop/features/dotnet/csharp_abc2_index.html
はわりとがっつりC#の文法を網羅的に説明している
筆者の語りはうざいが・・・ Wikipediaでも
has-a
https://ja.wikipedia.org/wiki/Has-a
日本語では集約やコンポジション集約関係を意味する。
って書いてあるからね クラスの機能はできるだけ簡素にを守っていると
is-aでいられるのは本当に基本的なクラスだけになる
普通にやってると絶対has-aの関係になる
継承を有効に使えるのはほんの一部 >>823
c#最新？
で無いなら折角買ってもなぁ >>821
少し古いがCLR via C#
C#やってて読んでないとモグリと言われる一冊 約一年ぶりにプログラミングをしようと思いC#を選らびました
学生の頃にJavaやCは学習したため参考書の購入にあたって相談があります
今はこの三冊から購入を検討しています
http://www.sbcr.jp/products/4797347081.html
http://www.shoeisha.co.jp/book/detail/9784798122205
http://gihyo.jp/book/2017/978-4-7741-8758-7
最後の一冊の購入はほぼ決めているのですが、上の二冊のどちらかを読了した後読もうと考えています
Cのポインタ、Javaのオブジェクト等は理解しているつもりですので、今後辞書のように使えそうな独習C#に傾いています
上記以外でも適切な本やWebサイトがあれば教えていただきたいです。 >>831
独習c#ってc#のバージョン的に最新出てんの? >>831
どれもハズレだな
CLR via C#
まずはこれを読もう >>832
出版日から見るに最新のバージョンには対応していないように見えます
>>833
ひとまずはコンソール上で動くプログラムを作ってみようと思ってます
後々はデスクトップアプリやUnityなどに手が出せるという理由でC#にしました
>>834
英語に疎いおかげで良書でも読めません・・ C#7.1なら本どころかMSDNのリファレンスじゃないと無理だろ
>>831
上に出ているじゃないか>>823
基本部分網羅してあってタダで見られるのだから本買う必要はない >>836
最新版を追うなら本では厳しいということですね
目次を流し見してみましたが確かに入門には十分すぎる内容でした
ここで勉強してから本の購入を検討してみようと思います 今のC#ってgithubで言語仕様決めてるからな
もうプログラミング言語は本で覚える時代じゃない >>838
githubってそんなに活発なんですね
仕様が議論させるとは >>835
"CLR via C#"は和訳本出てるよ。
タイトルは"プログラミング .NET Framework"。
最新のは第4版。 >>840
和訳ありましたか、ありがとうございます
.NETとやらが必要になったタイミングで買おうと思います 書籍もいいがM$燻製のChannel9とかもありじゃね
偶に裏話とかあるし
なんでC#（名称）になったとか（あっ知ってたらスルーね） >>841
.NETが必要じゃないc#の用途の方が珍しいと思われ >>837
えーでも結局誰かが書いたコードを辞書的に調べたいからそういう本欲しいんでしょ?
最新に対応してないのは困るなぁ
タプルとか出てこないね
最近書籍の対応遅いよね >>844
小さなバージョンアップを繰り返すようになったからね
C#開発のメインストリームがWeb系のバリバリな連中の方に移ってしまって、
書籍の主な購買層であったドカタ系が完全に取り残されて新機能に興味を示さなくなってしまったのも大きい >>831
独習とイディオム読んだ独学だけど、一通りの事はできるようになったよ。
api呼んでみたり、データベース連携したりね、
独学やったあと、イディオム読めばええんちゃう？ http://iup.2ch-library.com/i/i1846363-1504354345.png
このプログラムを作りたいんだけど
仕様が
・ルートフォルダ
手入力でディレクトリ先のパスフォルダを削除する事ができる
・参照
押してフォルダを選択してパスをルートフォルダのテキストボックスに表示
start
・クリックするとカレンダーが出てきて、そこから日付を選択
End
・start〜Endの期間の日付フォルダをまとめて削除できる
上記二つはできたけどstart〜endが分からん…
新人プログラマーで入ってまだ4日目なんですが
20時間以上やってるけど全くできない…
みんなこんなの本当にできるの？
入ってすぐ社内ではもう既に無能扱いされてますヾ(｡>?<｡)ﾉ >>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で変更しやすいと言ったのは運用保守フェーズに入ってからの話ね ■ このスレッドは過去ログ倉庫に格納されています
