C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[6]: Listを使ったクラスへのアクセスについて


(過去ログ 148 を表示中)

[トピック内 19 記事 (1 - 19 表示)]  << 0 >>

■86386 / inTopicNo.1)  Listを使ったクラスへのアクセスについて
  
□投稿者/ MTK (1回)-(2018/01/25(Thu) 11:38:40)

分類:[C#] 

2018/01/25(Thu) 11:49:32 編集(投稿者)
2018/01/25(Thu) 11:48:44 編集(投稿者)

C# VS2015を使用


初投稿させて頂きます。
C#を2週間前から始めて、まだまだひよっこプログラマです。
現在、フォーム上に複数の機能のボタンを設置、管理するプログラムを作っています。
ログインユーザの権限情報により、どのボタンを表示するかが変わります。
そこで、以下のような構成でプログラムを作成しています。


Menu.cs (ボタンの情報を入れています 簡単な内容なので中身は省略)
 ・buttonBasicクラス(すべてのボタンのスーパークラス)
 ・buttonAクラス(buttonBasicクラスを継承)
 ・buttonBクラス(buttonBasicクラスを継承)
 ・buttonCクラス(buttonBasicクラスを継承)
    ・
    ・
    ・


MenuManager.cs(上記ボタンクラスをまとめて管理する)

 // 各ボタンに数字を付けて管理
 public enum buttonEnum
 {
  BUTTON_A = 0,
  BUTTON_B = 1,
  BUTTON_C = 2,
  BUTTON_D = 3,
  BUTTON_E = 4
 }

 class menuManager
 {
  private List<buttonBasic> mainMenus;


  public menuManager()
  {

   // 上記ボタンの内、ユーザ権限に合うものだけをListにする
   foreach (int n in Enum.GetValues(typeof(buttonEnum)))
   {
    if(権限チェック)
    {
     //【ここが問題!!!】
     mainMenus.Add( createButton(n) );
    }
   }
  }

  // 引数に対応するボタンのインスタンスを生成して返す
  private createButton(buttonEnum type)
  {
   switch(type)
   {
    case buttonEnum.BUTTON_A:
     return new buttonA();
    case buttonEnum.BUTTON_B:
     return new buttonB();
       ・
       ・
       ・
   }
  }
 }



上記プログラムの【ここが問題!!!】の部分で質問です。
ユーザの権限によって、必要なボタンをListに追加しています。
ただ、Addで追加していくと、後で「buttonCにアクセスしたいな」と思った時に
Listの何番目にあるのかが分かりません。

Addじゃなくてinsertを使ってmainMenus.insert( n, createButton(n) );
という追加方法にすれば、buttonCにアクセスしたい場合はmainMenus[buttonEnum.BUTTON_C]とアクセスすればいいかなと思いましたが
これは結構危険な実装になってしまうのではないかな?と不安です。

こういうことをしたい場合、どのように作るのが良いのでしょうか?
また、上記のプログラムの構成についてもご指摘頂けると嬉しいです。
(例えばcreateButtonメソッドはmenuManagerクラス内じゃなくて、各ボタンクラスに作るべき?など)
つたない説明で申し訳ないですが、よろしくお願いします。
引用返信 編集キー/
■86387 / inTopicNo.2)  Re[1]: Listを使ったクラスへのアクセスについて
□投稿者/ shu (1082回)-(2018/01/25(Thu) 14:30:12)
No86386 (MTK さん) に返信

> 上記プログラムの【ここが問題!!!】の部分で質問です。
> ユーザの権限によって、必要なボタンをListに追加しています。
> ただ、Addで追加していくと、後で「buttonCにアクセスしたいな」と思った時に
> Listの何番目にあるのかが分かりません。
>
何かキーとなるものがあるのなら
Dictionaryを使われた方がよいです。

引用返信 編集キー/
■86388 / inTopicNo.3)  Re[1]: Listを使ったクラスへのアクセスについて
□投稿者/ 魔界の仮面弁士 (1550回)-(2018/01/25(Thu) 14:45:33)
No86386 (MTK さん) に返信
>  ・buttonBasicクラス(すべてのボタンのスーパークラス)

