Page 1 of 1

designing with classes - pointless?

Posted: Mon Jul 10, 2006 12:12 pm
by cjbilly
Hello

I'm currently designing a online system for real estate upload. The developers would upload real estate and users would review the uploaded estates.

I can design the system with a user as the parent class and then the developer would extend it (as it has more functionality / properties). But, surely, it would be easier to display pages based on a user type stored in a mysql db? Ie. a 'user' table would store all details about users and developers - with a type field to determine what type of pages would be shown to those people.

I suppose my real question is : why design a system using classes (esp in this instance) when using a db and simple if then else statements solve the problem? Surely, sessions store persistant data and so what is the point having these classes and objects?

I understand that objects make sense in an environment where the state of something changes frequently (such as a shopping cart), but when you define items / people / processes as classes you add another layer to your programming that could be deemed as unnecessary. I suppose it's down to individual circumstance...

Sorry - just confusing myself but does anyone have any _logical_ reason for using classes in the environment I'm talking about?

Cheers

Cj

Posted: Mon Jul 10, 2006 12:32 pm
by Jenk
classes do no negate the need for a data source (e.g. database, or flat file etc etc.)

essentially, classes are used to 'group' related functionality together.

these groups are identified as patterns

In your example, I wouldn't create a class for the user and anything related to the user, as it would be what is commonly known as a "blob" class - i.e. one class that does everything.

Re: designing with classes - pointless?

Posted: Mon Jul 10, 2006 12:40 pm
by Christopher
cjbilly wrote:I suppose my real question is : why design a system using classes (esp in this instance) when using a db and simple if then else statements solve the problem?


This seems a pretty common question around here for some reason. I guess I would first want to ask a couple of questions:

- What is it about "using classes" that seems so excessive in this case? Is it that they are unfamiliar to you and you would need to learn more about how to use the class construct? Or do you find them so much more difficult to use that they it probitis their use for this site?

- Is this site in fact so small that a few "simple if then else statements solve the problem"? I assume by that statement that the whole site would be maybe 100 lines of code with 5-10 if statements max? If so it may just be a simple Transaction Script with minimal needs for functions or classes.
cjbilly wrote:Surely, sessions store persistant data and so what is the point having these classes and objects?

I can design the system with a user as the parent class and then the developer would extend it (as it has more functionality / properties). But, surely, it would be easier to display pages based on a user type stored in a mysql db? Ie. a 'user' table would store all details about users and developers - with a type field to determine what type of pages would be shown to those people.
You seem to have some misunderstanding about classes/object that may be at the root of your question. Classes/object are not for "persistent data" any more than any other data structure is. They are made persistent in the same ways as other data.

I also note that you mention other developers and that you might be creating code for them to reuse. That sounds like a more complex design issue than the couple of if statements mentioned above. Designing reusable code is a difficult thing to do well -- the design is very important.

You are also venturing in database schema design -- which again has no more direct effect on classes than other data structures. So how to define page types in the database and the code are slightly separate (though related) issue.

Some reasons to use the class contruct are pretty basic design goals: to reduce code duplication, to provide well defined interfaces, to reduce dependencies, to modularize code for testing purposes. All of these goals can be achieved by a good programmer with or without using the class construct -- but as classes were explicitly designed to make meeting some of these goals easy -- why code the hard way to achieve them?

I would be interested to know more details about the application you are building.

Posted: Mon Jul 10, 2006 2:55 pm
by cjbilly
- What is it about "using classes" that seems so excessive in this case? Is it that they are unfamiliar to you and you would need to learn more about how to use the class construct? Or do you find them so much more difficult to use that they it probitis their use for this site?
Basically, the way I can see it working is that if I define a user of the site as an object, I will then have to store this info in the DB anyway (ie. as a registered user). Why bother with the object properties when it's stored in the DB?
- Is this site in fact so small that a few "simple if then else statements solve the problem"? I assume by that statement that the whole site would be maybe 100 lines of code with 5-10 if statements max? If so it may just be a simple Transaction Script with minimal needs for functions or classes.
Not at all - I imagine that this site will be quite comprehensive but I need clarification or, I suppose, similar examples where classes and objects have been used... I just need that 'ahhhh!' moment when I really understand the importance of classes rather than 'use classes because it makes reuse / viewing / coding easier' ...
You are also venturing in database schema design -- which again has no more direct effect on classes than other data structures. So how to define page types in the database and the code are slightly separate (though related) issue.
Absolutely, one defines the other (to a point). By defining what properties and methods my Classes have - I am indirectly defining my db schema to a certain extent. How one object interacts with another (esp parent-child) does have an implication on how my 1-many db design eventually ends up.
I would be interested to know more details about the application you are building.
Certainly. It's a repository of real estate. Real estate managers (what I called developers in the 1st post - sorry for the confusion) can register and then upload real estate to the site with desc / images / other associated meta-data. Each piece of real estate can have any number of plots on it for sale. Any member of the public can then register as an 'investor' and look / save real estate of interest in their members area which they can then come back to at any time. I, as the site owner, can look at stats, masquerade as a real estate manager is case of support issues, check payments etc. That's the basic premise of the system.

