Scope creep advice needed
Moderator: General Moderators
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Scope creep advice needed
Is it necessary to formally define a class's dependencies to configuration directives, esp. those directives which affect the behavior of multiple classes?
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
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.
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
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.
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.
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
A minority of them. Right now one, but I suspect there are more.So I can assume that these classes roughly share the directives?
[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.
Not sure what you mean here. I try to require_once every class a class will need (thus the convoluted include structure).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.
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
You've already got redundancy by nature of the below response.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.
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).
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.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. .
(#10850)
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
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.Not sure what you mean here. I try to require_once every class a class will need (thus the convoluted include structure).
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?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.
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.Registry with a Settings object, or just plain old Singleton Settings, perhaps with Factory?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
So why not everything then?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?
I would think only as much as needed.Ambush Commander wrote:I'm wondering how much info this definition should provide.
(#10850)
- Ambush Commander
- DevNet Master
- Posts: 3698
- Joined: Mon Oct 25, 2004 9:29 pm
- Location: New Jersey, US
Because configuration is directly tied to the interface. You could liken it to an argument in a function.So why not everything then?
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.I would think only as much as needed.
