Heyho hab die Frage bei laracasts gepostet (ist da vermutlich etwas untergegangen)
und ich denke hier sitzen auch die besseren Experten^^
Ihr dürft auch gerne auf Deutsch antworten, ist mir sogar etwas lieber.
https://laracasts.com/discuss/channe...al-programming
Da es mal wieder um oo und prozedurale programmierung geht, hab ich es mal unter Software-Design eingeordnet, auch wenn ich wahrscheinlich auf ner Ebene höher argumentiere, gibt aber leider kein Bereich (!(Design OR Architektur))
Also hier mein Wall of Text:
hoffe ich bekomme seriöse antworten..
moin moin,
if we look into the domin driven design (ddd) there we have services and poj-classes (entity classes)
i know the advantages from oo
for example there you have the
1. single-responsibilty-principle
2. inversion of control
3. inheritance
4. polymophism
5. and and and
but you can have these kinds of adavantages in procedural programming too
(dereferencing of function-pointers in c/php or take a look into the vtables of c++)
and if you code a function then these function have in most of the cases ONE responsibility.
And now my problem point 6
6. Data and Behaviour in one class
Thats a problem for me!
And it seems to be a problem for Martin Fowler too
=> Domin driven Design with service-objects (or should i say servie-procedures....)
you just code extended scalar types: entity-classes with NO behaviour
(for example the class circle: the draw-method would be Behaviour. the setter-method that only validates the no negative radius is set, would be just a validation mechanism that achieve that a circle is a circle and not "negative-circle" that wouldnt be a circle)
The draw method would be defined in a service-object, because these kind of method needs maybe some more objects to achieve a correct drawing.
So my question is why Laravel wrapps the database result into entity-objects (what in my opinion isnt oo, cause it breaks rule 6) and dont work on the raw 1D-Array which represent that entity-object?
The performance would be higher, too, cause:
if the servie-routine/method just need some values from the user and not all of them, then the database have just to give these values and not all of them OR if you have an array: it would be no waste of free heap/stack-memory, cause you dont have to fill up the user-object with NULL-values!
Join-Tables, Aggregate-Tables and and and
i think laravel do something right, but then that isnt really oo (cause of breaking rule 6)
So my conclusion:
Architecure-patterns like layer-models (mvc, osi, etc), and and and a very good.
We loose here a little bit of performance too, but thats ok (and good for abstraction)
But oo (particularly rule 6) is crimes against humanity
And i think ddd or laravel isnt really oo... here the oo is more a synonym for prodecural-programming, or im wrong?
oo has a problem and so servie-objects and entity-classes (seperation of data and behaviour) are invented
how do you think about these all kind of aspects??
lg knotenpunkt
und ich denke hier sitzen auch die besseren Experten^^
Ihr dürft auch gerne auf Deutsch antworten, ist mir sogar etwas lieber.
https://laracasts.com/discuss/channe...al-programming
Da es mal wieder um oo und prozedurale programmierung geht, hab ich es mal unter Software-Design eingeordnet, auch wenn ich wahrscheinlich auf ner Ebene höher argumentiere, gibt aber leider kein Bereich (!(Design OR Architektur))
Also hier mein Wall of Text:
hoffe ich bekomme seriöse antworten..
moin moin,
if we look into the domin driven design (ddd) there we have services and poj-classes (entity classes)
i know the advantages from oo
for example there you have the
1. single-responsibilty-principle
2. inversion of control
3. inheritance
4. polymophism
5. and and and
but you can have these kinds of adavantages in procedural programming too
(dereferencing of function-pointers in c/php or take a look into the vtables of c++)
and if you code a function then these function have in most of the cases ONE responsibility.
And now my problem point 6
6. Data and Behaviour in one class
Thats a problem for me!
And it seems to be a problem for Martin Fowler too
=> Domin driven Design with service-objects (or should i say servie-procedures....)
you just code extended scalar types: entity-classes with NO behaviour
(for example the class circle: the draw-method would be Behaviour. the setter-method that only validates the no negative radius is set, would be just a validation mechanism that achieve that a circle is a circle and not "negative-circle" that wouldnt be a circle)
The draw method would be defined in a service-object, because these kind of method needs maybe some more objects to achieve a correct drawing.
So my question is why Laravel wrapps the database result into entity-objects (what in my opinion isnt oo, cause it breaks rule 6) and dont work on the raw 1D-Array which represent that entity-object?
The performance would be higher, too, cause:
if the servie-routine/method just need some values from the user and not all of them, then the database have just to give these values and not all of them OR if you have an array: it would be no waste of free heap/stack-memory, cause you dont have to fill up the user-object with NULL-values!
Join-Tables, Aggregate-Tables and and and
i think laravel do something right, but then that isnt really oo (cause of breaking rule 6)
So my conclusion:
Architecure-patterns like layer-models (mvc, osi, etc), and and and a very good.
We loose here a little bit of performance too, but thats ok (and good for abstraction)
But oo (particularly rule 6) is crimes against humanity
And i think ddd or laravel isnt really oo... here the oo is more a synonym for prodecural-programming, or im wrong?
oo has a problem and so servie-objects and entity-classes (seperation of data and behaviour) are invented
how do you think about these all kind of aspects??
lg knotenpunkt
Kommentar