How To Architect Multi-Class Modules, And Some Questions About Basic Pw Architecture

[thetuningspoon]

I've been starting to dip my toes into the oop world, and am hoping to start some module development for PW soon. Right now I understand many of the principals and concepts of oop, but once the rubber meets the road and I start trying to build/modify something, I have some trouble putting things into practice.

Right now I'm trying to figure out how to architect modules with multiple classes (in separate .php files), similar to Ryan's formbuilder module. One of the things that's confusing me is how to work with an object (think of a Shopping Cart or Form) that needs to be used by multiple classes in the same module. Right now I am thinking of using the .module file itself as a "controller" and instantiating the shared object as a property of the module object (ok so far?). Since I need the ability to use $pages and other PW API variables, I am extending all my classes from Wire or WireData. This means I can reference my shared object from my external classes using $this->modules->get('myModule')->myObject. But is this a good practice? Shouldn't I instead be passing my object into the other objects as a parameter to reduce coupling? If so, should I be passing it in the constructor and making it a property of the new object, or as a parameter on each method call?

Also, I will need to access the main module's settings from within my external classes. I could do this using $this->modules->get('myModule') or with a fuel variable like $myModule that I set, but both of those seem wrong to me. And from what I can make out of the formbuilder module, Ryan isn't doing this kind of thing (although I could have missed it).

Which leads me to my question about PW's architecture... I'm having a tough time grasping how the Wire/WireData class is used. My n00b understanding of inheritance is that it's supposed to represent an "is-a" relationship. From my understanding, many of PW's classes extend the WireData class to have the functions available to access the API... but this doesn't seem like an "is-a" relationship. It seems to work well, though, and I'm not sure what the alternative would be... Maybe just instantiating a WireData object any time you need to use its functions?

So, as you can see... OOP n00b needs halp!

[netcarver]

@everfreecreative

Just a quick response to your post...

But is this a good practice? Shouldn't I instead be passing my object into the other objects as a parameter to reduce coupling? If so, should I be passing it in the constructor and making it a property of the new object, or as a parameter on each method call?

Passing them in is called dependency injection (lots thrown up by google) and should make your classes more easily testable and code more reusable.

My n00b understanding of inheritance is that it's supposed to represent an "is-a" relationship. From my understanding, many of PW's classes extend the WireData class to have the functions available to access the API... but this doesn't seem like an "is-a" relationship. 

It certainly can represent an "is-a" relationship but in practice I've seen it used all over the place to implement common code. This can also be done to a limited degree in PHP using interfaces and more recently through traits.

Hope that helps and starts some more comprehensive answers coming.

[thetuningspoon]

Thanks netcarver, I did some reading on dependency injection this morning.

Would it be correct to say that avoiding $this->modules->get('myModule') from within my module code would be more efficient since I can bypass an unnecessary database query?

[Nico Knoll]

Well in case of ProcessDiagnostics we're using  $this->modules->get('myModule') 

https://github.com/netcarver/PW-ProcessDiagnostics/blob/master/ProcessDiagnostics.module#L75-L83

[thetuningspoon]

Yeah, in that instance it seems appropriate.