「名詞+形容詞」の語順のクラス名に違和感があります。

クラス名が Pascal 形式ではなく camel 形式の命名ルールになっている点も
あまり C# っぽくは無いですね。
https://msdn.microsoft.com/ja-jp/library/ms229043.aspx


なお、このクラスがスーパークラス専用で設計されている場合は、
「class buttonBasic」ではなく
「abstract class buttonBasic」となるのが良いでしょう。


> そこで、以下のような構成でプログラムを作成しています。

そことなく不自然さは感じますが、
細かい仕様が分かっているわけではないので、
この設計が妥当かどうかは判断できかねます。

ただ少なくも現状のコードでは、mainMenus のインスタンス生成が漏れているので
NullReferenceException 例外で停止してしまうことになるでしょうね。


> public enum buttonEnum
> private List<buttonBasic> mainMenus;
> ただ、Addで追加していくと、後で「buttonCにアクセスしたいな」と思った時に
> Listの何番目にあるのかが分かりません。

せっかく列挙体にしても、List 内の位置で管理される仕様にしてしまっては、
マジックナンバーによる管理と代わらないですし、使い難いかと思います。

たとえば「List<buttonBasic>」という部分を
「Dictionary<buttonEnum, buttonBasic>」に
変更してみるのは如何でしょうか?

そうすれば、利用時には
 // A を非表示にする
 mainMenus[buttonEnum.BUTTON_A].Hide();
とか
 // B を保持しているかどうかを確認する
 if(mainMenus.ContainsKey(buttonEnum.BUTTON_B))
とか
 // mainMenu に割り当て済みの buttonEnum の一覧を得る
 buttonEnum[] keys = mainMenus.Keys.ToArray();
とか
 // mainMenu に割り当て済みの buttonBasic の一覧を得る
 buttonBasic[] buttons = mainMenus.Values.ToArray();
とか
 // Visble プロパティが true なボタンだけを取り出す
 buttonBasic[] buttons = mainMenus.Values.Where(bs => bs.Visible).ToArray();
とか
 // mainMenu に割り当て済みの情報をすべて列挙する
 foreach (var entry in mainMenus)
 {
  buttonEnum key = entry.Key;
  buttonBasic button = entry.Value;
  // (ここに処理を記述)
 }
といったことができます。


> private createButton(buttonEnum type)
「private buttonBasic createButton(buttonEnum type)」
にしないと文法違反ですよ。(static でも良いかな)
引用返信 編集キー/
■86389 / inTopicNo.4)  Re[2]: Listを使ったクラスへのアクセスについて
□投稿者/ yummy (1回)-(2018/01/25(Thu) 14:56:07)
2018/01/25(Thu) 15:50:21 編集(投稿者)

以下の内容によっても、対応方法は変わると思います。

・何のためにListを使うのか?
・buttonA, B, C等に分ける理由は何か?
 (権限で分けているのか、単にボタン機能別だけなのか)
・例えば、buttonAクラスのインスタンスは複数存在しうるのか?(buttonB, buttonC等も同様)
・後でList内のボタンの参照が必要となるのはどのような場合か?
 また、何を以てそのボタンを特定するのか?

後でボタンを参照する場合、ボタンの特定方法(例えば、ボタンクラスの何らかのプロパティ等で判断)
があれば、それを利用してListのFindを利用するのも一つの方法だと思います。
引用返信 編集キー/
■86390 / inTopicNo.5)  Re[3]: Listを使ったクラスへのアクセスについて
□投稿者/ ぶなっぷ (163回)-(2018/01/25(Thu) 15:14:31)
私もshuさんの意見に賛成です。

具体的な実装方法は以下のような感じ。

まず、
  private List<buttonBasic> mainMenus;
を
  private Dictionary<buttonEnum, buttonBasic> mainMenus;
に変えます。

その上で、
  mainMenus.Add( createButton(n) );
を
  mainMenus.Add( type, createButton(n) );
