SitePoint Sponsor

User Tag List

Results 1 to 19 of 19
  1. #1
    Non-Member melancholic's Avatar
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Daunting advanced topics.. How do I learn more?!?!

    Hi everyone,

    In my quest to have a more advanced knowledge of application design, I've come accross many posts in this forum alone (let alone googling for hours).

    I must say I find the whole thing very daunting as I come accross topics like Front Controllers, Page Controllers, Application Controllers, Interceptor Filters, Input filter, Action, Command and Router objects the list goes on.

    I have some kind of clumsy understanding of MVC, but, I just found out that my approach is terribly misdirected...

    I'm somewhat exasperated, confused and discouraged by the volume of things that I do not know about.

    I've read Jason's guide to PHP Design Patterns... I have PoEAA sitting on the shelf, but everytime I try to turn to it for reference, my lack of knowledge in the field bests me everytime and the googling and forum trolling cycle starts yet again.

    Where does it end? where do I look? how do I learn more about these patterns/objects/techniques?

    Can anyone explain what these are and when and where they would fit in into a typical application?


    Frustrated,

  2. #2
    SitePoint Enthusiast Buddha443556's Avatar
    Join Date
    Apr 2004
    Location
    FL, USA
    Posts
    87
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Where does it end? where do I look? how do I learn more about these patterns/objects/techniques?
    It doesn't end. The cycle is continuous. When I started programming, procedural was just showing its limits. Now OOP is in the same state. The code base never strinks, it only gets bigger. To keep up we not only have to learn the techniques of the past but invent the techniques of the future. Welcome to the Ultimate Rat Race.
    Last edited by Buddha443556; Apr 6, 2006 at 06:25.
    Simple fool to the 3rd include.

  3. #3
    SitePoint Zealot
    Join Date
    May 2001
    Posts
    193
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Try learning a new language, it sometimes forces you to think in a different way and in turn you pick up new concepts

  4. #4
    SitePoint Member
    Join Date
    Feb 2006
    Posts
    18
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is probably no consolation, but I'm in pretty much the same place.
    I suspect I'm never going to master the grand Design of an application, so
    I try to concentrate on small-ish objects that I can understand (e.g. Eclipse).
    I know that a library is not a Pattern, but at least I'm imposing disciplines on myself by trying to follow Vincent's principles.
    I have a two-year old application which was mostly built on the "that will do for now, I'll fix it later" principle. Now I've decided that "later" has arrived.
    I'm rewriting it, but from the inside out. That is, building modules that work
    individually rather than staring at a blank "drawing board" waiting for understanding of Design Patterns (in the application-wide sense) to arrive.
    I'm probably doing it wrong again, but hey, life's for learning.

  5. #5
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    With all due respect I think you're trying to run before you're able to walk. Be patient and, like Martin Hall points out, go one step at a time. When you feel you need to refactor your code (and I don't mean whenever you have some time to spare but when the application itself is screaming to be refactored) go ahead and concentrate only on the part that needs to be refactored. Through experience you'll be easily able to jump to the next level, but don't go there before having "mastered" the "easier" ones.

    And don't let the lack of knowledge take you down. You should focus on what you've already learned and achieved, and be damn proud of it instead. Nobody knows everything, nor will you, get that straight.
    Theres more than one way to skin a cat.

  6. #6
    Non-Member melancholic's Avatar
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Thanks everyone for the feedback and advice. Believe me, I'm walking, my problem is that it seems to be in circles which is why I get dizzy, sick and "spew" frustration.

    No problem, I've read a few more posts and a load of php frameworks... I guess I'll keep at it. :P

    regards,

  7. #7
    SitePoint Evangelist
    Join Date
    May 2004
    Location
    New Jersey, USA
    Posts
    567
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Some good points already. I'll add this:

    Write code. Patterns are patterns because they happen over and over again. But you won't really understand the little asides in pattern notes until you've been there.

    If you read Harry's entry on, I think, Registry over at PhpPatterns, you may find your self nodding your head and going, "Oh, yeah, it'll be hard to do unit testing on a Singleton Registry, I can see that."

    But you probably wouldn't have seen that yourself, unless you had been doing Unit Testing for a while. I was just coming up to speed on TDD (the book) when I read that, and it took me a minute to understand that NO, I would NOT have seen that without Harry pointing it out.

    I moved forward a lot on the TDD side just from reading that article at the right time. The reason I got that big jump, though, was that I hadn't been writing code using TDD. I hadn't drunk the "portable code, portable tests" Kool-Aid yet.

    To a large extent, patterns are about wrapping up the experience of others so that you can learn from it. But you can't really learn this stuff until you've done development with it.

    For another example, look at the Composite pattern. When I first read that I thought, "Okay, here's a waste of paper. Aside from drag/drop in drawing programs, who cares about this?"

    I was wrong for a bunch of reasons. The one that really got me, though, was DOM XML processing in perl. One day it hit me: this whole DOM business is the Composite pattern.

    On another note, I'll ding Fowler for this: in PoEAA he splits his discussion of patterns into an "essay" and a "reference" section, and then further divides the essay section into layers. IMO this makes it harder to get the full picture, because he talks about (for instance) Object-Relational Mapping in a bunch of different places.

    Returning to point, I'll close with this: write code. It's easy to get sucked in to the pattern-of-the-month, especially given that PHP discussion seems to track both real PHP issues and fads from Java. The way to avoid that is to take what you know right now, and do something with it.

    You can keep up with the discussions here, but ignore them for the most part. When you're done with whatever-it-was, you'll have a new set of opinions and some new things you want to try. Lather, rinse, repeat.

    =Austin
    Austin Hastings - Principal Consultant - Longacre, Inc.

    Anything you can do, you can do better.

  8. #8
    Non-Member melancholic's Avatar
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Write code. Patterns are patterns because they happen over and over again. But you won't really understand the little asides in pattern notes until you've been there.
    appreciate the insight.. I must admit I got lost into the thick of things... thanks for putting it back into perspective for me.

    regards,

  9. #9
    SitePoint Zealot Serberus's Avatar
    Join Date
    Oct 2005
    Location
    Herts, UK
    Posts
    113
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just re-enforcing what Austin said, start writing code. I find there's only so much theory I can absorb in one hit, and most of that will have gone in a few hours if I never bothered to put that theory into practice.

    This is always easier if you've a project you can apply this stuff to rather than writing code for the sake of it.

  10. #10
    SitePoint Guru Galo's Avatar
    Join Date
    May 2005
    Location
    Holland!
    Posts
    852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by MikeShank
    Try learning a new language, it sometimes forces you to think in a different way and in turn you pick up new concepts
    lol, what does that has to do with patterns ?

    realy, patterns are patterns and they "can" solve a problem that occurs more thgan once to u, hence the name "pattern"

    btw, IMHO application design and framework design, all design is ART, thinking, finding, solving, asking yourself questions in which you somewhat push yourself to an awnser, and more in the guide of "what" then "where", what would solve this problem, and not so much where to solve it cause a good solution will point that out for you.

    Programming applications is not even close to designing them, the 2 are
    very differen concepts in the whole application scope.

    i always just start writing the code that my end-users will be typing in to get the results i offer them from within my application, and you sould. cause then u can add more methods over time and refactor things in other versions of your system.

    It's best not to think about the 1000's cool features you want your application to have in v10.x if your base classes are not well designed your users end up searching the spiderweb and will get confused, also you will fase a huge problem at the end, you have so many methods everywhere scatterd through your app, and now your client want to implement another interface, whoops.... that's why progressive design should be attained at all times. this is just my personal oppinion though so don't shoot me for it.
    Business as usual is off the menu folks, ...

  11. #11
    SitePoint Member
    Join Date
    Feb 2006
    Posts
    18
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Galo
    lol, what does that has to do with patterns ?
    We're basically talking about learning. A step back, a different overview, a new direction - they are all useful aids to understanding.

  12. #12
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by melancholic
    Where does it end? where do I look? how do I learn more about these patterns/objects/techniques?

    Can anyone explain what these are and when and where they would fit in into a typical application?
    If anyone is going to PHP|Tek, please stop reading now .

    I am doing a talk at PHP|Tek on exactly this topic. Hopefully a podcast will follow, but if it doesn't here is my advice from what I've learned (from coaching) so far...

    1) Ignore advice. You have to through a period of chaos before things start to click. This is mostly subconcious, and so forgotten later. Once things start to click, you can put them into words. This means most advice will be helpful after the stage you are now at. You are suffering information overload right now. People mean well, but when they suggest patterns and stuff they just make things worse. They recall these breakthroughs because they were from a later, more rational stage of understanding.

    2) Do read some of the refactoring book and try the stuff out. That is, design something at random (three classes say) and shuffle stuff around to see what it looks like. Version control will help here if you check in often enough. You need to play for a bit. Yes, that means you will spend a whole day getting just one class right to your satisfaction. Do it though. Give yourself this time, and it will pay for itself later.

    3) When thinking about the problems you are trying to solve, gather stories as a first cut. You are trying to identify roles in the system. These become apparent when you examine changes and dialog. When you say "I am the authoriser and I ask the database if a username is present", "now I am the database and I give back a login whem asked for a username", and "The database has given me a login, so I ask it for the password to see if it matches", then you are on the right track. The classes make changes and answer questions. The roles may not be explicit, and often have to be teased out.

    4) Iterate. Any solution will be a first cut, and the code is never finished. Eventually you will understand the problem domain better than the original stakeholder, at least on the technical side.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  13. #13
    SitePoint Evangelist tetsuo shima's Avatar
    Join Date
    Oct 2005
    Location
    Switzerland
    Posts
    597
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,
    Writing scenarios is a good thing. Just think "I want to reach this result". Then work on your UML schemes, then redo the process, and then again. Everytime you're not sure whether this or that approach is or is not the best one (like choosing which pattern is the most suitable to solve a given problem), start a thread about it.

    Slowly you will notice how patterns become more concrete. It took me a while to really understand that patterns weren't abstract theoretical entities created to confuse you. They are applied on a problem in order to solve it, so they shouldn't be problematic in themselves. That would be quite a paradox. So you have to confront yourself to problems in order to really get familiar with them. I think you're at that very theoritcal stage, when you don't really dare trying something because there are too many things you don't know yet. Remember it's a trap. You will improve your skills through practice, you don't have to wait to be a master to start practicing.

    The SEO Faq thread
    Dependency injection made easy: Phemto

  14. #14
    SitePoint Zealot
    Join Date
    May 2001
    Posts
    193
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Galo,
    My suggestion has nothing to do with patterns. The topic was "Daunting advanced topics.. How do I learn more?!?!"
    Not, "How should I learn patterns"

    Also, after reading your post, I think you should take my suggestion and I'll let you figure out which language to learn next.

  15. #15
    Non-Member melancholic's Avatar
    Join Date
    Nov 2004
    Location
    Australia
    Posts
    447
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hi,

    Stories for objects is an approach I've not really considered, but I can see the point of it.

    Information overload is right... I've taken a step back and wrote some code for the first time in about a week due to research.

    I'll take the advice on board and start writing code.

    Thanks again,

  16. #16
    SitePoint Zealot Serberus's Avatar
    Join Date
    Oct 2005
    Location
    Herts, UK
    Posts
    113
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Materialising research by coding always helped me clarify my understanding. I found too much research with no code just lead to analysis paralysis.

  17. #17
    SitePoint Enthusiast silicate's Avatar
    Join Date
    Nov 2004
    Location
    Toronto
    Posts
    43
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hey there,

    I think that the reason that I answered "refactoring" on this poll was because that is were I get most of my knowledge from. I have a large collection of little code bits that are derived from patterns. It's amazing on this forum alone how many people have different ideas for developing a pattern or a specific component. Any post that starts out with some code is sure to get more code in the responses. For me, taking all of those bits and playing with each one as well as applying my own techniques gives me a great understanding. Every once in a while I revisit some of these code chunks and see what features or things I can add to them.

    Building knowledge is a lot like building a sand pile. A lot of grains of knowledge are required in the base in order to make the pile higher.
    later,

    Matthew.

  18. #18
    SitePoint Zealot
    Join Date
    Dec 2004
    Location
    virginia
    Posts
    188
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Learn patterns.

    The problem is that alot of oop tutorials give useless examples (like a class that counts/adds/removes leaves on a tree, etc) so it can be hard to apply the concepts they cover to real world problems when you've never seen oop applied to real world problems. Thats why you should start with patterns because its oop for real world problems and you can immediately see how the code is useful. Thats how I'm beginning to finally get a grip on oop/ood after almost 2 years of trying. I suggesst phppatterns.com

  19. #19
    SitePoint Evangelist
    Join Date
    Jun 2003
    Location
    Melbourne, Australia
    Posts
    440
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by joflow
    The problem is that alot of oop tutorials give useless examples (like a class that counts/adds/removes leaves on a tree, etc) so it can be hard to apply the concepts they cover to real world problems when you've never seen oop applied to real world problems.
    To an extent, I'd agree. That's what so wonderful about seeing lastcraft's code examples in this very forum. It seems to me that his emphasis in advocating OOP is that it allows one to write expressive code. The naming of classes and methods (and the variable names of objects) explain what the code is doing.
    Zealotry is contingent upon 100 posts and addiction 200?


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •