|
|
Posted by Tony Marston on 12/04/06 11:30
"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:dfadnZG_0a5vde_YnZ2dnUVZ_qSdnZ2d@comcast.com...
> Curtis wrote:
>>>That's just your opinion. Where does it say that I *MUST* define and use
>>>an
>>>interface before I can access a class method? Interfaces are optional
>>>(especuially in PHP) so it is not wrong to excercise the option NOT to
>>>use
>>>them. I can define a class method and access that method without using an
>>>interface, and that is what I choose to do.
>>
>>
>> No one is saying that you have to use interfaces. The point is that it
>> is there to help in organizing and creating classes, the same goes for
>> visibility keywords. Just because you don't have to use these, doesn't
>> mean that you should not use them.
>>
>> I can see an advantage in using interfaces and/or visibility keywords
>> in PHP, if one is creating a large library, or to help communications
>> between a team of developers. These features can help track down where
>> a problem is if something isn't working right, or just for clarifying
>> the particular usage for the class or its members.
>>
>> BTW, I do not believe there is any controversy over what encapsulation
>> is; if so, I haven't heard about it.
>>
>
> Hi, Curtis,
>
> Actually, there is. Tony is claiming that variables should not be private
> because they are not part of the implementation.
Wrong again. I did not say that they SHOULD NOT be private, I said that they
DO NOT HAVE TO be private. It is optonal, not mandatory.
> All of the industry-recognized experts, college level OOAD courses, etc.
> disagree with him. So do the people who designed Java.
>
> And even the PHP designers disagree with him - otherwise why would they
> have bothered adding private and protected to variables, for instance?
They added those features so that programmers have the option of using them.
Their usage is OPTIONAL, not MANDATORY.
> Data should be private because it hides how the data is being stored. A
> SQL database is a perfect example. You can't access the data directly,
> but you can do it through SQL. And even if the internal representation of
> the data changes (i.e. switch from MyISAM to InnoDB engines in MySQL, or
> upgrade MySQL), you can still access the data with no changes to the
> program. The data is encapsulated, but it is not hidden (it's all
> available).
Now it is you who is being stupid. The way in whch data is stored in the
database has nothing to do with making object variables public, protected or
private. In a well-written application all database access should be
performed in a separate data access object (DAO), thus making it possible to
switch from one database to another (e.g. fom MySQL to PostgreSQL) without
having any effect on the business object.
My argument is that it is not NECESSARY to make every class variable private
or protected. It is an OPTION, but one which does not provide any
additional functionality or increased performance. All it does is place
restrictions on the programmer.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
Navigation:
[Reply to this message]
|