と変えます。

こうしておけば、それ以降は、
  buttonBasic btnBasic;
  mainMenus.TryGetValue(buttonEnum.BUTTON_C, out btnBasic);
でOKです。

BUTTON_Cの権限が無い(= mainMenusに含まれていない)なら、
btnBasic は null が返ってきます。
権限があるなら、ちゃんと btnBasic に BUTTON_C に対応する
インスタンスが返ってきます。

(参考)
以下のような手もありますが、今回のようにキーに対して結びつく
値が1:1の場合はDictionaryの方が圧倒的に高速です。
  class BtnInfo
  {
    buttonEnum type;
    buttonBasic btnBasic;
  }
を定義し、
  private List<BtnInfo> mainMenus;
その上で、検索時は、
  btnBasic = mainMenus.FirstOrDefault(x => x.type == buttonEnum.BUTTON_C)
すると、BUTTON_Cの権限が無い(= mainMenusに含まれていない)なら、
btnBasic には null が返ってきます。
権限があるなら、ちゃんと btnBasic に BUTTON_C に対応する
インスタンスが返ってきます。

引用返信 編集キー/
■86391 / inTopicNo.6)  Re[2]: Listを使ったクラスへのアクセスについて
□投稿者/ MTK (2回)-(2018/01/25(Thu) 16:10:20)
No86387 (shu さん) に返信

回答ありがとうございます。
Dictionary調べてみました。
なるほど、こちらで管理した方が使いやすそうです。
早速試してみたいと思います。
引用返信 編集キー/
■86392 / inTopicNo.7)  Re[1]: Listを使ったクラスへのアクセスについて
□投稿者/ PANG2 (209回)-(2018/01/25(Thu) 16:12:59)
No86386 (MTK さん) に返信
> こういうことをしたい場合、どのように作るのが良いのでしょうか?
> また、上記のプログラムの構成についてもご指摘頂けると嬉しいです。

ボタンを動的に作成する必要があるのか?
継承してクラス化する必要があるのか?

> ログインユーザの権限情報により、どのボタンを表示するかが変わります。

であれば、デザイン画面にボタンを5個貼り付けて、コードで.Visibleを切り替えるのが一般的かと。
引用返信 編集キー/
■86393 / inTopicNo.8)  Re[2]: Listを使ったクラスへのアクセスについて
□投稿者/ MTK (3回)-(2018/01/25(Thu) 16:24:37)
No86388 (魔界の仮面弁士 さん) に返信

回答ありがとうございます。


> 「名詞+形容詞」の語順のクラス名に違和感があります。
>
> クラス名が Pascal 形式ではなく camel 形式の命名ルールになっている点も
> あまり C# っぽくは無いですね。

クラスなどの命名、あまり意識せずに好みでやってしまっていました。
BasicButton とか ManagerMenu といった命名の方がいいということですよね?
添付して頂いたURLも参考にして、修正したいと思います。


> なお、このクラスがスーパークラス専用で設計されている場合は、
> 「class buttonBasic」ではなく
> 「abstract class buttonBasic」となるのが良いでしょう。

abstract を付けるとインスタンスが作れないと聞き、
buttonBasicのListが作れなくなると勘違いしていました;;


例もあげて頂き、ありがとうございました。
お陰様で色々な問題が解決しそうです。
引用返信 編集キー/
■86394 / inTopicNo.9)  Re[3]: Listを使ったクラスへのアクセスについて
□投稿者/ MTK (4回)-(2018/01/25(Thu) 16:36:11)
No86389 (yummy さん) に返信

回答ありがとうございます。

> ・何のためにListを使うのか?
複数のボタンをまとめて管理する方法として、クラスの配列型かListくらいしか
私に引き出しがなかったためです。
ポリモーフィズムを聞きかじりながら実装しようとしている状態です。


> ・buttonA, B, C等に分ける理由は何か?
>  (権限で分けているのか、単にボタン機能別だけなのか)
各ボタンは機能で分かれており、ログインユーザの権限によってどの機能が使えるかが分かれています。
ボタンを押せば、その機能を使うための別ウインドウが開くようにしたいと考えています。
ボタン毎の画像や挙動を分けるためにも、分けています。


