Entwickler-Ecke :: Thema anzeigen

Ralf Jansen - Fr 30.06.17 19:41

Zitat:

oder Verbesserungsvorschläge vorliegen, so lasst es mich wissen.

Den Syntax wenn möglich ;) Es wäre schön wenn du IntPtr's verstecken könntest. Ein IntPtr sagt ja nicht wofür er steht darum liegt es nahe die immer mit einer passenden contextabhängigen Klasse zu kapseln an der man dann auch nur die entsprechenden auf diesen IntPtr möglichen Methoden kapselt.

Z.B. anstatt

C#-Quelltext

1:
2:
3:
4:

  IntPtr h = frDrive1.OpenVolume('D');  // ermittelt ein Laufwerk 
  frDrive1.EjectVolume(h);              // trennt das Laufwerk
  System.Threading.Thread.Sleep(5000);
  frDrive1.CloseVolume(h);              // nimmt das Laufwerk wieder auf und gibt das Handle frei

eher

C#-Quelltext

1:
2:
3:
4:

  Volume d = frDrive1.OpenVolume('D');
  d.Eject();
  System.Threading.Thread.Sleep(5000);
  d.Close();

Ralf Jansen - Fr 30.06.17 20:35

Zitat:

Man soll es als Handle identifizieren können.

Warum? Ich vermute mal das selbst bei professionellen .Net Entwicklern höchsten ein Viertel weiß was ein Handle ist bzw. mehr weiß als den Namen Handle. Auch in Winforms würdest du ja nicht eine HForm anstatt Form erwarten. Und eine Form ist letztlich auch nicht viel mehr als eine Kapsel für ein Window Handle.

Wo ich gerade sehe das ein Volume auch eine Close kennt spinne ich mal die Analogie zu Form weiter. Am besten du implementierst du in diesen Klassen auch IDisposable damit sich der arme Entwickler Fragen muss ob er nun Close oder Dispose oder beides am Ende aufrufen muss ;) Nein, empfehlen würde ich Close wegzulassen und nur Dispose anzubieten. Bzw. das Handle freigeben von Close zu trennen und nur in Dispose zu machen.

Edit: Vergiss den letzten Satz. Ich habe kurzzeitig Close missverstanden. Es ist nicht die gegenteilige Operation zu Eject :roll:

Th69 - Sa 01.07.17 10:01

Ich bin auch der Meinung von Ralf, daß die API objektorientierter sein könnte. Bisher ist es einfach eine große Klasse (und als Anwender weiß man nicht auf Anhieb, welche Methoden wie in Korrelation stehen).
Ich fände hier sogar eine Schnittstelle IVolume am schönsten:

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

interface IVolume
{
  // Handle
  // Eject
  // Close
  // ...
}

IVolume OpenVolume(char cDrive);

So wäre dann auch der Code auf 2 kleinere Klassen aufgeteilt (frDrive, (I)Volume).

Th69 - Sa 01.07.17 11:32

Ich meine alle Methoden, die bisher den IntPtr hDrive als Parameter entgegennehmen, also auch die privaten Methoden LockVolume, UnlockVolume, d.h. diese kämen dann auch in die Implementationsklasse Volume (und dies würde dann schon den Code kleiner und übersichtlicher machen).

Und bei den anderen Methoden, welche bisher char cDrive als Parameter haben, kannst du dich ja an DriveInfo [https://msdn.microsoft.com/de-de/library/system.io.driveinfo(v=vs.110).aspx] orientieren. So würde sich dann deine Komponente besser in die .NET-Infrastruktur anlehnen (umgekehrt kannst du dir ja auch für die Delphi-Komponente überlegen, ob dies nicht der bessere Designansatz wäre).

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2024 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!