Frage zu Programmplanung (KlassenDesigen)

  • C#
  • .NET (FX) 4.5–4.8

Es gibt 7 Antworten in diesem Thema. Der letzte Beitrag () ist von Duster.

    Frage zu Programmplanung (KlassenDesigen)

    Hallo Leute,

    ich habe vor kurzem angefangen eine Tutorialserie die ich in VB angefangen habe nach C# zu portieren und eigentlich neu zu schreiben
    da in der BV-Version einiges schief gelaufen ist. Die Tutorials dienen auch als Lernprogramme für mich.

    Ich habe auf @'Erfinder des Rades' gehört und einen damals von mir entwickelten Datentyp (PenData) rausgeworfen und verwende jetzt nur noch Klassen und keine Strukturen etc. mehr!. Ausserdem plane ich das ganze jetzt mehr d.h. nicht nur Oberfläche etc.!.

    Meine Frage ist, sehe ich folgendes richtig ?( :

    Ob ich die Datenübergabe in die Klassen über einen Konstruktor oder über Eigenschaften regle ist vom Tippaufwand her egal ich muss immer
    entweder den Konstruktor oder die Eigenschaften in vollem Umfang angeben um ein geändertes Objekt (Farbe, DashStyle etc.) zu erhalten.

    Aber mit den Eigenschaften bin ich näher an der Kapselung da die Background Variablen der Eigenschaften private sind!

    Die „CreatePen()“ befindet sich bei Line01 noch im Konstruktor, da es aber auch eine CrateBrush() geben wird habe ich sie aus den
    Konstruktor geholt. Über die Eigenschaften kann ich später testen ob ein Pen oder ein Brush gewünscht wird und diesen dann erstellen.

    Ich habe ein kleines Testprogramm geschrieben (und angehängt) in dem ich beide Möglichkeiten gegenüberstelle.
    Ich würde die Erstellung der Objekte mittels der Eigenschaften vorziehen. Was meint Ihr dazu?

    Vielen Dank für Eure Mühe vorab :)

    Hier etwas Code:

    Shape01:

    C#-Quellcode

    1. namespace ColorDialog_Problem
    2. {
    3. public abstract class Shape01
    4. {
    5. public Point Line01StartLocation;
    6. public Point Line01EndLocation;
    8. public abstract string Name { get; set; }
    9. public int Alpha { get; set; }
    10. public int Width { get; set; }
    11. public DashStyle DStyle { get; set; }
    12. public Size Size { get; set; }
    13. public Pen Pen;
    15. public abstract void Draw(Graphics e);
    16. }
    17. }



    Line01:

    C#-Quellcode

    1. namespace ColorDialog_Problem
    2. {
    3. class Line01 : Shape01
    4. {
    5. public override string Name
    6. {
    7. get => "Line01";
    8. set { }
    9. }
    11. public Line01() { }
    13. public Line01(int alpha, int red, int green, int blue, int width, DashStyle dStyle)
    14. {
    15. Pen = new Pen(Color.FromArgb(alpha, red, green, blue), width)
    16. {
    17. DashStyle = dStyle
    18. };
    19. }
    20. public override void Draw(Graphics e)
    21. {
    22. e.DrawLine(Pen, Line01StartLocation, Line01EndLocation);
    23. }
    24. }
    25. }



    Shape02:

    C#-Quellcode

    1. namespace ColorDialog_Problem
    2. {
    3. public abstract class Shape02
    4. {
    5. public Point Line02StartLocation;
    6. public Point Line02EndLocation;
    8. public abstract string Name { get; set; }
    9. public abstract int Alpha { get; set; }
    10. public abstract int Red { get; set; }
    11. public abstract int Green { get; set; }
    12. public abstract int Blue { get; set; }
    13. public abstract int Width { get; set; }
    14. public abstract DashStyle DStyle { get; set; }
    16. public Pen Pen;
    17. //public Brush Brush;
    18. public abstract void Draw(Graphics e);
    19. }
    20. }


    Line02:

    C#-Quellcode

    1. namespace ColorDialog_Problem
    2. {
    3. class Line02: Shape02
    4. {
    5. private int _alpha;
    6. private int _red;
    7. private int _green;
    8. private int _blue;
    9. private int _width;
    10. private DashStyle _dStyle;
    12. public override string Name
    13. {
    14. get => "Line02";
    15. set { }
    16. }
    17. public override int Alpha
    18. {
    19. get => _alpha;
    20. set => _alpha = value;
    21. }
    22. public override int Red
    23. {
    24. get => _red;
    25. set => _red = value;
    26. }
    27. public override int Green
    28. {
    29. get => _green;
    30. set => _green = value;
    31. }
    32. public override int Blue
    33. {
    34. get => _blue;
    35. set => _blue = value;
    36. }
    37. public override int Width
    38. {
    39. get => _width;
    40. set => _width = value;
    41. }
    42. public override DashStyle DStyle
    43. {
    44. get => _dStyle;
    45. set => _dStyle = value;
    46. }
    48. public Line02() { }
    50. private Pen CreatePen() // Wird noch eine CreateBrush() geben
    51. {
    52. DashStyle dStyle = DashStyle.Dash;
    53. Pen pen = new Pen(Color.FromArgb(Alpha, Red, Green, Blue), Width);
    54. pen.DashStyle = DStyle;
    55. Pen = pen;
    57. return pen;
    58. }
    59. public override void Draw(Graphics e)
    60. {
    61. CreatePen();
    62. e.DrawLine(Pen, Line02StartLocation, Line02EndLocation);
    63. }
    64. }
    65. }


    Die Verwendung:

    C#-Quellcode

    1. namespace ColorDialog_Problem
    2. {
    3. public partial class Form1 : Form
    4. {
    5. private bool _drawState = true;
    6. private string _shapeName01 = "Line01";
    7. private string _shapeName02 = "Line02";
    9. private Line01 _line01 = new();
    10. private Line02 _line02 = new();
    12. private int _line01Alpha = 255;
    13. private int _line01Red = 255;
    14. private int _line01Green = 201;
    15. private int _line01Blue = 14;
    16. private int _line01Width = 10;
    18. private int _line02Alpha = 255;
    19. private int _line02Red = 0;
    20. private int _line02Green = 0;
    21. private int _line02Blue = 255;
    22. private int _line02Width = 10;
    24. private Point _line01StartCoords;
    25. private Point _line01EndCoords;
    27. private Point _line02StartCoords;
    28. private Point _line02EndCoords;
    30. public Form1()
    31. {
    32. InitializeComponent();
    33. }
    35. private void Form1_Load(object sender, EventArgs e)
    36. {
    37. InitializeShapes();
    38. }
    40. protected override void OnPaint(PaintEventArgs e)
    41. {
    42. base.OnPaint(e);
    43. _drawState = true;
    45. _line01.Draw(e.Graphics);
    46. _line02.Draw(e.Graphics);
    47. }
    48. private void CmdColorLines_Click(object sender, EventArgs e)
    49. {
    50. if (DlgColor.ShowDialog() == DialogResult.OK)
    51. {
    52. _line01Red = DlgColor.Color.R;
    53. _line01Green = DlgColor.Color.G;
    54. _line01Blue = DlgColor.Color.B;
    55. _line02Red = DlgColor.Color.R;
    56. _line02Green = DlgColor.Color.G;
    57. _line02Blue = DlgColor.Color.B;
    59. _line01 = new Line01(_line01Alpha, _line01Red, _line01Green, _line01Blue, _line01Width, DashStyle.Dash)
    60. { Line01StartLocation = _line01StartCoords, Line01EndLocation = _line01EndCoords };
    62. _line02 = new Line02() { Line02StartLocation = _line02StartCoords, Line02EndLocation = _line02EndCoords };
    63. _line02.Alpha = Convert.ToInt32(NudAlpha.Value);
    64. _line02.Red = _line02Red;
    65. _line02.Green = _line02Green;
    66. _line02.Blue = _line02Blue;
    67. _line02.Width = _line02Width;
    68. _line02.DStyle = DashStyle.Dash;
    69. }
    71. Invalidate();
    72. }
    74. private void NudAlpha_ValueChanged(object sender, EventArgs e)
    75. {
    76. _line01 = new Line01(Convert.ToInt32(NudAlpha.Value), _line01Red, _line01Green, _line01Blue, _line01Width, DashStyle.Dash)
    77. { Line01StartLocation = _line01StartCoords, Line01EndLocation = _line01EndCoords };
    79. _line02 = new Line02() { Line02StartLocation = _line02StartCoords, Line02EndLocation = _line02EndCoords };
    80. _line02.Alpha = Convert.ToInt32(NudAlpha.Value);
    81. _line02.Red = _line02Red;
    82. _line02.Green = _line02Green;
    83. _line02.Blue = _line02Blue;
    84. _line02.Width = _line02Width;
    85. _line02.DStyle = DashStyle.Dash;
    87. Invalidate();
    88. }
    90. public void InitializeShapes()
    91. {
    92. _line01StartCoords = new Point(250, 150);
    93. _line01EndCoords = new Point(560, 150);
    95. _line02StartCoords = new Point(250, 200);
    96. _line02EndCoords = new Point(560, 200);
    98. _line01 = new Line01(_line01Alpha, _line01Red, _line01Green, _line01Blue, _line01Width, DashStyle.Dash)
    99. { Line01StartLocation = _line01StartCoords, Line01EndLocation = _line01EndCoords };
    101. _line02 = new Line02()
    102. { Line02StartLocation = _line02StartCoords, Line02EndLocation = _line02EndCoords };
    103. _line02.Alpha = _line02Alpha;
    104. _line02.Red = 0;
    105. _line02.Green = 0;
    106. _line02.Blue = 255;
    107. _line02.Width = _line02Width;
    108. _line02.DStyle = DashStyle.Dash;
    110. Invalidate();
    111. }
    112. }
    113. }


    Vielen Dank nochmal und viele Grüße bei der Hitze,
    Duster

    P.S.: Hab ich was falsch gepostet oder sind alle am Badesee :)
    Dateien

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Duster“ ()

    Duster schrieb:

    Ob ich die Datenübergabe in die Klassen über einen Konstruktor oder über Eigenschaften regle ist vom Tippaufwand her egal ich muss immer entweder den Konstruktor oder die Eigenschaften in vollem Umfang angeben um ein geändertes Objekt (Farbe, DashStyle etc.) zu erhalten.
    Aber mit den Eigenschaften bin ich näher an der Kapselung da die Background Variablen der Eigenschaften private sind!
    Das kommt drauf an. Grundsätzlich ist es so, dass Du bei einem parametrisierten Konstruktor die Werte initial festlegst. Und somit dem Nutzer sagst: Ohne die Initialwerte ergibt die Nutzung der Klasse keinen Sinn. Ich z.B. nutze solch einen parametrisierten Konstruktor bei einem speziellen TCP/IP-Server, dem gesagt werden muss, auf welchem Port er lauschen soll. Ohne Portangabe ergäbe die Nutzung bei meiner speziellen Serverklasse keinen Sinn. Gleichzeitig könnte solch ein Konstruktor auch aussagen: Die verwendeten Parameter sind nach Instanziierung so wie angegeben und bleiben auch so. Wenn Du hingegen Properties nimmst, machst Du dem Klassenuser klar: Ändere die Einstellungen, wann immer Du willst, ich sorge danach dafür, dass das alles so seine Richtigkeit hat.

    ##########

    C#-Quellcode

    1. public override void Draw(Graphics e)
    2. {
    3. CreatePen();
    4. e.DrawLine(Pen, Line02StartLocation, Line02EndLocation);
    5. }

    Wenn das Ding gemalt wird, wird erstmal ein Pen kreiert? Klingt nach Overkill. Ggf. vorher prüfen, ob Pen schon etwas ist? Wo werden all die Disposable-Objects (ok, hab bisher nur Pen gesehen) disposed?
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VaporiZed“ ()

    @VaporiZed
    Tut mir leid dass ich mich so spät melde!!!!!!!

    Danke für die schnelle Antwort Vaporized.

    Bevor wir weiterreden lass mich kurz beschreiben um welche Art Programm es sich
    bei meinem Projekt handelt.: Das ganze wird ein GDI+ Tutorium bei dem der Nutzer über verschiedene Controls (List-/ Comboboxen, PropertyGrids etc.) die verschiedenen GDI+ Primitive (Line, Ellipse, Rect, Rects etc.) zeichnen lassen kann. Der Nutzer kann entscheiden ob ein Pen oder Brush genutzt wird und kan Start- und EndCaps etc. hinzu fügen. Es kann über Controls alles geändert werden was die Primitive betrifft!


    Das kommt drauf an. Grundsätzlich ist es so, dass Du bei einem parametrisierten Konstruktor die Werte initial festlegst. Und somit dem Nutzer sagst: Ohne die Initialwerte ergibt die Nutzung der Klasse keinen Sinn. Ich z.B. nutze solch einen parametrisierten Konstruktor bei einem speziellen TCP/IP-Server, dem gesagt werden muss, auf welchem Port er lauschen soll. Ohne Portangabe ergäbe die Nutzung bei meiner
    speziellen Serverklasse keinen Sinn. Gleichzeitig könnte solch ein Konstruktor auch aussagen: Die verwendeten Parameter sind nach Instanziierung so wie angegeben und bleiben auch so.

    Das ist klar. Da aber bei meinem Programm eben alles was die Primitive vom Nutzer über Contros änderbar ist, d.h. die verwendeten Parameter nach Instantiierung eben nicht bleiben wie sie sind halte ich die 2.
    Variante mit Properties für besser.

    Wenn Du hingegen Properties nimmst, machst Du dem Klassenuser klar: Ändere die Einstellungen, wann immer Du willst, ich sorge danach dafür, dass das alles so seine Richtigkeit hat.

    D.h. nicht den parameterisierten Konstruktor sondern die Properties. Habe ich Dich da richtig verstanden ?( ????

    Wenn das Ding gemalt wird, wird erstmal ein Pen kreiert? Klingt nach Overkill. Ggf. vorher prüfen, ob Pen schon etwas ist?

    Wieso Overkill, vor jedem Primitiv muss ein zugehöriger Pen erstellt werden mit dem die Form gemalt wird!
    Selbstverständlich werde ich noch prüfen ob pro Primitiv ein Pen bzw. Brush schon erstellt wurde (null) oder ob noch einer gebraucht wird. Werd noch sehen wie ich das mache vielleicht innerhalb irgendeiner Eigenschaft.

    Wo werden all die Disposable-Objects (ok, hab bisher nur Pen gesehen) disposed?

    Ja muss ich auch noch machen. Werd sehen wo es Sinn macht!.

    Viele Grüße,
    Duster

    Welche Frage?
    In Post#4 sehe ich auf die Schnelle keine Frage.

    Doch, eine, aber die ist an Vpz gerichtet:

    Duster schrieb:

    D.h. nicht den parameterisierten Konstruktor sondern die Properties. Habe ich Dich da richtig verstanden ????
    Ich könnte da allenfalls drauf antworten, dass so eine verallgemeinerte Aussage: "nicht den parameterisierten Konstruktor sondern die Properties."
    natürlich Unfug ist.
    Und das hat Vpzs sicher sicher auch nicht gemeint, wenn er sagt:

    VaporiZed schrieb:

    Das kommt drauf an...






    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    @Erfinder des Rades
    Aso, dann hab ich missverständlich geschrieben.
    Eigentlich wollte ich wissen was die bessere (cleanere) Variante ist bei meinem Projekt (Tutorial wie in Post #4 beschrieben), parameterisierter Konstruktor oder Eigenschaften?
    Nach weiterem Überlegen denke ich dass ich den Pen oder den Brush an die Draw-Funktion von aussen übergebe und in der Draw einfach teste ob Pen oder Brush Null sind.
    Ich glaube mich zu erinnern dass Du mir bei der VB-Version (letztes Jahr) sowas auch geraten hast ==> Proframmiere so einfach wie möglich und wirf PenData raus ;)

    Ich hoffe das war unmissverstänlicher?

    Grüße,
    Duster

    Jo, imo besser verständlich, aber ich habe dein Projekt nicht so im Detail vor Augen.
    Jdfs. Pen und Brush in eine Draw-Methode reinreichen klingt für mich sinnvoll.

    Nicht sinnvoll scheint mir, da immer abzuprüfen, ob sie Null sind.
    Wenn eine Methode falsch aufgerufen wird, dann darf das Proggi gerne abstürzen.
    Das ist ein sehr effizientes Mittel, den Entwickler dazu zu bringen, die Methode richtig aufzurufen.
    Oder anders: Welcher Depp wird denn einer Draw()-Methode, die einen Brush erwartet, Nothing übergeben und denken, das wird schon irgendwie?

Facebook
Telefonspende