Page 1 of 1

ideas for classes

Posted: Thu Jun 09, 2005 4:47 pm
by Burrito
I've gone from uber-newb to newb to n00b to postn00b and now am on exn00bbutstillnotgood with classes and I want to start using them for my next big project at work.

I am going to be designing a contact managment system that will tie into an enrollment system (for schools) and actually have some accounting functionality as well.

I know that's a very vague description of my project and you therefore might not be able to answer this question, but I'm at the hump where I can't figure out when to use classes over regular functions tied with arrays and multiple db queries.

Sure I could create a class to do all of my queries, but I want to take this a step further and put what little knowledge of classes I have into a bigger practice and actually make them do something *useful* for me.

my question then becomes: what practical application could you see me using classes for in the project I outlined above? Again I know it's vague, but I'm going to have several different departments in my company all accessing the same data on different levels (marketing, operations, accounting etc). Basically it will work like this:

a contact gets entered to the db by X department, Y and Z departments need to manipulate data based on that contact according to how it fits to their department. Department X might need to track status of how many times that contact has been touched (by their department) and need to push them along to the next phase in their "development".

I'm certain there would be a good use for a class in here somewhere, but I just can't wrap my brain around how...which is where you come in.

I'm not asking for any code help at this point, just a conceptual idea of where I might be able to use a class to accomplish what I'm after.

Again, I understand that the information I've given you is very sparse and you might not be able to provide any solid ideas as to where I could use one, but please try to think a step outside the box and let me know ANY ideas that you might have....something I've failed to do to this point.

Thanks in advance,

Burr

as a side note, I'm leaving town this evening for a week so I will return anxiously to see any responses :D

thanks again.

Re: ideas for classes

Posted: Thu Jun 09, 2005 9:39 pm
by McGruff
Burrito wrote:I can't figure out when to use classes over regular functions tied with arrays and multiple db queries.
Always.
Burrito wrote:I'm not asking for any code help at this point, just a conceptual idea of where I might be able to use a class to accomplish what I'm after.
Everywhere.

OOP is essential because there is no comparable way to manage the complexity inherent in anything but the simplest of "hello world" apps. It provides the flexibility you need to keep hitting the moving target of client requirements. It's the old story of divide and conquer: a complex problem is easier to deal with if broken down into smaller parts. The complexity is always there, even in the most abject spaghetti code [edit: better phrased as "even in superficially simple, globally-scoped code"], it's just that it hasn't been brought under control.

There is a problem though. It'll take a while before you begin to get reasonably fluent with OOP. One to two years - and more to become expert. Don't ask me how long because I'm no expert. It takes a while to learn - be prepared to tear up your code regularly as you go. That's a good sign although it won't feel like it.

In the meantime you've got to produce something functional to earn a living so I guess you'll have to study as much as you can in your spare time and introduce OOP-ish parts of code as you feel they will be useful.

First on the to do list are (1) get a copy of Patterns of Enterprise Application Architecture by Martin Fowler and (2) download SimpleTest (see my signature link). Fowler is full of good advice, and "enterprise" patterns. Unit testing is an absolutely essential OOP technique - much more than just a "quality control" tool although of course it's very good at that too.

Testing is a vital element in the picture. The first time I tried it out I was literally chortling away in front of the monitor in sheer glee. And things just got better and better from there on, the more I learned about it. Again, testing puts you in control of the code, taming the most complex of problems.

I've just spent the evening refactoring a couple of classes. A bad design had to be changed to a better one. The thing is, once you start editing, how do you know if the class still does what it's supposed to do? Tests keep you on the straight and narrow. There were almost 200 separate assertions and 700 lines of test code compared to 350 lines of code in the classes being tested. You really, really wouldn't want to check this kind of detail manually. In fact, you couldn't. You'd inevitably forget to check something. Quite probably you'd just back away too scared to make the change. With tests, it's a breeze. The test methods needed a few adjustments to take account of a slightly different API & etc, then you start with them all commented out, bring them on one at a time, and edit the class until it passes the next test. If something isn't working, fine-grained unit tests tell you exactly what's going wrong so you don't waste time blundering about trying to find the right question to ask never mind the solution. It makes coding a lot of fun since you don't tend to get stuck with horrible debugging issues. It's absolutely crucial if you're working on complicated applications where you have to continuously integrate changes and upgrades.

