Object Oriented web scripting

[anatak]

I understand the concepts of OO and I see the re usability of the code as a big advantage but I don't know how to apply this for webdesign.

 

Every time I start to try to create classes I keep wondering why do OO in webdesign ?

How would I design for example an authentication in OO ?

 

For authentication I need

-username and password from a webform

-clean up the username and password to avoid sql injection

-connect to a db

-run a query to see if the username exists

-run a query to check if the password is correct in case the username exists

-return the result (1 username does not exist 2 username exist, password is incorrect 3 username and password combination exist)

 

the way I was thinking to do this is like this

 

class authentication with

var username

var password

 

method clean_input (a function to ensure against sql injection)

 

and then I am lost

does the db connection become a different class ?

to run the query is a method from the db connection class or a method from the authentication class or maybe a new class ?

 

Any help would be greatly appreciated.

 

kind regards

anatak

 

[Mchl]

Look how they did it in Zend Framework for example

[Daniel0]

I understand the concepts of OO and I see the re usability of the code as a big advantage but I don't know how to apply this for webdesign.

 

If that's the case then you have not yet fully grasped what OO is about

[xangelo]

OOP doesn't have it's place in every application. A big part of learning OOP is deciding when it makes sense to use it. I personally would keep the MySQL class separate. That way, all your scripts could have access to it, and as an added bonus, you would be able to easily extend your current script, or even move the database class to other applications.

[Daniel0]

OOP doesn't have it's place in every application.

 

Why not?

[xangelo]

Perhaps application was the wrong word to use, but I don't feel that OOP has it's place every time. For example, a simple website wouldn't need to utilize OOP principles, but one that needed such things as a user-management system and news system would be best done in OOP.

[Daniel0]

How can you know that your simple website won't evolve into a more complex one later on? That something is simple right now is not an excuse to skip the design phase.

[xangelo]

Personally, I don't see the point in doing it for a small website. Granted, if there IS the chance that you'll be expanding, why not take the extra precautions and make sure you can do so easily. But if you go through all the planning, and then see that it's still going to be something small and simple, why spend the extra effort doing things that you won't benefit from.

[waynew]

I'm working on a small website at the moment. I have to fix the code of another. Small shopping cart. It's not OO, which means that I have to go from page to page, fixing each piece separately and minding my ass, keeping an eye out for dependencies. If the site was OO, my job would have been far less tedious, quicker to do and therefore, cheaper to do. OO is not only self-pleasing, but it can also save the client a lot of money. Truth be told, since I started using OO, I feel dirty whenever I don't.

[Eric_Ryk]

How can you know that your simple website won't evolve into a more complex one later on? That something is simple right now is not an excuse to skip the design phase.

OOP is a typical implementation of designs. However, that does not mean that applications that are properly structured and designed cannot be built without OOP. It seems to me that a lot of people seem to have this tendency to make absolutely everything an object besides the index page. By that point it's just absolutely ridiculous. Some code simply does not need to be in an object format.

 

Some applications are small, will remain small, and are better designed without objects. For those that this applies, using objects would be a waste of trying to take something that is not suited for objects and making it OOP.

 

People, for whatever reason, equate OOP with program design and design patterns. Neither is reliant upon the other, OOP is simply a means to an end.

[Daniel0]

No, you're right, it does not need to be OOP, but neither does it need to be any other programming paradigm. It's entirely possible to create poorly designed application using OOP and it's also possible to create well designed applications using imperative programming. However, saying that it's ridiculous making everything an object in OOP is... ridiculous. In object-oriented programming you make objects. OOP applications generally lead to good maintainability and design when it is actual OOP and not just procedural programming with objects so to speak because OOP is closely tied to OOD. I often see people here who are "using OOP" when they are in fact just emulating namespaces using objects so to speak. That's not OOP and just because you have an object doesn't mean the paradigm is OOP.

 

Also, if making everything an object is ridiculous, does that mean that major languages such as Javascript, Python, and Ruby are ridiculous? Because you know, in those languages everything is an object.

[Eric_Ryk]

No, you're right, it does not need to be OOP, but neither does it need to be any other programming paradigm. It's entirely possible to create poorly designed application using OOP and it's also possible to create well designed applications using imperative programming. However, saying that it's ridiculous making everything an object in OOP is... ridiculous. In object-oriented programming you make objects. OOP applications generally lead to good maintainability and design when it is actual OOP and not just procedural programming with objects so to speak because OOP is closely tied to OOD. I often see people here who are "using OOP" when they are in fact just emulating namespaces using objects so to speak. That's not OOP and just because you have an object doesn't mean the paradigm is OOP.

 

Also, if making everything an object is ridiculous, does that mean that major languages such as Javascript, Python, and Ruby are ridiculous? Because you know, in those languages everything is an object.

In every single on of those example languages that you listed there can still be procedural code that makes use of the objects, and that's the point. Other code simply is not related to objects, it cannot be "nounified" (so to speak) in any way, shape or form. OOP is about taking things that can be represented by objects and making them objects. If something is not suitably recognizable as an object, why would you make it one?

 

The problem that I see is that people have an algorithm that runs perfectly fine, but become so fixated on making everything an object that they take the algorithm and turn it into an object when that offers no improvement in the design or efficiency of the script. Don't get me wrong, if turning it into an object would improve the design, I'm all for it, but if not, I see no reason to.

 