> ・例えば、buttonAクラスのインスタンスは複数存在しうるのか?(buttonB, buttonC等も同様)
複数存在しないようにしたいです。
まだきちんと理解できていませんが、シングルトンなどを検討した方が良いのでしょうか?


> ・後でList内のボタンの参照が必要となるのはどのような場合か?
>  また、何を以てそのボタンを特定するのか?
ボタンの参照が必要になるのは、想定では表示、非表示、ボタンクリック時の画像の変更、どのボタンが有効になっているかのチェックなどです。
何を以てそのボタンを特定するのか?は、初めはENUMで管理しようと四苦八苦して今の問題にぶち当たってしまっています。


> 後でボタンを参照する場合、ボタンの特定方法(例えば、ボタンクラスの何らかのプロパティ等で判断)
> があれば、それを利用してListのFindを利用するのも一つの方法だと思います。
なるほど、プロパティで判断する方法もあるんですね。
こちらの方法も調べてみたいと思います。
引用返信 編集キー/
■86395 / inTopicNo.10)  Re[4]: Listを使ったクラスへのアクセスについて
□投稿者/ MTK (5回)-(2018/01/25(Thu) 16:40:05)
No86390 (ぶなっぷ さん) に返信

回答ありがとうございます。


このような作りにすればいいんですね。
これなら権限の部分も、無駄な判定を入れずにスマートにできそうです。
具体的な例を出して頂きありがとうございました。

引用返信 編集キー/
■86397 / inTopicNo.11)  Re[2]: Listを使ったクラスへのアクセスについて
□投稿者/ MTK (6回)-(2018/01/25(Thu) 16:48:41)
No86392 (PANG2 さん) に返信

回答ありがとうございます。

> ボタンを動的に作成する必要があるのか?
> 継承してクラス化する必要があるのか?
>
>>ログインユーザの権限情報により、どのボタンを表示するかが変わります。
>
> であれば、デザイン画面にボタンを5個貼り付けて、コードで.Visibleを切り替えるのが一般的かと。

必ず動的にする必要はないかと思います。
わざわざプログラム側で作っているのは、例えばボタンが10個あった場合に

□□□□□
□□□□□
↑のように表示させたいのですが、
もし権限の問題で6つしか表示しない場合は

□ □ □
□ □ □
↑のように表示させたりと、権限の状況によって表示を変えたいのと
ボタンをグループ分けして、グループ毎に上記のような表示をしたいため
プログラムで作った方がいいのかな?と思い、このやり方にしています。
引用返信 編集キー/
■86398 / inTopicNo.12)  Re[3]: Listを使ったクラスへのアクセスについて
□投稿者/ 774RR (585回)-(2018/01/25(Thu) 18:39:34)
設計方針というか次第だけど、権限がないとき
・ボタンは見えるが無効化されている=できるけど権限が無いことがユーザにわかりやすい
・ボタンが表示されない=ユーザに余計な情報を与えないので今できることに集中させやすい

前者なら Enabled=false で済むし後者なら Visuble=false で済むし、
オイラなら最初からデザイナで「全部乗せ」画面を作り、どれか適切なイベントハンドラで上記処理するかな。
わざわざ動的管理するよりデザイナに任せちゃったほうが簡単だと思う。

offtopic
フランス語圏の人なら名詞+形容詞の順に違和感ないと思うの心。
黒い猫 / black cat / chat noir

引用返信 編集キー/
■86406 / inTopicNo.13)  Re[4]: Listを使ったクラスへのアクセスについて
□投稿者/ yummy (2回)-(2018/01/26(Fri) 12:47:48)
2018/01/26(Fri) 12:49:45 編集(投稿者)

