Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.
PCSpectra wrote:That goes for any problem. Everything is simple once it is understood
Man, you and jshpro2 sure like your philosophy, don't you
PCSpectra wrote:I recall reading a study/article years ago, titled: "what makes a super programmer" or something similar...the study was from 1978 in an old book I have so it's a little dated. The conclusion was that of all backgrounds tested (Psychologists, physicists, etc about a dozen in total) mathematicians made the best programmers. Assumingly because they are 'experts' at breaking complex problems into atomic problems.
That made me laugh... I'm picturing my abnormal psych prof trying to program. (I'm a psychology major)
Man, you and jshpro2 sure like your philosophy, don't you
Sure I guess....I think he's probably more formal than me.
Most of my understanding of philosophy, spirituality and psychology is from self-observation and just spending a lot of time thinking about thinking...
Fowler wrote:The way to deal with [situations where different use cases work best with different varieties of laziness] is to have separate database interaction objects for the different use cases. Thus, if you use DataMapper (165), you may have two order mapper objects: one that loads the line items immediately and one that loads them lazily. The application code chooses the appropriate mapper depending on the use case. A variation on this is to have the same basic loader object but defer to a strategy object to decide the loading pattern.
class User extends SmartORM # vanilla User class, default laziness
# properties
property id, Integer, auto-inc
property username, String
property name, String
property description, Text
property signature, Text
# associations
belongs_to groups
has_many posts, order_by(date, desc)
end
class Poster extends User # the class to use when displaying posts
lazy [description,username,groups]
eager [id,name,signature,posts]
end
class Profile extends User # the class to use when displaying profiles
lazy [username,posts]
eager [id,name,signature,description,groups]
end
Kieran Huggins wrote:So would a strategy object essentially be a model wrapper with embedded laziness settings?
That's probably one way to do it. I think he meant injecting an object through a method, such as setLoader (LoadingStrategy $loader) ...but subclassing works as well.
Composition is inheritance. Sub classing is static inheritance, only a subset of kinds of ways to inherit functionality. Delegation is a way to inherit functionality, despite it's de-facto usage. I guess head first books don't teach you that, only GoF. The confusion, I guess, comes from implementation specific terms vs the context I'm using them in being for analysis / design phases.