Gespräche über die PLO in der Lounge - Seite 10
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Man muss sich nicht aufdrängen, aber es ist offensichtlich, dass in einer prozeduralen Form die Logik des Codes bereits ohne zusätzliche Gesten sichtbar ist, und jede Geste eines angestellten Programmierers kostet den Arbeitgeber eine Gebühr. Wenn ein Arbeitgeber klug ist, wird er sich nicht von OOP täuschen lassen, aber ein cleverer Programmierer kann ihm ein Märchen über fortschrittliche OOP auftischen, um mehr Geld von ihm zu bekommen, indem er seinen geringen Bildungsstand ausnutzt. :)
Ha!
Es gibt eine Logik, die besagt, dass es keinen zusätzlichen Aufwand bedeutet, zu Fuß zu gehen, aber aus irgendeinem Grund will jeder ein Verkehrsmittel benutzen. Das geht so weit, dass sie sich in ein Auto setzen, zwei Kilometer zu einem Fitnesscenter fahren und dann fünf Kilometer auf einem Laufband "spulen".
Apropos Programmierung: In DOS wird ein Fenster einfach durch Schreiben in einen Videopuffer erstellt. Aber um ein einfaches Fenster in Windows zu erstellen, müssen Sie eine Fensterklasse registrieren, sie erstellen und eine Schleife der Nachrichtenverarbeitung ausführen - aber aus irgendeinem Grund macht jeder genau diese "zusätzlichen Schritte".
So ist es auch hier. Das OOP - wird überhaupt nicht wegen der "Fortschrittlichkeit" gewählt, sondern wegen der Vorteile, die diese Methode bietet, und weil sie letztlich für den Arbeitgeber billiger ist. Denn wenn man etwas im prozeduralen Stil geschrieben hat, kann man es nicht mit der gleichen Effizienz pflegen wie im OOP-Stil geschrieben.
Ein gutes Beispiel ist der Code von Peter Konov - einerseits ein ganz normaler, prozeduraler Code, aber andererseits muss man, um damit zu arbeiten, immer eine Menge Informationen über die Systemstruktur im Kopf behalten, so dass ich persönlich eine solche Aufgabe nicht einmal für viel Geld übernehmen würde. Gleichzeitig ist SB, das im OOP-Stil geschrieben ist, sehr einfach zu pflegen und zu ändern. Die Architektur der Objekte im TC-Muster der Standardbibliothek ist viel komplizierter als in Peters Code, aber viel einfacher zu verstehen und zu ändern.
Das ganze Gerede über "einen prozeduralen Stil ohne zusätzliche Arbeit" gilt nur bis zu dem Punkt, an dem Sie eine wirklich komplexe Struktur schreiben und vor allem Änderungen daran vornehmen müssen. Das ist der Grund, warum OOP so weit verbreitet ist - es ist einfacher für Programmierer und billiger für Kunden. Um etwas ganz Einfaches darin zu tun, sind allerdings "unnötige Gesten" erforderlich. Ganz einfach, niemand braucht dieses "einfach", alle brauchen "komplex", was besser mit der Verwendung von OOP zu tun ist.
P.S. Und ich verstehe immer noch nicht, wie Sie (sprechen wir von "Sie") vorschlagen, den Zugriff auf Funktionen zu beschränken, die ohne OOP-Zugriffsmodifikatoren nirgendwo verwendet werden sollten?
George Merts:
Denn wenn Sie etwas im prozeduralen Stil schreiben, können Sie es nicht mit der gleichen Effizienz pflegen wie etwas, das im OOP-Stil geschrieben wurde.
P.S. Und ich verstehe immer noch nicht, wie Sie (sprechen wir von "Sie") vorschlagen, den Zugriff auf Funktionen zu beschränken, die ohne OOP-Zugriffsmodifikatoren nirgendwo verwendet werden sollten?Nein, nein. Es ist genau andersherum.
Es ist nur OOPeshe Code, die schwer zu pflegen und zu ändern, denn es gibt eine Menge von verschiedenen Drehungen und Wendungen in ihm, dass später ist es einfacher, den Code noch einmal zu schreiben. Man sagt, dass der Zweck von OOP darin besteht, die Logik zu verstecken, also haben sie sie versteckt, und wenn es plötzlich notwendig ist, sie zu öffnen, ist dies eine kostenpflichtige Dienstleistung.
Wrapper-Funktion ermöglicht es, interne Funktionen zu verstecken, aber wenn Sie plötzlich das Gefühl, wie das Hinzufügen dieser internen Funktion, können Sie es in einer DLL verstecken, oder Quellcode in einer separaten Datei, und die Datei in der am weitesten entfernten Verzeichnis, so dass selbst wenn Sie versuchen, es wird nicht gefunden werden, vielleicht gibt es mehr Möglichkeiten für besonders rasende Programmierer. :)
Nein, das ist es nicht. Es ist genau andersherum.
Der OOP-Code ist genauso schwierig zu warten und zu ändern, weil die Logik dort mit vielen verschiedenen Tricks versteckt ist, so dass es einfacher ist, den Code neu zu schreiben. Man sagt, der Zweck von OOP sei es, die Logik zu verstecken, also haben sie sie versteckt, und wenn es plötzlich notwendig ist, sie aufzudecken, ist dies ein kostenpflichtiger Service.
Wrapper-Funktion können Sie die internen Funktionen zu verstecken, aber wenn Sie plötzlich wollen, um diese interne Funktion für alles, können Sie es in einer DLL verstecken, oder Quellcode in einer separaten Datei, und die Datei in der am weitesten entfernten Verzeichnis, so dass im besten Fall Wunsch es nicht gefunden werden könnte, vielleicht gibt es Optionen für besonders wütende Programmierer. :)
Warum sollte es "schwer zu ändern" sein, wenn die Logik versteckt ist? Deshalb ist die Logik versteckt, um zu verhindern, dass Sie etwas ändern, wo es nicht möglich ist.
Es ist nur so, dass man beim prozeduralen Ansatz etwas ändern will, es geändert hat und dann nicht versteht, warum es nicht funktioniert (oder schlimmer - manchmal bekommt man unverständliche Fehler). Und im OOP-Ansatz wollen Sie es ändern - und Sie haben keinen Zugriff auf die Interna der Klasse. Und wenn es keinen Zugang gibt, bedeutet das, dass es einen Grund dafür gibt, dass es etwas Kniffliges gibt, einige implizite Bedingungen für die Nutzung. Wenn Sie also etwas ändern wollen, können Sie genau diese Klasse nehmen, ihre eigene Klasse erben und dort ändern, was Sie brauchen, da Sie bereits Zugriff auf die Schutzmethoden in der Nachfolgeklasse haben.
Und selbst wenn man es vererbt, kann man auf eine private Methode oder ein privates Feld stoßen, das auch im Nachkommen nicht verfügbar ist, und auch hier bedeutet es aus einem bestimmten Grund, dass dieses Feld auch im Nachkommen nicht geändert werden soll.
Apropos "in DLL verstecken" - das Problem ist, dass man nur ALLES in einer DLL verstecken kann. Kein Teil des Objekts. Und genau dafür ist der Zugriffsmodifikator da, um nur einen Teil des Objekts auszublenden. Das ist der Grund, warum alles so konzipiert ist - damit der Programmierer an jeder Stelle des Programms nur auf das zugreifen kann, was er braucht, und nichts "von oben" - so muss er nicht befürchten, dass er versehentlich nicht das ändert, was er braucht, sondern den Teil, der geändert werden darf. Welchen Sinn hat dann die DLL? Öffnen Sie den DLL-Code - dann wird der gesamte Code geöffnet, nicht nur Teile. Schließen - auch hier ist der Zugang gesperrt.
Ich weiß nicht, wie man den Zugang prozedural einschränken kann, ohne privat-geschützte-öffentliche Bereiche zu verwenden. Und diese Einschränkung hilft mir sehr.
Warum sollte es "schwer zu ändern" sein, wenn die Logik versteckt ist? Die Logik ist versteckt, so dass man nichts ändern kann, was man nicht ändern kann.
Es ist nur so, dass man beim prozeduralen Ansatz etwas ändern möchte, es geändert hat und dann nicht versteht, warum es nicht funktioniert (oder schlimmer - manchmal erhält man unverständliche Fehler). Und im OOP-Ansatz wollen Sie es ändern - und Sie haben keinen Zugriff auf die Interna der Klasse. Und wenn es keinen Zugang gibt, bedeutet das, dass es einen Grund dafür gibt, dass es etwas Kompliziertes gibt, einige implizite Bedingungen für die Nutzung. Wenn Sie also etwas ändern wollen, können Sie genau diese Klasse nehmen, von ihr Ihre eigene Klasse erben und dort ändern, was Sie brauchen, da Sie bereits Zugriff auf die Schutzmethoden in der Nachfolgeklasse haben.
Und selbst wenn man es vererbt, kann man auf eine private Methode oder ein privates Feld stoßen, das auch im Nachkommen nicht verfügbar ist, und auch hier bedeutet es aus einem bestimmten Grund, dass dieses Feld auch im Nachkommen nicht geändert werden soll.
Apropos "in DLL verstecken" - das Problem ist, dass man nur ALLES in einer DLL verstecken kann. Kein Teil des Objekts. Und genau dafür ist der Zugriffsmodifikator da, um nur einen Teil des Objekts zu verbergen. Deshalb ist alles so konzipiert, dass der Programmierer an jeder Stelle des Programms nur auf das zugreifen kann, was er braucht, und nichts "von oben" - so muss er nicht befürchten, dass er versehentlich nicht das ändert, was er braucht, sondern den Teil, der geändert werden darf. Welchen Sinn hat dann die DLL? Öffnen Sie den DLL-Code - dann wird der gesamte Code geöffnet, nicht nur Teile. Schließen - auch hier ist der Zugang gesperrt.
Ich weiß nicht, wie man den Zugang verfahrenstechnisch einschränken kann, ohne privat-geschützte-öffentliche Bereiche zu verwenden. Und diese Einschränkung hilft mir sehr.
George, du schlägst wieder die Trommel )))) Das macht keinen Sinn.
Georges, du redest wieder um den heißen Brei herum )))) Das ergibt keinen Sinn.
Vielleicht, vielleicht.
Aber du bist ein Teilzeit-Casanova... Und ich bin Nachhilfelehrer in Teilzeit. Ich sehe, dass "der Kunde nicht verloren ist". Also erkläre ich weiter. Wie "berufliche Deformierung".
Vielleicht, vielleicht.
Aber du bist der Teilzeit-Casanova... Und ich bin Nachhilfelehrer in Teilzeit. Ich sehe, dass "der Kunde nicht verloren ist". Also erkläre ich mich weiter. Wie "berufliche Deformierung".
Ich habe die Nase voll von den Casanovas. Du hast dir ein Märchen ausgedacht und selbst daran geglaubt), so wie ein Kind an den Weihnachtsmann glaubt, um Gottes willen).
Es besteht keine Notwendigkeit, sie aufzuerlegen, aber es ist offensichtlich, dass in der prozeduralen Form die Logik des Codes bereits ohne zusätzliche Gesten sichtbar ist, und jede Geste eines angestellten Programmierers kostet den Arbeitgeber Geld.
Die Anzahl der Gesten im obigen Verfahrenscode muss erhöht werden, wenn Änderungen vorgenommen werden müssen.
Es ist möglich, Code ohne Funktionen (Prozeduren) zu schreiben. Doch irgendwann hörte die Programmierung auf, aus "Beton" geschrieben zu werden, und begann, aus "Ziegeln" zu bauen. Daraus entstand die prozedurale Programmierung.
OOP ist ein weiterer Schritt zur Zerlegung der Gesamtarbeit in einfachere Komponenten.
Die Arbeitsteilung und die damit einhergehende Fließbandproduktion schufen die industrielle Revolution, die zur Industrialisierung der Menschheit führte.
Handgemacht heißt "Code ohne Verfahren schreiben".
Bei Conveyor handelt es sich um "prozedurales Schreiben von Code", bei dem viele Elemente des Conveyors von anderen abhängig sind. Das heißt, die Änderung eines Elements kann die Änderung eines anderen erfordern.
"OOP-Programmierung" ist eine Pipeline mit reduzierten Abhängigkeiten zwischen den Elementen. Das heißt, ein Element kann durch ein anderes ersetzt werden, und es ist weniger wahrscheinlich, dass die Rohrleitung nicht mehr funktioniert. In der Lage sein, jede Produktion in unabhängige Teile zu zerlegen, Normen einzugeben, usw. - ist objektorientierte Fertigung (nicht Programmierung).
Die Programmierung selbst ist ein Spezialfall der Produktion. Der OOP-Ansatz ist ein prinzipieller Ansatz für die Entwicklung von allem. Daher ist es sehr eng, von Programmierung zu sprechen. OOP wurde erfolgreich angewandt, BEVOR es in der Programmierung auftauchte.
Ich habe die Nase voll von den Casanovas. Sie haben sich ein Märchen ausgedacht und selbst daran geglaubt ) wie ein Kind, das an den Weihnachtsmann glaubt, um Himmels willen )
Ich beneide dich, Lech!
Ganz im Ernst. Nun, lassen Sie mir das Recht auf ein wenig künstlerische Übertreibung...
Die Anzahl der körperlichen Bewegungen in dem oben genannten Verfahren...
О ! Gut gesagt.
Vollständig unterstützend.
Der körperliche Aufwand im obigen Verfahrenscode wird größer sein müssen, wenn Änderungen vorgenommen werden müssen.
Im Prinzip kann der körperliche Aufwand bei OOP nicht geringer sein, da alle diese Schnittstellen zusätzlichen Overhead darstellen, der oft die Kosten für das Schreiben der Logik selbst übersteigt. Und das, obwohl jede Funktion bereits eine Schnittstelle hat, d.h. es wird vorgeschlagen, eine weitere Absicherung zu machen, die im Grunde genommen sinnlos ist.
Gleichzeitig wird jede Änderung des Codes, sowohl in der Schnittstelle als auch in der Funktion, viel komplizierter, da das eine vom anderen abhängt, was bedeutet, dass die Zahl der möglichen Fehler und die Arbeitsintensität mindestens quadratisch ansteigen... Das ist doch irgendwie offensichtlich, oder?