Passing $_POST to Object

[TomTees]

How would it get hacked?

From what was described before, you could call the __Constructor repeatedly even if you hadn't instantiated yet.  (Maybe I misunderstood?!)

 

Yeah, I think you misunderstood.  Calling the constructor IS instantiating an object.  Whenever the word 'new' is written an object is being instantiated.

 

Now, you don't need to DEFINE a constructor.  If you don't define one, PHP will simply invoke the default constructor, which doesn't do anything but tell PHP "Hey, this is an object."

 

Someone earlier said you could make it "private" but I guess that isn't so.

 

You CAN make a constructor private.  This is used when you want to deny public/multiple instantiation.  It's a critical part of the Singleton pattern and other static classes (Factories).

 

Now that makes more sense!! 

 

I understand what you said above and that seems more consistent with my concerns.

 

So "private" for my constructors it is!

 

Thanks,

 

 

TomTees

 

 

 

[KevinM1]

So "private" for my constructors it is!

 

You're not planning on making all your classes static or Singletons, are you?

[TomTees]

So "private" for my constructors it is!

 

You're not planning on making all your classes static or Singletons, are you?

 

Nope.  Not at all.  But based on what you said, it sounds like I can make all constructors "private"...

 

 

TomTees

 

[KevinM1]

So "private" for my constructors it is!

 

You're not planning on making all your classes static or Singletons, are you?

 

Nope.  Not at all.  But based on what you said, it sounds like I can make all constructors "private"...

 

 

TomTees

 

 

Not in the way you're thinking.  You can't make them private and expect normal behavior, which is why I specifically mentioned Singletons and static classes.  Singletons use a static method to return an instance of itself.  There can only be one instance of a particular Singleton in existence EVER.  Singletons are also global in nature because they use a static method for creation/assignment.  Best to stay away from them.

 

Generic static classes shouldn't be instantiated at all.  Instead, data is passed into a static method and a result comes back, often an object.

 

I'd say the vast majority of classes you'll write will have public constructors.  That's okay.  Encapsulation is good, but there still needs to be a way to turn on an object and initialize it somewhere in the system.

 

You should do yourself a favor and buy the Gang of Four's book.  It will address all these fundamental questions and provide relevant examples.

[TomTees]

Not in the way you're thinking.  You can't make them private and expect normal behavior, which is why I specifically mentioned Singletons and static classes.  Singletons use a static method to return an instance of itself.  There can only be one instance of a particular Singleton in existence EVER.  Singletons are also global in nature because they use a static method for creation/assignment.  Best to stay away from them.

 

Generic static classes shouldn't be instantiated at all.  Instead, data is passed into a static method and a result comes back, often an object.

 

I'd say the vast majority of classes you'll write will have public constructors.  That's okay.  Encapsulation is good, but there still needs to be a way to turn on an object and initialize it somewhere in the system.

 

So if I have this class...

 

class FormHandler4 {
	private $myFormArray = array();

	private function __construct($input = false){
		if(is_array($input)){
			$this->myFormArray = $input;
		}
	}
}

 

 

And I instantiate it using this...

 

$objFormHandler4 = new FormHandler4($_POST);

 

You are saying it won't work (i.e. instantiate a new object)??

 

 

You should do yourself a favor and buy the Gang of Four's book.  It will address all these fundamental questions and provide relevant examples.

 

It is on my "To-Do List", but I'm not far enough long with OOP to understand what a book of that magnitude probably says...  (I hear it is s-c-a-r-y?!) 

 

 

TomTees

 

 

[TomTees]

Fatal error: Call to private FormHandler4::__construct() from invalid context in /Users/user1/Documents/DEV/++htdocs/Test2/results.php on line 6

 

Yep!  You were right about using "private" for my constructor!! 

 

 

TomTees

 

[trq]

I said several posts ago that if you make your __construct private you will not be able to instantiate the class into an object.

[KevinM1]

So if I have this class...

 

class FormHandler4 {
	private $myFormArray = array();

	private function __construct($input = false){
		if(is_array($input)){
			$this->myFormArray = $input;
		}
	}
}

 

 

And I instantiate it using this...

 

$objFormHandler4 = new FormHandler4($_POST);

 

You are saying it won't work (i.e. instantiate a new object)??

 

