php-general Digest 14 Jul 2012 20:53:23 -0000 Issue 7888
Topics (messages 318473 through 318476):
Re: extend or encapsulate?
318473 by: tamouse mailing lists
318474 by: Tony Marston
318475 by: Lester Caine
Seeking a scheduling algorithm
318476 by: Tedd Sperling
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On Sat, Jul 14, 2012 at 12:04 AM, Paul M Foster <pa...@quillandmouse.com> wrote:
> On Fri, Jul 13, 2012 at 12:06:22AM -0500, tamouse mailing lists wrote:
>
>> It's Friday, so...
>>
>> Yes, it's true, I have just started looking at using PDO instead of
>> mysqli -- a bit behind the times...
>>
>> My question at this stage, is do people tend to extend the PDO class
>> for their own use, or encapsulate it in a class (or do most people use
>> it mostly in procedural code?)
>
> I encapsulated it in my own database class. One reason for that is that
> the PDO "class" is really two classes, which is fine for low level
> drivers but not production code that I have to use daily. A second
> reason is that many of the methods are not really necessary in a
> production environment. I want to limit the methods my code uses to
> interact with the database. Third, I wanted to handle errors and
> exceptions with my own methods, more suitable to the code I write. For
> example, a fatal error should only, but always, be issued if the
> database code is given something illegal to chew on. Anything else, like
> a failure to return the expected result, should simply yield some sort
> of sentinal value or something. If *my code* ever gives the database
> library something illegal to chew on, then it should only be because of
> my bad code, not because a user managed to somehow get bad data through.
> That is, my code should always catch illegal data before it ever gets to
> the database library. Fourth, encapsulation means that I can have the
> class itself carry around some of the data that I would normally have to
> explicitly pass around among functions. This way, I make that useful
> data (like the number of records returned from the last fetch), part of
> the "payload" of the class itself.
>
> Extension is tricky and requires a more subtle and refined knowledge of
> the classes involved. Besides, it exposes methods which I would prefer
> not be used by my code. Encapsulation limits the methods of the classes
> to just what I deem necessary and no more. I can always write new
> methods if I need them.
>
> Paul
>
> --
> Paul M. Foster
> http://noferblatz.com
> http://quillandmouse.com
I am rather agreeing with both of you. Back in the days I used to poke
at Java, one of the caveats was to only inherit from abstract classes,
and encapsulate final classes. It does make more sense to me that way.
--- End Message ---
--- Begin Message ---
wrote in message
news:1535031289.371987.1342162338279.javamail.open-xcha...@email.1und1.de...
tamouse mailing lists <tamouse.li...@gmail.com> hat am 13. Juli 2012 um
07:06
geschrieben:
It's Friday, so...
Yes, it's true, I have just started looking at using PDO instead of
mysqli -- a bit behind the times...
My question at this stage, is do people tend to extend the PDO class
for their own use, or encapsulate it in a class (or do most people use
it mostly in procedural code?)
I stick to use it as components as it is said "Do not use inheritance for
code
re-use" :)
The idea that you shouldn't use inheritance for code reuse is absolute
nonsense as it makes a mockery of one of the fundamental principles of
object oriented programming. If you make a mess of inheritance it's because
your implementation is flawed, not that the concept is flawed. Next you'll
be saying "don't use encapsulation"or "don't use polymorphism". What a bunch
of idiots!
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
--- End Message ---
--- Begin Message ---
tamouse mailing lists wrote:
I am rather agreeing with both of you. Back in the days I used to poke
at Java, one of the caveats was to only inherit from abstract classes,
and encapsulate final classes. It does make more sense to me that way.
One option is to keep both drivers available ...
ADOdb will use either the generic or PDO which is useful when PDO does not
provide access to key database specific functions. I've been testing the PDO
driver on my own code simply by switching which one is loaded, but I still find
the generic driver for Firebird is faster - when wrapped in ADOdb.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
--- End Message ---
--- Begin Message ---
Hi gang:
Does anyone have a resource, or better yet code, to solve the scheduling
problem described below?
Let's say you have a week calendar that has openings between 8:00am to 5:00pm
for Monday through Friday (40 hours).
Then you have an assortment of appointments that must be scheduled into the
week calendar. Some of the appointments are simply a one hour per week, while
others may be two, three, four, or five times per week and each appointment for
an hour or more (up to eight hours).
The problem is, knowing what appointments (i.e., twice a week for 2 hours,
three times a week for one hour, etc.) must be scheduled for the week, what is
the most efficient way to schedule these appointments into that week?
The most efficient way is defined as scheduling appointments with little, or
no, gaps in between appointments. For example, four one-hour appointments on
Monday between 8:00am to 12:00pm is better than four one-hour appointments
spread out between 8:00am to 5:00pm.
Anyone have any solutions, ideas, resources, code?
Thanks,
tedd
_____________________
t...@sperling.com
http://sperling.com
--- End Message ---
