Oh dear, I can't do .... OOP design

[Ely]

I'm learning ASP and thus VBScript at the moment and to be honest i'm finding it pretty logical. Maybe i've not done the tricky stuff yet ?

[chilliChill]

I think it's where you start from to be honest, I started doing functional programming , and moved onto OOP, and this cause me the problems, the whole OOP concept was so alien to my normal programming style, it took a while to get to grips with it.

moving from

function saverecord(lctype)

if lctype = 'cust' then
open table
save customer
endif

endfunction

to :

define class customer as dataclass
proc save
open table
save customer
endproc
enddefine

so:

saverecord('cust') becomes ocustomer.save()

I found that being able to define classes, and create objects from them which could store their own data and know how to handle themselves really useful.

Did take me a while tho, but someone said to me, if it's a noun, then it can be an object.

eg Cashmachine, could be an object, and it could have properties like
: amountofmoneyleft_n
: date_d

and methods (or actions)like

proc dispensemoney(lndispense)
dispense()
amountofmoneyleft_n =amountofmoneyleft-lndispense
endproc

Being able to pass objects to other objects is really useful, as is operator overloading, so I could add objchips() to objbigMac() to produce a new object called valuemeal()

Pretty cool.

[Jimaroid]

I think it's where you start from to be honest, I started doing functional programming , and moved onto OOP, and this cause me the problems.

I think you mean procedural programming as (functional (programming (is (something (else (entirely)))))).

[SheepShifter]

Heh. I've written a OO system for form management in PHP4. Actually it was inspired by Java. PHP4 doesn't have much functionality when handling classes and such.

I guess this is exactly what you're trying to do. I could mail you the code if you want.

Code: Select all

$elements = array(
  'Login' => new divider(),
  'Username' => new textfield('username', 16),
  'Password' => new password('password', 16),
  'Post display' => new divider(),
  'Screen name' => new textfield('fullname', 32),
  'Function / guild' => new textfield('function', 48),
  'Personal' => new divider(),
  'E-mail address' => new textfield('email', 48),
  'Gender' => new combobox('gender', array('male' => 'Male', 'female' => 'Female')),
  'Birthdate' => new date_input('birthdate', 64, 0),
  'Country' => new textfield('country', 32)
);

$form = new form('Create account', $elements);
$form->display();

The class has a number of functions to validate user input. It also has a function which saves the data into a database. I even wrote an extension of the form class to handle HTML input (previewing etc).

[skab]

Ah, forms. I got something similar, but since I don't like OOP I tried a more data-structure oriented approach, like (simplified code):

Code: Select all

$form = array (
	array (
		'type' => 'fieldtext',
		'name' => 'myname',
		'caption' => 'First Name'
	),
	array (
	....
)

echo formBuild($form);

It's the classic way of code/data separation, big data structures and a mighty function to "execute" them. You can design structures that work like an own meta language.

That approach has some huge advantages, the nested arrays can be saved somewhere as needed, could become the "user preferences file" for your app, since they are quite easy to read and change and don't contain any actual function/method calls, just pure data. And if you need a more standard oriented data format, those arrays have a similar structure to XML, so if you need that data as XML files, it's not too hard to write an appropriate XML-parser and then feed the resulting PHP array-structure to the above routine like before.

I use those nested associative PHP arrays for nearly everything now and this has proven to be superior to the widespread OOP approach. One of the reasons why I never used OOP in PHP so far. Again, I see the idea, it just doesn't translate to a real life benefit so far. Especially when using it with a rather slow interpreted script language.

Use what you like best, just make sure your code is clean and tidy. Actually I find it weird that nowadays I'm defending the good old ways of procedural programming just the same as 10 years ago everyone had to defend the then-new OOP.

Just my tip of the week: Check out PHP arrays, it's worth it! (BTW, if you know Perl, think "hashes" )

[SheepShifter]

I did go with such a solution at first, but it produced gigantic arrays which really weren't any fun to work with. Also, the OO approach has a a few advantages over the procedural one, even when programming in PHP.

The main advantage is a lot of your code is re-usable. The differences between, say, a text and a password field are marginal. Your password class could be an extension of your textfield class which only overrides the output function.

Once the basic class structure is finished fetching the output of the whole form is really simple. You can do something like this:

Code: Select all

$result = '';

foreach ($this->elements as $cap => $obj)
    $result .= $cap . ': ' . $obj->get_value() . "\n";

When you want to introduce new component types (like comboboxes, for instance) you don't have to change your form functions. You just add a new class (which is an extension of the main 'component' class) and you're ready to go.

(Oh dear, I'm defending OOP. I hear this is really old-fashioned. )

[skab]

Hm... still don't see any real advantage. The things you mentioned can be done just as easy with the procedural approach. It's not better or easier, it's just different.

And compare the both versions of form-definition-arrays above, both are basically the same, one is an array of objects, the other of simple strings that acts as commands and data. Both are basically just the same size, code-wise, if you replace my clear-text approach with simple parameter lists similar to the new object parameter list (instead of "array ('type' => 'bla', 'size' => 10") just array ('bla', 10)).

About re-usability, this would be a point with really complex objects, but in my forms-module I simply copied the 5 lines of code from the textfield code and was done .

If I wanted to extend my library because it's missing something, you're right, I could simply add a new class to that object and had that function added. But ask yourself, if your forms-library/object/module is missing something, why not simply add that functionality to the whole module instead of patching it with an additional class? Thats the whole point of re-usable modules, you add this functionality to that module and every script you write gets the added value.

And BTW, it's just a single form function that calls itself recursively if I get nested arrays. I implemented columns and row "types", so even complex form layouts are possible. And yes, those nested arrays are indeed nasty blocks of code. But you won't get it any clearer and less obfuscated with OOP, so there...

Again, use what you like best, since that's what you probably do best. Just write clean code, that's all.