Incidentally, I'd never have realised the classes had nearly 200 ways to go wrong if it wasn't for the discipline of testing. Some bugs would only have been found after deployment. Not good.

It's going to take time but, if you aim to have a career in programming, I think it's essential to learn the modern, agile "best practices". It just might get you a better job if your employers are themselves up to speed. At the least it will make you a more effective and productive programmer.

Re: ideas for classes

Posted: Thu Jun 09, 2005 10:47 pm
by Roja
Burrito wrote: I know that's a very vague description of my project and you therefore might not be able to answer this question, but I'm at the hump where I can't figure out when to use classes over regular functions tied with arrays and multiple db queries.
Obviously, you are going to get extremely different answers depending on who you ask.

My answer is "When it makes sense to do so". I've joked about McGruff's 1,000 line MVC, true OOP version of "Hello, World", with 50 unit tests before. To him, it makes sense to always use OOP. To me, its closer to 60% procedural, 40% OOP.

All humor aside, you are the best judge of when to use which technique. We can't see the code, we won't be maintaining it, and we don't know the expectations of your customers. So how can we tell YOU how to design and implement a solution YOU can stand behind. We can't.

We can however provide guidance.
Burrito wrote:I can't figure out when to use classes over regular functions tied with arrays and multiple db queries.
To me, the answer is when you see clear objects sticking out. No, I'm not talking about cars and other strained metaphor-based descriptions. Users is a great example.

Almost every PHP app out there has some form of a "user". That should scream out object. With that, there is an obvious opportunity to use classes to manipulate the object. Create a user, delete a user, and so on. Once you are there, you quickly realize "Hey, creating a user should have X effect. It should affect the table like so, and it should also affect a specific row like so". Suddenly, you have your first test case.

Thats how the ball starts rolling. Very soon, you notice somewhat poorly-coded loops that when viewed properly turn into iterators. The path to OOP should make *sense*. It should be a logical transition, not something you force yourself into.
Burrito wrote:Sure I could create a class to do all of my queries, but I want to take this a step further and put what little knowledge of classes I have into a bigger practice and actually make them do something *useful* for me.
Classes are useful when:

- You learn how to use them
- They improve the maintability of code
- They improve the speed, memory, access methods, and testability

If you don't see any of those happening, you probably have tried too hard to embrace OOP too early.
Burrito wrote:my question then becomes: what practical application could you see me using classes for in the project I outlined above?
Contacts are clearly objects. Departments, arguably, might be objects (depending on your implementation). Status results would be stretching it.

As I said at the beginning, every developer is likely to give you a different answer. Your mileage may vary.

For me, there needs to be a clear value, and the description you've given definitely lends itself to some objects and classes that in-and-of-themselves would be highly beneficial, obvious, and better to implement as objects and classes than procedural code (at least at first glance, based on the description).

Good luck!

Posted: Fri Jun 10, 2005 4:39 am
by patrikG
Well, my piece of advise is somewhat inbetween Roja and McG.

Before you write a line of code, the most important thing is to have conceptualised solid and comprehensive API (use UML editors like Argo UML, Poseidon, or, if you want to fork out some real money, MS Visio).

OOP, to me, offers the best and most flexible methodology and way of coding to break down complexity. If you're no pro on OOP yet and you want to finish the work quickly, don't start reading up on design patterns, yet.

As a general rule of thumb for designing and API I love to quote Einstein's famous: "Make everything as simple as possible, but not simpler". Once you've designed the API and think it caters for everything the application is meant to do, start on designing the database - normalisation and consistency are the two most important words here. Once that's done: to the coding side of things.

