Concrete Classes for Mapped Objects

[solleer]

@TomBZombie I was wondering what the advantages and disadvantages are for having Maphper return objects as concrete classes?

[solleer]

@TomBZombie I am thinking about using a concrete class for mapped objects but I am concerned about in terms of best practice too tightly coupling myself to maphper. Is there a way to avoid tight coupling?

[TRPB]

Interesting question. In the strictest sense, concrete classes aren't tightly coupled to maphper. You don't need to extend a base class or even inject the maphper instance into them. The concrete class does not know that maphper exists. However, where you do get inferred coupling is with relations:

echo $user->address->address1;

Here, the code is coupled to maphper because without it the address property is not set or available without maphper.

Having said that, this is a convenience method and a law of demeter violation so regardless of maphper it's not ideal from a pure OOP perspective. With mapper and without concrete classes we have data structures which could have been loaded using json_decode so aren't coupled to maphper (you could load the data structure in a different way and the application will still work)

Becuse of this, personally I wouldn't generally use concrete classes for a data structure (this is a long but interesting read: http://www.smashcompany.com/technology/object-oriented-programming-is-an-expensive-disaster-which-must-end I disagree with a lot of the points, but the stuff on data structures is applicable here).

Essentially this is an issue of encapsulation and for data structures we have to agree that encapsulation is broken somewhere. We can add get/set methods but really we're still just exposing state and at some points in any program we need to pass data around. If you enforced encapsulation as strictly as possible, anything that worked on the data would be inside the concrete class where the data was stored. In practice this is hardly possible because you end up adding methods for all use-cases or extending the base class for each use-case (and then you need to know which to instantiate earlier on). Instead, if we treat the data as a behaviourless tree structure, it's possible to write methods that use it as-is.

I remember reading an interesting article on this exact topic, I'll see if I can find it.

[garrettw]

Wow, that article was quite a read. Interesting perspective being that I was brought up on OOP (starting with Java, a language I'd rather not use in the future). In my high school Java programming class, we were taught that OOP consisted of merely 3 traits (inheritance, polymorphism, and encapsulation); I'm so glad I've learned a lot since then.