March 16th, 2013, 10:14 PM
Why protected if one can change the value? (protected property)
Please give me a simple example of a real life situation that the property HAS to be protected but accessed at the same time.
What comes to my mind in maybe doing some validation in getter then if successful showing the results of that property. I may be wrong.
Last edited by zxcvbnm; March 16th, 2013 at 10:20 PM.
March 17th, 2013, 12:14 AM
Making an attribute protected isn't about completely hiding it from the outside world. It's about managing access.
You can choose to make the attribute read-only, you can choose to accept only certain values (for example, a price usually isn't negative), you can calculate the value ad hoc rather than fetching it from some variable, you can restrict access to certain classes and many things more.
So it actually makes sense to use private or protected attributes and make them accessible through getters and setters. Of course it's no real improvement when you merely have a getter returning a variable and a setter assigning it. In this case you might as well use a public attribute. But for more advanced applications, in can be very helpful.
By the way, since you seem to be very interested in OOP, you might wanna look into other languages that have actually been designed to be object-oriented. Ruby, for example, has no "public attributes" at all. The whole public API of an object consists only of methods (which can access internal variables).
This leads to a very high-level approach: The inner workings of an object are hidden from the outside world. As an object user, you no longer have to distinguish between "this is an actual variable holding some value" and "this is a method fetching or calculating some value". It doesn't matter. And why should it? All you want is the value. Where exactly it comes from is an implementation detail.
Interestingly, Ruby still uses the classical attribute syntax, so you don't have the verbosity of explicit calls to getter and setter methods:
# the "constructor"
# set up a database connection and store it in the @connection variable
@connection = MySQL.connect ...
# generate getter method for @connection
db = Database.new
# this looks like an attribute, but it's actually a method call:
connection = db.connection # the same as db.connection()
March 17th, 2013, 04:29 AM
At the moment I am in the middle of REST web service, OOP (design patterns, never ends, as Northie mentioned, metal blockage, need a paradigm shift,,,) and html 5. JSON's next, Ruby seems to be the most "agreeable" by everyone.
Originally Posted by Jacques1
March 17th, 2013, 12:22 PM
I'm sure I've mentioned this before, but there is no right way to write or design code. There are plenty of wrong ways, but even every non-wrong way has disadvantages.
The people who get code written, working and out the door are not the people who follow every applicable design pattern they can. If you take a survey of the most popular PHP software I think you'd be surprised at how few actually use OOP and common design patterns. WordPress, PhpBB, Drupal, phpMyAdmin, SMF - they may use classes to some extent, but none of them have even slightly object oriented architectures.
I criticize those packages all the time, because for the most part they have truly terrible architectures from a theoretical standpoint (and also from some practical standpoints). However, I can't deny that (a) they have a lot of useful and complete features, (b) they have relatively few bugs, and (c) with some exceptions, they are not too difficult to extend and modify.
Most people don't care what your code looks like as long as it works well. That's why those packages are so successful. The only people who actually care about your code is other developers, and developers have never and will never be able to decide on what is the correct way to program something.
What you have to decide is whether or not the time required to come up with a "perfect" design is greater than or less than the time it will take you to refactor an imperfect design when an unanticipated need arises in the future. For example, if you have a UserY class that is only used twice in your entire application, it makes no sense at all to pour hours of design work into the class; refactoring two locations in code is trivial. Another example: I could spend 10 hours today designing a perfect class that will fulfill every conceivable future need of my application. Or I could spend 2 hours designing a class that fulfills that needs I have today, and another 5 hours down the road refactoring my application when I have to redesign the class to handle a new requirement. Ultimately, I've still spent 3 hours less if I don't try to design a perfect class in this case.
Basically, what it comes down to is that not every part of an application needs a factory factory factory. Don't beat yourself up over trying to find a perfect solution. If you need some inspiration, crack open the PhpBB code and remind yourself how successful that project has been even though your code is so much better.
Also looking at a different language to learn OOP is a good idea. One that you might want to consider is Java, considering it is impossible to even write code outside of classes in Java.