Ab welcher Projektgröße lohnt sich OOP?

[Zergling-new]

Hallo,
ich sitze gerade an einer Mini-Aufgabe und habe dafür nen Haufen Klassen und Verwaltungs-Klassen erstellt. Wie so oft war für mich der Weg das Ziel (allerdings muss das Ziel auf morgen fertig sein) und ich habe wieder elendig lang gebraucht.

Klassen:
MovieManager
Movie
Actor
Director
etc.

Ab welcher Projektgröße lohnt sich der Einsatz eigentlich, denn ich bin mir sicher, ich hätte es prozedural mindestens doppelt so schnell hinbekommen. Oder liegt das eher an meiner wohl mangelnden praktischen Erfahrung, dass ich mit OOP deutlich langsamer bin?

Wie schnell ist bei euch der Zeitunterschied beim kompletten Erstellen (Konzeption, Programmierung, Testen) bei OOP vs Prozedural?

Klar braucht OOP immer etwas länger und ist damit aber auch gleich wiederverwendbar, aber dass ich soviel länger brauche...Oder ist der Betreff falsch gewählt und es müsste heißen, ab der wievielten Wiederbenutzung lohnt sich OOP?

[Waq]

Na, jetzt aber Ich kenne mich durchaus mit OO aus... Ich spreche C++ und Java... Das sollte OO genug sein :wink:

Offensichtlich nicht. OOP ist und bleibt ein sprachunabhängiges Konzept, und die Implementation in einer konkreten Sprache ist so schnell beschrieben, dass sich dafür kein Buch lohnt.
Und die philosophischen Unterschiede zwischen streng und schwach typisierter OOP sind auch nicht so ausufernd.

OOP in PHP.
Kauf dir wenn ein Buch über OO, in dem über OOA, OOD und Entwurfsmuster gesprochen wird.
Das hilft definitiv eher weiter als ein PHP-Buch ..

Na, jetzt aber Ich kenne mich durchaus mit OO aus... Ich spreche C++ und Java... Das sollte OO genug sein :wink:

Ich brauche lediglich OOP in PHP, weil ich das noch nicht kenn.
Zu Hause hab ich sogar en Buch "OOP in Perl"! Das ist äußerst interessant. Naja, darum hab ich halt nach einem Buch OOP in PHP gefragt, und nicht nach einem Buch über OOP allgemein.

@all:
Danke für die Links!

Gruß,
Andreas

[HStev]

OOP in PHP.
Kauf dir wenn ein Buch über OO, in dem über OOA, OOD und Entwurfsmuster gesprochen wird.
Das hilft definitiv eher weiter als ein PHP-Buch ..

naja aber anwenden ist dann immer noch so ne Sache wenn keine Beispiele drinnstehen für die entsprechende Sprache

Dann lieber ein Sprachbezogenes Buch und die Grundlagen irgendwo aus nen Tutorial wie zb.
Crashkurs OOP Teil 1: Klassen und Objekte
Crashkurs OOP Teil 2: Klassenvererbung
Crashkurs OOP Teil 3: Polymorphie

[imported_Ben]

OOP in PHP.
Kauf dir wenn ein Buch über OO, in dem über OOA, OOD und Entwurfsmuster gesprochen wird.
Das hilft definitiv eher weiter als ein PHP-Buch ..

[HStev]

Ist zwar ein Buch was sich allgemein mit PHP5 befasst aber ich kanns durchaus empfehlen auch in Bezug auf OOP

PHP5 - Grundlagen und Profiwissen
http://www.joergkrause.de/buecher/bo...p?selection=17

Wollte mal kurz anfragen, ob jmd. ein gutes Buch über OOP mit PHP kennt. Wollte mich in die Materie mal einarbeiten.

Dank und Gruß,
Andreas

[HStev]

Ja wie gesagt wenn man C/C++ gewohnt ist siehts echt merkwürdig aus auf den 1. Blick aber für eine Script die nicht explizit einen Datentyp verlangt ist das in PHP5 gut gelöst.

Man könnte auf die Art und Weise auch bei Eigenschaften einen Datentyp festlegen.

[Zergling-new]

Ja ich geb zu, bei mir ist gestern auch der Knoten geplatzt und plötzlich gingen die "kompliziertesten" Aufrufe mit ein paar Instanzierungen und Methodenaufrufen. Sehr fein

Frage an euch noch, benutzt jemand den Debugger der in der ZDE4/5 eingebaut ist oder welchen benutzt ihr? Und wie kann man damit GET oder POST-Parameter mitübergeben?

Edit: LOL wie krass. Sieht voll unübersichtlich aus, aber ist nen Versuch wert, kannte ich nocht garniht ^^

[HStev]

Naja für C-Strukturen könnte man genauso gut Assoc Arrays nehmen

Mann hat halt mit Klassen - vor allen in PHP5 durch die Magic Functions __get und __set - die Möglichkeit das Füll- und Rückgabeverhalten der Eigenschaften zu beeinflussen.

