Learning to design and then implement..

[xtopolis]

This is mainly directed to the more experienced people who have designed/coded PHP(or other decent languages) professionally, and on large projects, be it for as an employee or freelance.  But, anyone can answer of course.

 

I'm a pretty good problem solver, usually when I can see the problem clearly, it's easy to code the solution to something because it's logical.  However now that I'm starting to get into complex applications and very large projects, I often find myself getting lost and confused on how it all fits together.  For example, currently I'm working on a FMS(File management..) that will provide users with files managed(by name) in a database..dealing with permissions, etc etc..  However it's just very overwhelming trying to piece together the classes involved, the permissions, the dependencies..etc.  I have written it down a few times, but I guess I was never really clear during those times, or I could never foresee all the issues/dependencies..

 

So my question is:  What should I look into in order to become a better designer?...Such that I can take the now more complex problems that I'm dealing with and break them down or simplify them enough so that it's straightforward once again?

 

Is this perhaps just that I need to get a better understanding of OOP(as I'm not very strong in it yet)?  Or more something of a "take this type of class at a college"?  Any thoughts/ideas/stories of experience would be helpful.

 

Thanks.

[corbin]

Just of curiosity, where do your problems usually come along?  Do they appear when trying to piece classes together, or do they show up within classes?

[xtopolis]

I would say they show up in my classes in general.. I just don't logically follow how to design the class appropriately most of the time.

 

I remember this thread: http://www.phpfreaks.com/forums/index.php/topic,202199.0.html

(specifically: http://www.phpfreaks.com/forums/index.php/topic,202199.msg919607.html#msg919607) how keeB broke it down.  Looking at his post, it makes sense(for the most part) about how those classes work together, and what goes where, and what shouldn't go where..

 

I have learned limited OOP examples from this(sitepoint: PHP Anthology V1/V2) book.  The syntax was a little dated, but I picked up most of the new methods from reading here.  Point being, I have used their example classes, but it doesn't seem to make a lot of sense...

 

Usually what happens it seems is that I try to put too much into one class...  I'm currently taking a Java (beginning class) where I do ok coding the classes for homework assignments.  The difference here is that they tell me what the expected functionality is, and I simply create it.  But when I'm having to do it on my own, I get lost trying to incorporate it all.

 

Perhaps that clears it up a bit.  Do you think that if I got a solid understanding of classes that it would solve a lot of my design issues?  I've been deterred in the past because it was hard for me to look at example classes such as a bear object.. and then figure out how to apply that thinking to an application.

[corbin]

Hrmm, yeah it does sound kind of like you need to get a better feel for what a certain class should do.  You could just be being hard on your self though.  All big projects will run into at least a few problems.

 

 

It helps me sometimes to go through a list in my head of what methods a class will need.  For example, I know a login class should have a public method that checks if the username/password are valid.  Similarly, I know a gallery class should have a method to add an image and a method to delete an image.  Thing like that.

[VBAssassin]

Oh the memories!

 

Let me just explain a little about my site, since this will all become relevant in a minute. Also, you can see it's quite large, though not really huge (over 100,000 lines of code) by checking it out:

 

http://www.coderprofile.com/

 

First of all, it was entirely procedural. But that soon started too become to much work to update. It kept meaning complete re-writes and/or features being held back.

 

Then i started learning more OOP. So i converted a few things from procedural to objects. Such as the bbcode system,and thumbnails of images, etc. These were pretty independent classes.

 

Then i decided, i want to learn moooooreee... so i got some more books such as PHP Patterns, Objects and Practice (something like that) and some other books about OOP concepts and some UML books (designing them out in UML is a god send, also helps you understand what the books are on about). I also have the gang of four book (design patterns) which is good. They state things like "choose composition over inheritance" and other such tips. You learn the design patterns and as you learn them, they show you "good design" as well. I don't quite understand some of the patterns, but from the ones i do understand like the factory pattern... well... what can i say... i wish i had learn them years ago! They have simplified so much code!

 

Then your ready to really start coding in OOP especially when you can modal them in UML, you understand the difference between aggregation, composition, generalization, etc. A lot of "newbies" (and myself included at the time) tend to inherit everything! This simply produces a mess!

 

Also, learn what packages are (the concept is useful an organize them in to folders aka packages on the server). Read as many OO articles as you can... even if you already understand it... read it again!

 

Eventually... after just a few months you will start thinking in proper OO design ;-)

 

I would also suggest you invest in some books: amazon.com

 

Kind regards,

Scott

[Daniel0]

We have a few OO tutorials written by 448191.

 

Eventually... after just a few months you will start thinking in proper OO design ;-)

