Oh right, my badpytrin wrote:And this is what I was talking about jack, not the technical details. What problem is the OP trying to solve in this roundabout way
New Idea! Class Variable Scope all to Private + one Get Set
Moderator: General Moderators
Re: New Idea! Class Variable Scope all to Private + one Get Set
-
ctrLogicDotNet
- Forum Newbie
- Posts: 24
- Joined: Fri Jul 24, 2009 10:52 am
Re: New Idea! Class Variable Scope all to Private + one Get Set
Sorry, I don't understand the meaning of this...arborint wrote:...take a step back and investigate Tell Don't Ask.
Ok, seems like my idea of defining different get/set scope for the same property is not a good idea and just not the right way to do things...
Sorry to have questioned this way of doing things and tried to adapt a different way...
I've probably put to much effort into this and I'll now stick with the learned way of doing OOP...
Code: Select all
// if you can get then you can set and if can't get then you can't set
class::property and class::property = 'something';
$object->property and $object->property = 'something';
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: New Idea! Class Variable Scope all to Private + one Get Set
I'd recommend searching for "Tell Don't Ask" (and "Code Smell"). You will find a number of good articles on that area of OO design. And don't feel bad ... it is a problem all of us struggle with.ctrLogicDotNet wrote:Sorry, I don't understand the meaning of this...
(#10850)
Re: New Idea! Class Variable Scope all to Private + one Get Set
I dont comprehend how this thread has gotten this much interest, this is called an implicit interface ( as opposed to explicity interfaces )
"There is no right or wrong way to model something, only more or less useful in certain contexts" - paraphrased Martin Fowler's Analysis Patterns
If part of your program involves the users adding & deleting these "properties" from within the application, an implicit interface makes sense, otherwise its a smell.
Abstraction is like a hammer, its a tool but you could also bludgeon yourself to death if you were careless
"There is no right or wrong way to model something, only more or less useful in certain contexts" - paraphrased Martin Fowler's Analysis Patterns
If part of your program involves the users adding & deleting these "properties" from within the application, an implicit interface makes sense, otherwise its a smell.
Abstraction is like a hammer, its a tool but you could also bludgeon yourself to death if you were careless
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: New Idea! Class Variable Scope all to Private + one Get Set
That quote contradicts itself ... unless you only discuss context-less designs.josh wrote:"There is no right or wrong way to model something, only more or less useful in certain contexts"
(#10850)
Re: New Idea! Class Variable Scope all to Private + one Get Set
I dont see how its a contradiction? Even sloppy code is not "wrong" it is just less useful then if it had been done differently.
For instance if the user is adding custom fields an implicit interface is more useful.
In another context where the fields never change an explicit interface would probably be considered more useful
Not sure what you mean by context-less designs, every design has a context, a purpose, goal or "problem domain"
For instance if the user is adding custom fields an implicit interface is more useful.
In another context where the fields never change an explicit interface would probably be considered more useful
Not sure what you mean by context-less designs, every design has a context, a purpose, goal or "problem domain"
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: New Idea! Class Variable Scope all to Private + one Get Set
You're just arguing with yourself about your definition of "wrong".josh wrote:I dont see how its a contradiction? Even sloppy code is not "wrong" it is just less useful then if it had been done differently.
You were the one who seems to be arguing that rules don't have context, but problems do. I simply disagree with that. I think Rules also depend on context.josh wrote:For instance if the user is adding custom fields an implicit interface is more useful.
In another context where the fields never change an explicit interface would probably be considered more useful
josh wrote:Not sure what you mean by context-less designs, every design has a context, a purpose, goal or "problem domain"
(#10850)
Re: New Idea! Class Variable Scope all to Private + one Get Set
"rules"? Didn't the "rules" used to say functions in the global scope were "right"? Back in the 60s. I am simply saying I believe there are no "rules", there are clients with specs, but there's no "moral law of programming" that says one way of doing something is "wrong" ( however there are guidelines and following them will more then likely yield more useful models, then not following them would have )
I guess if you simply miss the bullz-eye on your client's spec, then yes it would be "wrong" but that wasn't what I was trying to say
I mean there is code that does not execute, you can call that "wrong" I guess, but it seems to me like youre just playing devil's advocate, I don't really understand what you're getting at. Maybe you could show an example or something of what "wrong" code looks like?
I have re-factored from explicit interfaces back to implicit interfaces, and vice versa. For instance on my Make Model Year search, I needed to be able to have "Make Model Option Year" vs "make model year". So, it does not make sense to keep writing ->getModel(), ->getMake(), ->getYear() ->getEngine(), ->getEngineCylinderCount(), ->getEngineHorsePower(), when every client wants something different, next week I'd be adding ->getBoltOffset() and ->getWindshieldSize() instead of just letting the client edit a configuration file, so I can just say ->getValueOf( $levels[ $i ] ). so that is an example of how an implicit interface proved more useful.
On the other hand there is code where implicit interfaces are used for their "main" API, like ->execute( 'get', 'variable', 'foo' ).. that is "bad" but not "wrong", especially if you were writing a token parser.

I guess if you simply miss the bullz-eye on your client's spec, then yes it would be "wrong" but that wasn't what I was trying to say
I mean there is code that does not execute, you can call that "wrong" I guess, but it seems to me like youre just playing devil's advocate, I don't really understand what you're getting at. Maybe you could show an example or something of what "wrong" code looks like?
I have re-factored from explicit interfaces back to implicit interfaces, and vice versa. For instance on my Make Model Year search, I needed to be able to have "Make Model Option Year" vs "make model year". So, it does not make sense to keep writing ->getModel(), ->getMake(), ->getYear() ->getEngine(), ->getEngineCylinderCount(), ->getEngineHorsePower(), when every client wants something different, next week I'd be adding ->getBoltOffset() and ->getWindshieldSize() instead of just letting the client edit a configuration file, so I can just say ->getValueOf( $levels[ $i ] ). so that is an example of how an implicit interface proved more useful.
On the other hand there is code where implicit interfaces are used for their "main" API, like ->execute( 'get', 'variable', 'foo' ).. that is "bad" but not "wrong", especially if you were writing a token parser.
Thanks for the psychological evaluationarborint wrote:You're just arguing with yourself .
-
pankajnagarkoti70
- Forum Newbie
- Posts: 4
- Joined: Fri Sep 25, 2009 5:31 pm
Re: New Idea! Class Variable Scope all to Private + one Get Set
Here's my take on it, if you want all three visibilities, and you want to be able to dynamically set/get static properties, then make three arrays.
Re: New Idea! Class Variable Scope all to Private + one Get Set
Wasn't it you who argued passionately that the "right" way to build controllers is to abstract all CRUD actions? I guess we all have our sets of beliefs of what is the "right" way to programI mean there is code that does not execute, you can call that "wrong" I guess, but it seems to me like youre just playing devil's advocate, I don't really understand what you're getting at. Maybe you could show an example or something of what "wrong" code looks like?
Re: New Idea! Class Variable Scope all to Private + one Get Set
Stop trying to argue your own opinions. It's futile 
Re: New Idea! Class Variable Scope all to Private + one Get Set
I argued that duplicating code decreases maintainability ( not to mention coupling with the controller )pytrin wrote:Wasn't it you who argued passionately that the "right" way to build controllers is to abstract all CRUD actions? I guess we all have our sets of beliefs of what is the "right" way to program
Re: New Idea! Class Variable Scope all to Private + one Get Set
No, you are argued that similar but not identical logic in a non-reusable space is duplication. That was your idea of what is the "right" way to code controllers, regardless of the context
Re: New Idea! Class Variable Scope all to Private + one Get Set
Yes, you are correct I did argue that among several other points.pytrin wrote:No, you are argued that similar but not identical logic in a non-reusable space is duplication.
http://i13.photobucket.com/albums/a260/ ... ftopic.jpg
http://en.wikipedia.org/wiki/Duplicate_codeThe following are some of the ways in which two code sequences can be duplicates of each other:
* character for character identical
* character for character identical with white space characters and comments being ignored
* token for token identical
* functionally identical
It is in a non-reusable space because that is where you put it, not "wrong" either mind you but less useful then a model.
Re: New Idea! Class Variable Scope all to Private + one Get Set
Less useful in your opinion. since you can't prove it, and since you don't know the actual context of the applications I build, you're basically saying your method is more correct in the general case, ergo it is "right" and mine is "wrong".
And thanks for the quote, I've been wondering all those years what duplicate code means. Thanks for enlightening me.
And thanks for the quote, I've been wondering all those years what duplicate code means. Thanks for enlightening me.