Genauso wie es jetzt mittels __call möglich ist Methoden zu überladen wenn es auch auf den 1. Blick etwas merkwürdig aussieht.

<?php
class MethodNotExistsException extends Exception {}
class Foo
{
    public function __call($methode, $params)
    {
        $FUNCTION = "_" . $methode . "_" ;
        
        foreach ($params as $param)
        {
            $FUNCTION .= '_' . gettype($param);
        }
        
        if (!method_exists($this, $FUNCTION))
            throw new MethodNotExistsException();
        
        return call_user_method($FUNCTION, $this, $params);
    }
    
    protected function _bar__string_string($params) 
    {
        return $params[0] . $params[1];
    }
    
    protected function _bar__string_integer($params)
    {
        $ret = "";
        for ($i=1; $i<= $params[1]; $i++)
        {
            $ret .= $params[0];
        }
        return $ret;
    }
}

$F = new FOO();

echo $F->bar("Hallo ", "Welt");
echo "
";
echo $F->bar("Hallo
", 3);
?>

OOP hat ja auch den Ansatz was schon geschaffenes wieder benutzen zu können ... egal wie klein es ist ... ist es arbeit ...

Das ist ein Argument Und prozedurales Zeug etwa nicht? Wenn man es richtig macht, dauert das Lösen einer Aufgabe mit prozeduralem Code wahrscheinlich noch länger als mit der OOP.

Nehmen wir mal an, ich schreib einen Request-Container, also ein Skript, das den Request zur Verfügung stellt:

class SRequest {
    var $args = array(); // Argumentnamen
    var $argv = array(); // Argumentwerte
    var $argc = 0; // Anzahl der Argumente
}

function &request_create()
{
    $req = new SRequest();

    // hier füll ich die Argumente von $_POST/$_GET in diese Instanz

    return $req;
}

function request_delete($request)
{
    unset($request); // nur der förmlichkeit halber, funktioniert natürlich nicht
}

function request_get_arg($request, $argname)
{
    // Schleife, die den Argumentnamen sucht und den Wert zurückgibt
}


function request_set_arg($request, $argname, $argvalue)
{
    // Schleife, die den Argumentnamen sucht und den Wert ändert, bzw den Argumentnamen neu anlegt
}

// usw.

Ich nutze Klassen als C-ähnliche Strukturen. Angewandt wird das dann folgendermaßen:

include_once("request.php");

$req = &request_create();
$seite = request_get_arg(&$req, "seite");
request_delete(&$req);

[robo47]

OOP hat ja auch den Ansatz was schon geschaffenes wieder benutzen zu können ... egal wie klein es ist ... ist es arbeit ...

[HStev]

Eigentlich immer OOP selbst wenns nur Kleinigkeiten sein aber da wo sich ein Objekt anbietet setzt ich es auch ein. Meistens kommen bei mir die Klassen nie zum 2. Einsatz außer bei so Klassen wie Datenbankschnitstelle, RandomString Generator oder zb. n ThumbCreator aber alle anderen Klassen landen irgendwo im Archiv und werden dort auch begraben

Aber der Vorteil von OOP liegt klar auf der Hand nämlich der modulare Aufbau des Codes späteres austauschen geht "fast" problemlos.

Ich hab mal von irgendjemanden gehört das OOP Performancelastiger sei aber das halte ich persönlich für unwahrscheinlich es sei den ich instanziere 50.000 Objekte

[imported_Ben]

Und benutzt du größtenteils die Klassen auch wieder (außer ganz alltäglichen Klassen wie vielleicht der eigenen DB-Klasse) oder machst du sie letztlich dann doch neu (so ist das leider bei mir manchmal)?

Meine Template-Klasse, sone Art Konfigurations-Klasse, einen Error-Handler und eine Klasse mit ein paar Hilfsfunktionen verwende ich hauptsächlich wieder.

Wie siehts mit PEAR aus, benutzt du/ihr das und bringt das einen nicht unerheblichen Zeitgewinn?

PEAR kommt bei mir wenig zum Einsatz, weil ich in Sachen Programmierung zu den Leuten gehöre, die immer alles selbst machen wollen

Dito.

Ich verwende eigentlich meine Klassen immer irgendwo mal wieder, besser sie aus .. etc.

[Corvin]

Und benutzt du größtenteils die Klassen auch wieder (außer ganz alltäglichen Klassen wie vielleicht der eigenen DB-Klasse) oder machst du sie letztlich dann doch neu (so ist das leider bei mir manchmal)?

Meine Template-Klasse, sone Art Konfigurations-Klasse, einen Error-Handler und eine Klasse mit ein paar Hilfsfunktionen verwende ich hauptsächlich wieder.

Wie siehts mit PEAR aus, benutzt du/ihr das und bringt das einen nicht unerheblichen Zeitgewinn?

PEAR kommt bei mir wenig zum Einsatz, weil ich in Sachen Programmierung zu den Leuten gehöre, die immer alles selbst machen wollen