As you found out, that's exactly what I'm saying.  Also, again, don't be paranoid about having things public.  How else can objects talk to one another, let alone be instantiated?  Of course fields should be either private or protected, but most of the methods you'll write will be public.  A constructor is simply a method.

 

And, yes, accessors do have their place as well.  Hell, C#, a language that's much more object oriented than PHP, has a property mechanism just for that reason.  A lot of objects need to know about other objects' current state in order to work.  Look at just about any object that represents a database record.  How are you going to get at its data without an accessor?

 

You linked to an article about how accessors are bad, but did you ever bother to read the comments?  They're pretty enlightening: http://www.javaworld.com/community/?q=node/1759#comment-32951

 

It is on my "To-Do List", but I'm not far enough long with OOP to understand what a book of that magnitude probably says...  (I hear it is s-c-a-r-y?!) 

 

It's not scary.  It's written very plainly.  The biggest hurdle is that the examples are written in C++ and Smalltalk.  Their syntax is similar enough to PHP's to make it a non-issue.

[TomTees]

I said several posts ago that if you make your __construct private you will not be able to instantiate the class into an object.

 

 

And someone before you said it *would* work!

 

What's a newb to do?!

 

So I tried it out and looks like you were right and the other person was wrong!

 

 

 

TomTees

 

 

[TomTees]

As you found out, that's exactly what I'm saying.  Also, again, don't be paranoid about having things public.  How else can objects talk to one another, let alone be instantiated?  Of course fields should be either private or protected, but most of the methods you'll write will be public.  A constructor is simply a method.

 

Okay.

 

 

 

And, yes, accessors do have their place as well.  Hell, C#, a language that's much more object oriented than PHP, has a property mechanism just for that reason.  A lot of objects need to know about other objects' current state in order to work.  Look at just about any object that represents a database record.  How are you going to get at its data without an accessor?

 

You linked to an article about how accessors are bad, but did you ever bother to read the comments?  They're pretty enlightening: http://www.javaworld.com/community/?q=node/1759#comment-32951

 

I may have read a few, but I'll go back and re-read all of them

 

 

**SIDE NOTE:  See, this is what is soooo frustrating about trying to learn OOP.  "I" know very little.  And a lot of "experts" don't know a whole lot more!!    So who am I to believe?!    There is so much misinformation out there on the Internet that it is mind-boggling, and a person really has to be careful to not just trust the masses, lest they become part of the (uneducated) masses.  In the final analysis, I just try to ask enough supposed "experts" to get a decent feel for what approaches and theories seem to make sense, but Getters/Setters is a prime example of not knowing who to believe...

 

 

 

It is on my "To-Do List", but I'm not far enough long with OOP to understand what a book of that magnitude probably says...  (I hear it is s-c-a-r-y?!) 

 

It's not scary.  It's written very plainly.  The biggest hurdle is that the examples are written in C++ and Smalltalk.  Their syntax is similar enough to PHP's to make it a non-issue.

 

 

Okay.

 

 

TomTees

 

[KevinM1]

**SIDE NOTE:  See, this is what is soooo frustrating about trying to learn OOP.  "I" know very little.  And a lot of "experts" don't know a whole lot more!!    So who am I to believe?!    There is so much misinformation out there on the Internet that it is mind-boggling, and a person really has to be careful to not just trust the masses, lest they become part of the (uneducated) masses.  In the final analysis, I just try to ask enough supposed "experts" to get a decent feel for what approaches and theories seem to make sense, but Getters/Setters is a prime example of not knowing who to believe...

 

Well, there's really no set answer to these kinds of questions because it depends on the context of your current situation.  OOP is filled with "Don't do X, unless Y" kinds of situations.  Accessors fall into that group.  Not all objects need accessors.  But some (data objects) rely on them to be useful.  The key is to figure out who needs access to what in order to work.

 

Here's another one for you: PHP lacks a struct-like data structure.  In order to fudge it, a lot of developers create small, simple objects with public fields.  Not a good habit to get into in a general sense, but not entirely horrible if you're only dealing with POD (plain old data).  For example, Kohana's ORM does this because model objects are a 1-1 map of a db table row, so it streamlines assignment.  The only meaningful activity connected to the object is saving its data back to the db.

 

But, yeah, I hear you.  It can be maddening in the beginning because a lot of it boils down to context or opinion.