I feel that proper design includes the analysis of determining whether something should be procedural (that includes functions) or object oriented.

 

And don't get me wrong; I use OOP all the time when creating applications, but before I use it I ask myself if the components are better represented as objects or procedural code.

[Daniel0]

Give me an example of a specific thing that cannot logically be an object.

[Mchl]

a person

 

(ok, ok... I know it's not what we're talking about here )

[Daniel0]

object:

- anything that is visible or tangible and is relatively stable in form

- a thing, person, or matter to which thought or action is directed

 

Even in English a person is an object.

[Mchl]

Surely it is. But then ask lawyers

 

But it was just a an OT joke.

[Eric_Ryk]

An algorithm for parsing a string in a given format. Sure the "algorithm" is a noun, but realistically it is a process/action.

 

Sure it COULD be in object format, but a function would be more suitable.

[Daniel0]

Not true. Check out Zend_Json_Decoder (note that it's a noun). It provides an interface for getting JSON strings into arrays thus making JSON support possible for PHP versions below 5.2.0.

 

An analogy is a car factory. You order a car with specific specs and the result of this is a car. You don't care how the car is made, you just want a car. This is the same concept. You provide a JSON string and you get an array back like you expected. How this is parsed is completely irrelevant. The JSON parser is thus a logical object providing a known interface, but an unknown (and irrelevant) implementation. This is one of the design principles in OOP: "Code to an interface and not to an implementation". It would be impossible to encapsulate this in procedural programming and it would thus be more difficult to maintain. Although you might have created a wrapper/main function that will call the individual other functions, there is nothing preventing the people using the API from doing that instead. Your implementation is therefore locked unless you want to upset the developers of the dependent components because you break their stuff. Had you taken an OO approach and encapsulated the process then you would have overcome this problem. You can change the implementation as much as you like as long the the interface remains the same (and it still returns the expected output of course).

 

Now tell me, how is an function more suitable for this task?

[Eric_Ryk]

Not true. Check out Zend_Json_Decoder (note that it's a noun). It provides an interface for getting JSON strings into arrays thus making JSON support possible for PHP versions below 5.2.0.

 

An analogy is a car factory. You order a car with specific specs and the result of this is a car. You don't care how the car is made, you just want a car. This is the same concept. You provide a JSON string and you get an array back like you expected. How this is parsed is completely irrelevant. The JSON parser is thus a logical object providing a known interface, but an unknown (and irrelevant) implementation. This is one of the design principles in OOP: "Code to an interface and not to an implementation". It would be impossible to encapsulate this in procedural programming and it would thus be more difficult to maintain. Although you might have created a wrapper/main function that will call the individual other functions, there is nothing preventing the people using the API from doing that instead. Your implementation is therefore locked unless you want to upset the developers of the dependent components because you break their stuff. Had you taken an OO approach and encapsulated the process then you would have overcome this problem. You can change the implementation as much as you like as long the the interface remains the same (and it still returns the expected output of course).

 

Now tell me, how is an function more suitable for this task?

I am aware of what encapsulation is because I use object oriented concepts all the time, though not necessarily with objects.

 

What you've done is taken my summary and found an example that requires multiple steps. However, what if "parsing" was simply counting the number of times the letter "A" appears in a given string? This could easily and properly be put into one function.

 

Now sure, if we are talking about parsing JSON, that's another matter, as that calls for several different algorithms to make up the one collective algorithm. However, at some point you will find code that is best represented as a single algorithm.

 

For example, just recently I wrote a truncate function for strings. There was no need for me to put that in an object, so instead I put it in a common.php file that contains generic functions that have no need for objects. All of them are short algorithms, 10 lines max. Putting these into an object would be wasteful, and would not give me any benefit.

 

Working with Joomla (don't know if you have), several modules are so simple (such as grabbing a value from the database and echoing it) that they don't need objects. If I were to put that into an object, I would simply be instantiating it and calling it on the next line, which wouldn't help me at all. Of course you could say that I should abstract out the way the information is gathered and separate it from the output (model & view). However, I know this system will not change in such a way that the module would break and I know that the data will always be grabbed in this way.

[waynew]

Person = User = Object

[Daniel0]

If I were to put that into an object, I would simply be instantiating it and calling it on the next line, which wouldn't help me at all.

 

As I said earlier, just because you use objects then it doesn't mean it's OOP.

 

OOP is a different way of thinking than other paradigms so you can't just go step by step and make every page an object and every function within that a method of that object. It just doesn't work that way.

 

OOP is about how objects interact with each other whereas for instance procedural programming is about procedures and the state of the application.

[Eric_Ryk]

If I were to put that into an object, I would simply be instantiating it and calling it on the next line, which wouldn't help me at all.

 

As I said earlier, just because you use objects then it doesn't mean it's OOP.

 

OOP is a different way of thinking than other paradigms so you can't just go step by step and make every page an object and every function within that a method of that object. It just doesn't work that way.

 

OOP is about how objects interact with each other whereas for instance procedural programming is about procedures and the state of the application.

Right, and my point was that the two can go hand in hand. Not absolutely everything has to be an object. I realize it doesn't work that way, I never said it worked that way, I said that people try to make it work that way and implied that it fails horribly.