Hmm... you see, this one is actually an example where inheritance was not a good design decision

[xtopolis]

Thanks for the replies.

 

@VBA, I'll be looking into books probably after xmas when I have some money again   I had intended to get some GoF book(s) after reading some of the tuts on here.  I guess the answer is simply "keep trying" lol.  Oh the beauty of trying to teach yourself..  Also, I intend to look into learning UML sometime soon..  I just find a lot of online tutorials lacking.

 

@Daniel0, I've read all the tutorials, and except for the first one (OOP : part 1) of his, they were above my head a little bit.  While I can understand what the code does, I am not understanding how he knew how to make it that way..

 

I guess, like I said before, that my problem may be in my inability to design classes properly yet.  While I understand some of their mannerisms of how they should behave and what they should contain.. a lot of it is just .. not logical?

 

The link I cited: http://www.phpfreaks.com/forums/index.php/topic,202199.0.html .  I can see very clearly what those classes do, and what their methods should do (and be limited to), and he designed it without actually coding much..  that's what I want to be able to do, I'm just having trouble getting there.

[Daniel0]

This may seem like a no-brainer, but it helps to think about objects as... objects. Like for instance, what properties does your car have? Color, speed, accelerationSpeed, etc. What can your car do? startEngine(), honk(), switchDirection(), brake(), reverse(), accelerate(), etc. The composition thing helps with this as well. A car is not just a car, it's composed of a lot of different parts like an engine, wheels, etc. Of course, you needn't identify and model every single object you can think of, but it helps to think of objects as real-world objects. OOP is about modeling the world essentially. Learning some of the most famous design patterns will help as well.

 

If you're new to OOP then PHP Objects, Patterns, and Practice by Zandstra would be a good start. Design Patterns by GoF was also mentioned in this topic. Another good one is Patterns of Enterprise Application Architecture (PoEAA) by Fowler is another good one (also check out his website for some good blog posts about software engineering). I'd recommend you start with Zandstra's though as it's intended specifically for PHP developers. The other books that were mentioned do not use PHP syntax. You must of course try to get the big picture, not just the syntax.

[xtopolis]

Firstly: I have ordered that book by Zandstra.  I will be out of town when it arrives, but I'll be sure to post follow up questions if I have them lol.

 

Secondly: I do try to think in terms of objects, it's just that I tend to couple things in classes most of the time.  For instance, my "User" object often starts to couple with my Database object..  Perhaps in this book it will help me to see proper examples of how to separate things.  I think another thing is that I think it's "wrong" to write extra code in order to separate things when I could just lump them all together... but since my background has been 100% procedural [ i didn't use functions like objects for a long time either lol ], it's probably just a bad habit from the past.

[Daniel0]

For instance, my "User" object often starts to couple with my Database object..

 

Nothing wrong with that as long as the User object represents something in the database.

[xtopolis]

Hmm, well I don't really know enough about OOP to use the proper terminology, so when I said it coupled, we may have been thinking if different meanings.

 

Could you or anyone reading this thread post a small design of a car object, using the proper terminology?  Something basic...  What I imagine is:

 

A Car will have: wheels, gas, an engine, a driver, a pedal and brake... to start.

 

The wheels would be objects themselves I'm guessing.. and so the car would compose them?

Gas might be a property?  as well as the engine?

The pedal and brake could be methods..

 

As for the user object, what is the name for his relationship to the car?  And if he had the method drive, would that method like take an argument of this car object?

 

Perhaps you can see my line of thinking now and understand why I don't get it, yet.