I very much appreciate the comments so far and look forward to any further discussions.

Thanks

Cj
[/quote]

Posted: Mon Jul 10, 2006 3:44 pm
by Christopher
cjbilly wrote:Basically, the way I can see it working is that if I define a user of the site as an object, I will then have to store this info in the DB anyway (ie. as a registered user). Why bother with the object properties when it's stored in the DB?
I'm not exactly sure about the question, but obviously if values are "stored in the DB anyway" then they need to be loaded into memory in some manner -- ususally an array in PHP. And since there is usually a set of functions that are used to do things (like validate that new values are correct) then it often makes sense to combine those functions and the array together in a class. The pattern Active Record describes a way this can be done that many programmers have repeatedly found works well for simple data like User Records. It has a simple basic interface, but you can add any methods specific to your site's users.
cjbilly wrote:Not at all - I imagine that this site will be quite comprehensive but I need clarification or, I suppose, similar examples where classes and objects have been used... I just need that 'ahhhh!' moment when I really understand the importance of classes rather than 'use classes because it makes reuse / viewing / coding easier' ...
Well classes are not really that magic -- but they have been found to be a pretty useful language construct. They obviously allow you to associate a set of function and variables in a common namespace. That helps reduce external accessable dependencies that can cause side effects and hard to track down problems. The also, mainly, allow you to program in a data centric manner that can be very handy. You descriptions of your side are very data centric so I can see how this may be a benefit to you.
cjbilly wrote:Certainly. It's a repository of real estate. Real estate managers (what I called developers in the 1st post - sorry for the confusion) can register and then upload real estate to the site with desc / images / other associated meta-data. Each piece of real estate can have any number of plots on it for sale. Any member of the public can then register as an 'investor' and look / save real estate of interest in their members area which they can then come back to at any time. I, as the site owner, can look at stats, masquerade as a real estate manager is case of support issues, check payments etc. That's the basic premise of the system.
One of the first things I do with a site like this is to mock up a Gateway class to the "piece of real estate can have any number of plots on it for sale". I usually just put an array of test row data in it that I can use. Then I start building the code that uses the Gateway to find the actual use cases. As I need more methods or properties in the "PropertyGateway" I add them -- that way I'm only coding what I actually need. Once I get all the use cases working, then I add the database code in the Gateway as needed. I like that it keeps all the SQL in one place and I often find some clear database efficiencies at that point because I can see the full picture.

Posted: Mon Jul 10, 2006 3:57 pm
by alvinphp
I second everything arborint says. Creating a simple function versus a simple method in a class is not much harder. And Class != OOP which some people seem to be inferring. A class is just one small piece of OOP and, ironically, a function is also part of OOP (which is called a method). To compare a simple function to OOP is like comparing your parking brake to a car.

Posted: Mon Jul 10, 2006 5:51 pm
by Roja
Let me take a different approach, and walk you through the differences on each side.

We'll use your example of users, stored in a database.

Procedural:

- I'll need a function to connect to the database.
- I'll need a function that will pull the user from the database.
- I'll need multiple functions that will change the user in a variety of ways (change of address, last name changed due to marriage, etc)
- I'll need a function that will save the user to the database.

Now, I've built those (lets say 6 functions). In each, I've used SQL to do what I need to do.

A month later I need to add a new property to users - member status. (Its a boolean yes/no). To do so, I have to modify all six functions, because its SQL, and hardcoded.

A month after that I need to use this members system in another program, so I can have multiple apps with a single login system on my site (say, forums and a Wiki). In the procedural world, I'm going to have to rewrite portions because, again, the SQL is hardcoded.

OOP:

- I need a method to connect to the database.
- I need the ActiveRecord pattern. It allows me to store, modify, and retrieve specific information from the database (In this case, a User object)

A month later, I need to add a new property to users. Not a problem, I just update the record, and possibly add a new modify method.

A month after that, I can easily use the ActiveRecord User class I've built in another script with a few minor changes.

------

Its important to understand that both Procedural and OOP have the ability to solve your problem. Both can do so well.

The reason many people advocate OOP is that it brings additional benefits that Procedural (unless extremely well designed) cannot bring. Things like encapsulation, reusability, and portability.

Better, OOP offers testability, while Procedural almost entirely cannot do so! Having sections of code that you can test reliably means they won't end up breaking when NewGuy joins the dev team and makes a bad commit.
cjbilly wrote:I just need that 'ahhhh!' moment when I really understand the importance of classes rather than 'use classes because it makes reuse / viewing / coding easier' ...
Leaving out reuse and viewing does in fact limit the discussion quite a bit, but encapsulation and testing are huge benefits too.