そもそも、ボタンクラスと実際のボタンコントロールとの関係はどうなっているのでしょうか?
また、ボタンコントロールの実体は、デザイナで作成するわけではなく、
コード上で作成されるのでしょうか?
また、「画像の変更」とありますが、この「画像」は、ボタン上の画像でしょうか、
それともボタンとは別の所にある(例えばフォーム内)画像でしょうか?

恐らく権限の管理はフォーム側で行うと思い、
ボタンクリックイベントもフォーム側に書くのだろうと思いますが、
そのボタンにどこまでの役割を委譲するかによって、
そもそものボタンクラスの設計は変わってくると思いますので、
ここら辺をもう少し整理した方がいいかも知れません。


> offtopic
> フランス語圏の人なら名詞+形容詞の順に違和感ないと思うの心。
> 黒い猫 / black cat / chat noir

そういえば、北海道の人気お土産に「ドゥーブルフロマージュ」がありますが、
フランス語だとFromage Double(確か、パッケージにもそう書いてあったはず・英語だとダブルチーズ)なので、
ちょこっとだけフランス語を知っている(?)私としては、すごく違和感を覚えました。
引用返信 編集キー/
■86411 / inTopicNo.14)  Re[4]: Listを使ったクラスへのアクセスについて
□投稿者/ MTK (7回)-(2018/01/26(Fri) 16:08:09)
No86398 (774RR さん) に返信

回答ありがとうございます。

仰る通り、その方法が簡単そうですね。
昨日の回答を頂いて色々考えた結果、現在はbuttonをbuttonBasicクラスに継承して
フォームに直接設置する方法で進めています。

Enabled か Visuble かは、どちらにするかちょっと悩んでみます。
Enabledで管理すると、一般ユーザに管理者用機能名が知られてしまう(これが問題になりうるか)
Visubleで管理すると、権限がないボタンが消えて、見た目が穴ぼこみたいになりそう
ということで、後は設計方針の部分になってくるかと思うので、検討をしてみます。

> offtopic
> フランス語圏の人なら名詞+形容詞の順に違和感ないと思うの心。
> 黒い猫 / black cat / chat noir

一般的には、どちらなんでしょうね?
英語も からっきしな私には違和感がなく・・・
C#のセオリーも覚えていこうと思います。
引用返信 編集キー/
■86412 / inTopicNo.15)  Re[5]: Listを使ったクラスへのアクセスについて
□投稿者/ MTK (8回)-(2018/01/26(Fri) 16:24:30)
2018/01/26(Fri) 16:26:50 編集(投稿者)
2018/01/26(Fri) 16:25:47 編集(投稿者)

No86406 (yummy さん) に返信

度々ありがとうございます。


> そもそも、ボタンクラスと実際のボタンコントロールとの関係はどうなっているのでしょうか?
> また、ボタンコントロールの実体は、デザイナで作成するわけではなく、
> コード上で作成されるのでしょうか?
> また、「画像の変更」とありますが、この「画像」は、ボタン上の画像でしょうか、
> それともボタンとは別の所にある(例えばフォーム内)画像でしょうか?

ボタンクラスと実際のボタンコントロールとの関係を全然考慮せず、作っていましたorz
現在はbuttonをbuttonBasicクラスに継承して、フォームに設置することで対応しています。

「画像の変更」とは、ボタン上の画像のことでした。
各ボタンに共通の背景画像と、ボタンの機能を示すアイコンみたいなものを、各ボタン別にその上に乗せるつもりでした。


> 恐らく権限の管理はフォーム側で行うと思い、
> ボタンクリックイベントもフォーム側に書くのだろうと思いますが、
> そのボタンにどこまでの役割を委譲するかによって、
> そもそものボタンクラスの設計は変わってくると思いますので、
> ここら辺をもう少し整理した方がいいかも知れません。

