PHP anthology, OOP and classes - which way do you design?

[steve_e]

Hi -
I'm just trying to teach myself PHP via Kevin Yanks and Harry Fuecks books here, and I'm trying to get my head round the Class and OOP based approach. (I'm not a natural programmer so apologies if this seems terribly basic!)

I've spent a fair amount of time going through the Access Control chapter and code, and I have a real problem with understanding the order in which a programmer would put together scripts like this.

The chapter first takes us through the development of the classes and functions to be used (sessions, authentication), and then develops the scripts for making use of those objects.

Is that how most of you develop an application? How do you know what classes and functions you're going to need before you start writing the script that uses them? I can more or less follow the code that Harry has written, but I don't think I have the kind of brain that would enable me to start on a project and have a clear enough vision of what is required to enable me to start with all the classes and functions.

Is there something I'm missing - should the design already have taken place at this stage with some sort of analysis technique?

[ghuytro]

While I realize this might not help you much right now, but experience definitely makes things easier. You'll find it much less daunting in the future to approach designing and coding a solution as you have the benefit of past experience to fall back on.

That being said, just remember that any code you write is intended to accomplish something. So having a clear idea up front what the requirements are for the particular problem you are tackling should be done before any code gets typed. Requirements are just that - what the various steps are in the task, the order they are to be performed, any constraints, and the types of technologies/methods you intend to use.

Take a simple login authentication system as an example. You would first start off figuring out what the process is involved in someone logging in:

1. Present user with a login screen.
2. User enters login data
3. Verify login information against stored login data.
4. If not valid, display error and make user try again.
5. If valid, log the user in.

Next you might ask and answer questions like:
1. How will I stored the login data - database, text file, xml?
2. How will I indicate that the user is logged in - session variable (what values)?
3. How will I handle the case if the user has forgotten their login information?
4. etc. etc.

Only once you fully understand the various steps in the problem and have decided on a range options - only then do you really begin the process of architecting the application and then coding.

Now, in terms of the style that you choose to code - procedural or OOP you will get a range of opinions here and what you should do really depends on your particular circumstances. If your goal is to learn OOP, then I would stick with trying to accomplish things in an OOP manner.

I'm sure others will have suggestions on reading material that should get you pointed in the right direction but I think that if you work your way through the book and take the time to learn and understand each chapter, you will be in good shape in the end.

And one of the great things about coding using PHP is that you can just play around with things and experiment and try things out. So once you feel that you've got a bit of foundation, try some things. Experience will only help you in the long run.

[steve_e]

Thanks ghuytro for that full answer!

I had an uncomfortable feeling it would be down to experience, but it's good to get an account of your top down approach!

Regards, Steve.

[McGruff]

http://www.developerspot.com/tutoria...ent/page1.html

[steve_e]

Thanks for that useful link McGruff. Once I've understood the concepts and tried working through some simple projects I'll see if I can work through the test driven development method.

If anyone has time to comment on this, I'd be grateful. I thought I'd try to do what ghuytro suggests and try it out by playing around with this first small project. So I'll see if I can create a 'Links' application:

This is what the application is for: it will allow users to input details of useful websites (URL, description etc) in a number of different categories, and then have the results displayed on a page within a website.

It will require, therefore, 4 admin pages, and an output page:

Admin pages
----------

Main admin page: Will allow users to select from the following options: add new link, edit existing link, deleting a link.

Add new link: will have the following input fields: URL, Name of site, description, date added, name of person who added the link.

Edit existing link: Selecting link from drop down list and loading same page with form details (PHP_SELF).

Delete existing link: As above.


Links Page
----------

Will display the links, by category, and will generate a list of category headings at the top of the page, which are links to the categories further down the page.

------------------------
I will use MySQL to store the data.
Access to the admin page will be controlled by .htaccess, so there is no need for authentication.

It seems at the moment that I will need the following elements:

The five pages described above
One MySQL table containing the link data
Two classes, a MySQL class and a Link Class, with a number of functions (not yet specified).

Does this sound like a reasonable requirement with which to begin 'architecting and coding the application'? Or should I be doing more work and have a closer spec before I think about creating the database and php files?

Apologies for the naivety - I don't have a team of people to learn programming techniques with or from. Just the Sitepoint books and this forum...

[sweatje]

I used the "links" example for my article "Industrial Strength MVC". You could take a look at the source code for it, but it does not match your requirements exacts (I used Postgresql for a back-end, and pushed many of the business logic/referential integrity things down to that layer. Also, IIRC, I implemented "catagory a a time" editing, where you could change or delete any/all of the links in a given catagory after selecting it on the admin catagory view.)

Anyway, might be worth poking around in it.

[ludwigs3rd]

Even in the OOP PHP articles that I see here I find PHP mixed in with HTML. Why isn't MVC pushed more in web programming? I'm reading a good book on UML and ecommerce. I'm also reading a book on UML and OOP thought process. I'm not a big UML guy, but from my recent reading/learning it sure helps through the thought process. Maybe I'm just starting a rant here, but I can't stand it when I find a huge PHP project that I want to tweak and there are echos in classes.

[sweatje]

Even in the OOP PHP articles that I see here I find PHP mixed in with HTML.

In my article (from the post above yours)?? IIRC, there was only one or two prints, and they were burried in some of the procedural debugging code, nothing that was touched during normal opperation of the code.

Or were you referring to OOP PHP articles in general?

[lastcraft]

Hi...

[QUOTE=lI'm reading a good book on UML and ecommerce. I'm also reading a book on UML and OOP thought process. I'm not a big UML guy, but from my recent reading/learning it sure helps through the thought process.[/QUOTE]

Which books? Are they any good?

yours, Marcus

[steve_e]

Thanks Jason - interesting looking article. I'm not trying to build a serious links page though. I just selected that as a way of trying out my first small PHP project using OOP/classes etc, to better understand the order that 'proper' programmers would approach a task like this.

Regards, Steve

[lastcraft]

Hi...

That being said, just remember that any code you write is intended to accomplish something.

Definitely. At the point of typing you must know exactly what output you want...

So having a clear idea up front what the requirements are for the particular problem you are tackling should be done before any code gets typed.

...but this is a major schism in the industry right now. It can work on a small project if one experienced person completely understands the system and can make the correct intellectual leap on the first go. If not it can be horribly accident prone.

You actually only need enough requirements for the next bit of code. It's actually very awkward getting all requirements before you start. By the time you do all of that and start coding they have usually changed anyway. Even if they haven't, trying to look that far ahead gives a very blurred vision. Most modern methodologies follow an iterative approach.

For example RUP will start with use cases. The early, most important, use cases are fed into the design, code and test phase before the next batch is ready. More of a pipeline approach. Each feature may have a two or three iteration jpourney to fruition. You may have to recode when a later requirement screws up an earlier one, but the fast feedback on the requirements gathering more than makes up for it. It means later requirements are more likely to be correct. Iterations are usually about a month at most. You do get a higher proportion of requirements gathering at the start, and less at the end obviously.

eXtreme Programming not surprisingly takes a...er...more extreme view. Iterations are typically 2-4 weeks. Nothing is decided before an iteration. The customer writes a load of user stories (lightweight use cases) sitting with the developers. From this an acceptance test is written. No design is added which is not needed for the coming iteration, a process known as YAGNI (you arn't gonna' need it). The system works because comprehensive regression tests and minimal code make the code base easier to refactor. This reduces the cost of changing the code later (you will anyway).

Scrum has the even simpler project backlog. You have a list of tasks written by managers. The developers put time estimates on each task. From previous cycles you know how much the development team can do in one iteration (always 30 days in Scrum). The project manager simply takes the top slice of the backlog whose estimates add up to past performance.

The main thing is that you can actually dribble requirements into the development process. It's actually very effective.

If your goal is to learn OOP, then I would stick with trying to accomplish things in an OOP manner.

I think this is going to be the deciding factor. One of the major benefits of OO is that it is easy to change your mind later. You can leverage this by solving just one part of the problem at a time. Adding another requirement will force you to change your mind occasionally and redesign (called refactoring). You will be overwhelmed if you try an OO design whilst staring at a full list of requirements.

Take one of the requirements, code that. Then another, then another. I think you will find it a lot easier. What's your first requirement?

yours, Marcus

[ssx-gun]

One way to put OOP effectively into your code. Is to take your requirements and underline all the important Nouns, these will be your classes. And then underline your important verbs, which will be most of the functions you need. "is a user" would be a function not just "is". I think I read this somewhere before but I am not sure of the exact source.

[Itshim]

Nice Tip ssx-gun!

I had never heard that before, but I can see how it would be very useful.

I was fortunate enough to work as a QA/Tester for four years , so I completely understand what a requirements document is and how to create one. I am kind of in the same league as steve_e, and looking over my requirements document for the project I am currently working on it took a matter of a few minutes to figure out how best to split it up.

Thanks,
Itshim

[lastcraft]

Hi...

One way to put OOP effectively into your code. Is to take your requirements and underline all the important Nouns, these will be your classes. And then underline your important verbs, which will be most of the functions you need.

I have started to distrust this method (I do seem to be in a contrary mood today), because you end up with very passive classes this way. I am still thinking about this but my reasoning goes something like this...

Imagine you are suspended a few metres above a production line. You are looking through a camera and you take a single freeze frame. What can you see? Well you see the parts that are being assembled and some things like conveyor belts. By freezing the motion though you have lost the real action. We are in the business of automation, so that's a big loss, but that sems to be what happens when you take a nouns approach.

Now we go back to full motion. Suddenly we see the flow of information, but more importantly we see the jobs that the different people do. We lost the roles and responsibilities by freezing the image. We lost the actual "doing" of stuff. That seems to leave 95% of the problem still to solve.

The experience that lead me down this path was that after you do the noun/verb split you then get stuck. You then end up with a few god classes doing all the work of passing the passive noun objects around. This ends up rather procedural in feel, and if you took nouns to be data and verbs to be functions I think you would get the same result.

I now prefer doers as classes. Suppose I was scraping some links from a web page. Rather than think about a "web connection" and "page" with "links" that I am interested in I now have a "link extractor" and a "page fetcher". I may not have a page or link object at all, they might just be strings. You seem to get smaller code this way and make more progress initially.

So I now have a modified version as a work in progress...

Classes = roles, e.g. class PersonFinder
Passive objects and variables = nouns, e.g. $person
Aspects/Decorators = adverbs, e.g class WithCaching
Verbs = methods, e.g. $person = &$finder->findByName()

yours, Marcus

[Manor]

This is exactly what I discover in Object Design: Roles, Responsiblitys and Collaborations. (probably where you found aspects of your idea in also ). Im reading it at the moment, and already this way of using objects (roles), that they are actually resposible for doing things, makes things 100x clearer to me.

The classes/objects now actually are resposible for doing things, you can assign responsibilitys to them easily because their role suggests them almost naturally. You now have the feeling (at least I do), that the objects are not just object, but are there to do stuff that has meaning in the proces of accomplishing the requirements.

I totally agree with Marcus' opinion on doers as classes, you will see that your objects have a meaning, and that gives a lot of confidence.
Designing this way lets you feel that you know what you are doing, and more importantly, it gives you the idea that there are more correct ways to get a good design (which, offcourse, is true ).

So now, after my rather enthousiastic reponse , ontopic: Thinking in roles will help you get further, it did the same trick for me.

[lastcraft]

Hi...

This is exactly what I discover in Object Design: Roles, Responsiblitys and Collaborations. (probably where you found aspects of your idea in also ). Im reading it at the moment, and already this way of using objects (roles), that they are actually resposible for doing things, makes things 100x clearer to me.

The book can be stodgy, but it's still a favourite. Everything in it is just so damn correct.

The real kicker for me was not so much that book, which I came across via CRC cards, but using MockObjects in testing. Testing a passive class just ends up as writing data in and reading it back. Hardly enthralling and a sure sign it's a waste of space. Real classes have to cooperate with other classes to achieve a result and mocks naturally highlight this.

yours, Marcus

[steve_e]

Thanks all, and thanks SSX-Gun for pointing out that way of looking at things (classes as nouns and functions as verbs).

I think I need to just start with a guideline such as this, and when I work my level of experience up, I'll probably understand the complexities better which will let me view a production line while suspended and maybe look at things in a different way (thanks lastcraft, that gave me vertigo for an hour or two!!).

I appreciate the time you've taken to help me understand the concepts!

Regards, Steve.

[Refresh]

Off Topic:


Has anyone noted that when you look at that article in printable form, the order of the pages has been reversed? Makes it cumbersome to understand...

I think you (steve_e) are lucky because you don't have a functional programming background. Take it as an advantage :-) A lot of people want to start OOP after they've mastered functional programming, but most of what you've learnt in functional programming doesn't apply... It's really another way to think about a problem, a bit like "the glass is half full" vs. "the glass is half empty" issue.
Well that wasn't the best example ever, but yeah ok never mind... ;-)