Page 1 of 1

Scope creep advice needed

Posted: Wed Sep 06, 2006 8:32 pm
by Ambush Commander
Is it necessary to formally define a class's dependencies to configuration directives, esp. those directives which affect the behavior of multiple classes?

Posted: Wed Sep 06, 2006 8:38 pm
by feyd
I'm not absolutely sure what you're asking..Image

Posted: Wed Sep 06, 2006 8:45 pm
by Ambush Commander
Well, at the start of class files I make a few static function calls to a configuration definition object to define configuration directives the class uses. So an Encoder class would define a Encoding related directives that it uses. This works great for simple configuration parameters but bigger picture ones that span multiple classes, you have to pick one of the classes to do the definition in. Which means that we've got undocumented dependencies... not a good thing for later refactoring.

Posted: Wed Sep 06, 2006 8:58 pm
by feyd
So I can assume that these classes roughly share the directives?

Why not define them in each of the classes (give them the ability to check if they need to do the set up in the first place too) or are they tightly coupled?

For tightly couple classes I'd add directives to load all other coupled classes in each file. Annoying to write and somewhat annoying to maintain, but makes it less annoying for a third party to use them. Of course this loading code could be in an loadable file of it's own making the maintanence a bit easier.

Posted: Wed Sep 06, 2006 9:06 pm
by Ambush Commander
So I can assume that these classes roughly share the directives?
A minority of them. Right now one, but I suspect there are more.

[quopte]Why not define them in each of the classes (give them the ability to check if they need to do the set up in the first place too) or are they tightly coupled? [/quote]

Well, that's an interesting question, because that's how the original implementation went. By decentralizing the directives and definining them wherever they'd be needed, it would make excising classes and the like less painful. I now see that this comes at a price: redundancy.
For tightly couple classes I'd add directives to load all other coupled classes in each file. Annoying to write and somewhat annoying to maintain, but makes it less annoying for a third party to use them. Of course this loading code could be in an loadable file of it's own making the maintanence a bit easier.
Not sure what you mean here. I try to require_once every class a class will need (thus the convoluted include structure).

Posted: Wed Sep 06, 2006 9:15 pm
by feyd
Ambush Commander wrote:Well, that's an interesting question, because that's how the original implementation went. By decentralizing the directives and definining them wherever they'd be needed, it would make excising classes and the like less painful. I now see that this comes at a price: redundancy.
You've already got redundancy by nature of the below response. ;)
Ambush Commander wrote:Not sure what you mean here. I try to require_once every class a class will need (thus the convoluted include structure).

Posted: Wed Sep 06, 2006 9:16 pm
by Christopher
Ambush Commander wrote:Well, at the start of class files I make a few static function calls to a configuration definition object to define configuration directives the class uses. .
If you use globals then you just need to deal with using globals. There really isn't a way around that. The alternative is obviously to not use globals.

Posted: Thu Sep 07, 2006 3:34 am
by Jenk
Registry with a Settings object, or just plain old Singleton Settings, perhaps with Factory?

Posted: Thu Sep 07, 2006 5:16 pm
by Ambush Commander
Not sure what you mean here. I try to require_once every class a class will need (thus the convoluted include structure).
Yeah, but it's not as painful, because if a class moves to another name (requiring the require_once's to be rewired), it probably means you'd have to update the class anyway. Plus, the data is fairly sparse: just a name. A directive would require redundant type-definition, name, namespace and default value.
If you use globals then you just need to deal with using globals. There really isn't a way around that. The alternative is obviously to not use globals.
This isn't really the problem: I know I have to use globals, so I'm using them, and its savvy, after all, class definitions are global, so why not configuration definitions?
Registry with a Settings object, or just plain old Singleton Settings, perhaps with Factory?
Once again, not really the problem. As it stands right now, the configuration container is like putty: it gets molded into the form it needs when it gets passed an application-wide configuration definition. I'm wondering how much info this definition should provide.

Posted: Thu Sep 07, 2006 6:54 pm
by Christopher
Ambush Commander wrote:This isn't really the problem: I know I have to use globals, so I'm using them, and its savvy, after all, class definitions are global, so why not configuration definitions?
So why not everything then?
Ambush Commander wrote:I'm wondering how much info this definition should provide.
I would think only as much as needed.

Posted: Thu Sep 07, 2006 9:55 pm
by Ambush Commander
So why not everything then?
Because configuration is directly tied to the interface. You could liken it to an argument in a function.
I would think only as much as needed.
The whole trouble is that it's not objective. Do I really need some way for a class to say, "Hey, I use this configuration directive even though it's in another class?" Right now, no. If I'm refactoring, yeah, that might have been a good idea.