ボタンにどこまでの役割を委譲するか・・・
そうですよね、そこを考えないといけませんね。
まだそれぞれのメリットデメリットが明確に分かるような知識がないのが悔しいところですが
今までの皆さんの回答を伺った後だと、わざわざボタンクラスを作らなくても
大抵のことであればフォームやコントロールの設定等で対応できるような気がしてきています。
当初の構想とは違う方向に行きましたが、良い形にできたかと思います。
解決済み
引用返信 編集キー/
■86413 / inTopicNo.16)  Re[5]: Listを使ったクラスへのアクセスについて
□投稿者/ 774RR (588回)-(2018/01/26(Fri) 16:45:43)
-- offtopic only --
アルファベット文字を使うが非英語圏の人にとってはどうやら悩ましい問題のようです。
名詞→形容詞の順が自然なフランス語やスペイン語圏の人はかなり困っている様子。
統一された見解は無いように見えます。

アジア圏の人にとっては英語教育があってもフランス語やスペイン語教育は少なくて、だから
ソースコードを書く上での標準言語は英語っぽいっす。
だから形容詞→名詞になるようにシンボル名をつけるほうが圧倒的多数だと推測してます。


引用返信 編集キー/
■86414 / inTopicNo.17)  Re[6]: Listを使ったクラスへのアクセスについて
□投稿者/ MTK (9回)-(2018/01/26(Fri) 16:55:20)
No86413 (774RR さん) に返信

なるほどなるほど!
アジアではソースコードを書く上での標準言語は英語、であればそれに合わせた方が良さそうですね。
勉強になりました。
ありがとうございます。
解決済み
引用返信 編集キー/
■86416 / inTopicNo.18)  Re[5]: Listを使ったクラスへのアクセスについて
□投稿者/ 魔界の仮面弁士 (1553回)-(2018/01/26(Fri) 17:29:50)
No86393 (MTK さん) に返信
> BasicButton とか ManagerMenu といった命名の方がいいということですよね?

非英語圏の単語を並べる場合はさておき、
「英単語」を並べる場合には、英語の語順が良いと個人的には思います。

ただ重要なのはむしろ、プロジェクト全体で統一の取れた命名規約を保つことですね。


ちなみにスーパークラス専用となる基底クラスでは、
しばしば「〜Base」と命名されることがあります。

 System.Windows.Forms.ButtonBase ← Button / CheckBox / RadioButton など
 System.Windows.Forms.TextBoxBase ← TextBox / RichTextBox / MaskedTextBox など

と言っても、すべてのスーパークラスがそういう命名になるわけでは無いのですが。

 System.Windows.Forms.ListControl ← ComboBox / ListBox など
 System.Windows.Forms.CommonDialog ← FolderBrowserDialog / FontDialog など


No86411 (MTK さん) に返信
>> ボタンを押せば、その機能を使うための別ウインドウが開くようにしたいと考えています。
>> ボタン毎の画像や挙動を分けるためにも、分けています。
> 昨日の回答を頂いて色々考えた結果、現在はbuttonをbuttonBasicクラスに継承して

Form クラスを継承して Form1 クラスを作るのが一般的であるように、
「Button クラスを継承した buttonBasic クラス」を継承して buttonA クラスを
作るという設計にするのも一つの方針ですし、要件次第ではありますね。

ボタンから呼び出される個別の処理を定義する場合は、ボタンクラスへの実装ではなく、
ボタンのインスタンスに対してイベントを割り当てて実装するようにし、
ボタンそのものの汎用的な振る舞いを定義する場合(長押しとかトリプルクリックとか)は、
ボタンクラスへの実装にすることが多いです、私は。

なお、継承を用いて実装する場合は、自クラスのイベントに処理を書くのではなく、
イベントを呼び出すためのメソッド(OnClick など)をオーバーライドする方が望ましいです。
https://opcdiary.net/?p=3966


> Enabled か Visuble かは、どちらにするかちょっと悩んでみます。
Visuble ではなく Visible ですね。


> Enabledで管理すると、一般ユーザに管理者用機能名が知られてしまう(これが問題になりうるか)

特定のユーザーしか使わない機能は、例えば、Office 2007 以降の「開発者リボン」のように、
タブページやサブメニューなどを用いて、分けてしまうのも手です。

そうすれば、その管理者向けサブメニューを開けない一般ユーザーの目から、機能名を隠せます。
メニューを分けることで、呼び出すまでのクリック数が増えることになるのが難点ですが。



