|
| |
VB.NET - Ein- und Umsteiger| Re: Hierarchie im TreeView | |  | | Autor: ErfinderDesRades | | Datum: 21.05.14 11:15 |
| nanu?
Also das ist alles richtig, und ist mir bekannt, was du jetzt sagst, und ich denke, weißt du auch, dasses mir bereits bekannt ist - also ich stimme dir ganz zu.
Zur Modul-Klasse-Begrifflichkeit: Ich bezeichne hier mit "Modul", was in vb.Net mit dem Schlüsselwoert "Module" deklariert wird (c#: "shared class"), und als "Klasse" bezeichne ich, was im Code als "Class" deklariert wird. Anderes gelagerte Begriffsverwendungen finde ich unglücklich, weil sie genau den Punkt "Objektorientierung" verwaschen: Aus einer Class kann man ein Objekt instanzieren, aus einem Module nicht.
Nun werden die Begriffe halt auch anders verwendet, das führst du richtig aus, aber für den strittigen Punkt bringt das nur Irritation.
Strittig zwischen uns ist ja meine Feststellung, dass das mvb-Strings-Modul weniger objektorientiert ist als die String-Klasse - es ist halt ein Modul, und kann man kein Objekt draus erstellen.
Das ist dir ja auch bekannt, nur zu meiner Verwunderung widersprichst du mir so energisch, wenn ich sage, die mvb-Methoden seien obsolet, weil in der String-Klasse ist besser geeignetes und desingnetes (eben OOP), und nennst es "Unsinn".
Dabei weißt du es so gut wie ich.
Nur wenn ich es sage - zu stefanbla80, der es nicht weiß - dann kommt dein eigentümlicher energischer Widerspruch - ich finde zum Schaden von stefanBla80, der sich aus diesem Wortgefecht raushält, und am Ende dann auch zu keiner Entscheidung gelangt.
Ich versuche ihn auf das Kern-OOP-Prinzip "Objektmethode" hinzuweisen am ganz praktischen Beispiel, und zu motivieren, sich mit der String-Klasse intensiv auseinander zu setzen, und mit Klassen überhaupt - vorzugsweise mittels ObjectBrowser.
Aber durch dieses mir aufgezwungene Gefachsimpel, machst du es zunichte, und ich frag mich, was von diesem Verhalten das Ziel ist.
Ebenso verhielt es sich ja bei sloorgs Thread - hier: http://www.vbarchiv.net/forum/id22_i95571t95543_subroutine-schreiben.html
Aber auf das hier kann ich noch eingehen, weil das argumentiert ja für mich:| Zitat: | |
(Wären die oben angesprochenen Methoden der MSVB.Strings-Klasse in einem Modul deklariert und mit dem Extension-Attribut versehen, könnten sie direkt auch als Erweiterungsmethoden der System.String-Klasse fungieren.) | |
Wie gesagt: du kennst dich so gut aus wie ich, und daher weißt du so gut wie ich:
Wären Len, Mid, StrDup, Left, Format, Instr, LTrim, RTrim, LSet, RSet, StrComp, UCase, LCase Extension-Methods, dann wäre all diese Funktionalität nicht nur (wie jetzt) doppelt verfügbar, sondern die Redundanz wäre nun auch noch direkt sichtbar inne Intellisense.
Also das (historisch bedingte) unglückliche Design wäre ja wohl ins Groteske getrieben, wenn alles doppelt angeboten würde, unter jeweils 2 verschiedenen Namen.
(Rechtschreibfehler urheberrechtlich geschützt) | |
 | Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
 Einloggen | Neu registrieren |
 |
|
vb@rchiv CD Vol.6 vb@rchiv  Vol.6
Geballtes Wissen aus mehr als 8 Jahren vb@rchiv!
Online-Update-Funktion
Entwickler-Vollversionen
u.v.m.Jetzt zugreifen Tipp des Monats Neu! sevPopUp 2.0 
Dynamische Kontextmenüs!
Erstellen Sie mit nur wenigen Zeilen Code Kontextmenüs dynamisch zur Laufzeit. Vordefinierte Styles (XP, Office, OfficeXP, Vista oder Windows 8) erleichtern die Anpassung an die eigenen Anwendung... Weitere Infos
|
November 2025
Sie sind aktuell nicht angemeldet.