OOP: Read up on stuff like inheritance, encapsulation, polymorphism (a classic is this post). Once they've become second nature to you, and after you've messed up your first project that you wanted to do in "pure" OOP and are ready to start the next, start reading up on design patterns. If they don't make sense, congratulations, that's exactly what everyone else felt about them as well the first time around. Do not get confused by the chatter about MVC pattern this and MVC pattern that, try implementing it as a separate pet project and don't listen to people who ask academic questions on whether this is actually an MVC 1 or MVC 2 or whether MVC can actually be done in PHP. If you have too much time, jump right into those discussions. If all these design patterns are still confusing after a while, let them be for a bit and return to them once you've had a "deja vu" experience with the code of a new project. The best source for PHP and design patters and how to implement them is http://www.phppatterns.com

Don't worry too much about database abstraction, it only makes sense when it's simpler than what you've used before (simpler as in: after OOP has become second nature to you ;) ) For the API point of view: databases are not important whatsoever. Data goes in, data comes out = database.

Posted: Fri Jun 10, 2005 4:46 am
by malcolmboston
im currently learning classes and after a few hours of initial problems (as burrito found out on MSN :wink: ) im blooody loving it,

from a pure syntax POV, classes are awesome, being able to do

Code: Select all

$this->user_config->css_file = file2load();
(not the best example but still..) is much more intuitive than going through 5/6 variables to get the same outcome.

i imagine ill be moving over to fully OOP in the next few months

Posted: Fri Jun 10, 2005 4:49 am
by patrikG
Forgot to mention: Harry Fuecks has a nice introduction to OOP in his "The PHP Anthology" books.

Posted: Fri Jun 10, 2005 12:38 pm
by McGruff
malcolmboston wrote:im currently learning classes and after a few hours of initial problems (as burrito found out on MSN :wink: ) im blooody loving it
If you want to run through a unit test for a class just post. As you can tell, I'm on a mission to promote testing.

Re: ideas for classes

Posted: Sun Aug 14, 2005 4:18 pm
by npeelman
Burrito wrote:I've gone from uber-newb to newb to n00b to postn00b and now am on exn00bbutstillnotgood with classes and I want to start using them for my next big project at work.

I am going to be designing a contact managment system that will tie into an enrollment system (for schools) and actually have some accounting functionality as well.

I know that's a very vague description of my project and you therefore might not be able to answer this question, but I'm at the hump where I can't figure out when to use classes over regular functions tied with arrays and multiple db queries.

Sure I could create a class to do all of my queries, but I want to take this a step further and put what little knowledge of classes I have into a bigger practice and actually make them do something *useful* for me.

my question then becomes: what practical application could you see me using classes for in the project I outlined above? Again I know it's vague, but I'm going to have several different departments in my company all accessing the same data on different levels (marketing, operations, accounting etc). Basically it will work like this:

a contact gets entered to the db by X department, Y and Z departments need to manipulate data based on that contact according to how it fits to their department. Department X might need to track status of how many times that contact has been touched (by their department) and need to push them along to the next phase in their "development".

I'm certain there would be a good use for a class in here somewhere, but I just can't wrap my brain around how...which is where you come in.

I'm not asking for any code help at this point, just a conceptual idea of where I might be able to use a class to accomplish what I'm after.

Again, I understand that the information I've given you is very sparse and you might not be able to provide any solid ideas as to where I could use one, but please try to think a step outside the box and let me know ANY ideas that you might have....something I've failed to do to this point.

Thanks in advance,

Burr

as a side note, I'm leaving town this evening for a week so I will return anxiously to see any responses :D

thanks again.
I think for one that most people get confused between OOP and PROCEDURAL because they think it (OOP) is some unnatural beast. Even with OOP, you are still calling functions and setting variables. OOP just lets you 'box' things up into a more cohesive unit (encapsulation). Yes it does more than that, but that's the basics. It also can make your code easier to read. It appears to me that your question pertained more on 'how' the different depts in the company would utilize/act on the data. I think you need to:

1) write out as many things each dept. has to do to the data. ie: dates/times accessed, who accessed what...
2) think about how the depts. interact with each other, will any one dept be able to alter data that another
dept is working on? Certain data may need to be 'locked' (read-only) while 'in-use', maybe even an indication
that the data is being used and that it may not remain the same (decisions could be made on inaccurate
data).
3) etc.

Norm