> Visubleで管理すると、権限がないボタンが消えて、見た目が穴ぼこみたいになりそう
> ということで、後は設計方針の部分になってくるかと思うので、検討をしてみます。

関連性のあるボタンなら、まとまって配置されていた方が使いやすい面もありますので、
必ずしも単純に均等配置すれば良いというもので無いのが、デザインの難しいところですね。

また、「機能」をアイコンや文字ではなく、『位置』で覚える人もいるので、
歯抜けな配置になったとしても、位置を大きく変えないほうが良い場合もあります。
(もちろん、その逆もありえるのですが)


異なる権限のアカウントでログインする必要が生じる運用形態がありえる場合、
権限によってボタンの位置が変わってしまうことに、使いにくさを覚えるかもしれません。
たとえば「休職者に対する代行処理」とか「他店舗の臨時支援」などといったケースです。


似たような話は、Microsoft Office のメニューでも起きていました。
バージョン 2000 あたりから、「利用頻度の低いメニュー項目が自動的に非表示となる」機能が
追加されたのですが、人によってはこれを邪魔に感じることがあったようです。

もちろん、使わない機能は見えない方が分かりやすい、という考えの人もいるので、オプション設定で
 「最近使用したコマンドを最初に表示する」(Office 2000)
 「常にすべてのメニューを表示する」(Office 2002/2003)
を切り替えられるようにはなっていましたけれどね。
解決済み
引用返信 編集キー/
■86426 / inTopicNo.19)  Re[6]: Listを使ったクラスへのアクセスについて
□投稿者/ MTK (10回)-(2018/01/26(Fri) 20:47:32)
No86416 (魔界の仮面弁士 さん) に返信

色々な意見を頂きありがとうございます!


> 非英語圏の単語を並べる場合はさておき、
> 「英単語」を並べる場合には、英語の語順が良いと個人的には思います。
>
> ただ重要なのはむしろ、プロジェクト全体で統一の取れた命名規約を保つことですね。

まだ命名に慣れていませんが、
そのように統一していきたいと思います。



> Visuble ではなく Visible ですね。

ほんとですね;;
失礼しました。



> ボタンから呼び出される個別の処理を定義する場合は、ボタンクラスへの実装ではなく、
> ボタンのインスタンスに対してイベントを割り当てて実装するようにし、
> ボタンそのものの汎用的な振る舞いを定義する場合(長押しとかトリプルクリックとか)は、
> ボタンクラスへの実装にすることが多いです、私は。

だんだん、フォームのボタン側で出来ることが分かってきました。
ボタンクラス側であれば長押しとかトリプルクリックとかも検出できるんですね。
まだまだ勉強が必要です。



> 特定のユーザーしか使わない機能は、例えば、Office 2007 以降の「開発者リボン」のように、
> タブページやサブメニューなどを用いて、分けてしまうのも手です。

なるほど、そういう発想は無かったですね。
例えばボタンをグループ毎にタブコントロールで分けて、
管理者メニューを1つのタブにまとめてしまうのはアリですね。



> また、「機能」をアイコンや文字ではなく、『位置』で覚える人もいるので、
> 歯抜けな配置になったとしても、位置を大きく変えないほうが良い場合もあります。
> (もちろん、その逆もありえるのですが)

考えてみたら、私も色々なものを位置で覚えているな・・・と思います。
位置を変えない方がいい気がしますね。



> 関連性のあるボタンなら、まとまって配置されていた方が使いやすい面もありますので、
> 必ずしも単純に均等配置すれば良いというもので無いのが、デザインの難しいところですね。

そうですよね;;
その辺りのデザインセンスというか、配置配色のセンスなどが欠けていていつも困ってしまいます。
特にユーザ視点での使いやすさ、分かりやすさを実現するのが難しく感じます。
普段何気なく使っているソフトなどから、そういうものを吸収していかなければいけませんね。
解決済み
引用返信 編集キー/


トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

管理者用

- Child Tree -