extending class but base call needs to call extended class

I have a large class that I'm breaking up into smaller chunks.

So I have a base class and a new class which extends the base class.

My problem is, Can I call the extended class from the base class? This just doesn't seem right.

// a.php
class A {
    // set all the properties and runs some validation and functionality in the process
}

// b.php
class B extends A {
    // needs all the same validation as class A and adds more functionality
}

To start the process I can only call class A, Example:

$process = new A();

in the class A I need to decide if class B functionality is needed

class A {
    if($condition) {
        include_once('b.php');
        $new_process = new B();
        $new_process->doMoreStuff();
    }
}

I could add the doMoreStuff() (well a ton more functionality) but this defeats the purpose of having the smaller class file sizes.

I know the right way would be to create a wrapper script and put the logic in there, if to use class A or B. But is there any other reason why I couldn't do as I've requested?

UPDATE:

So let me clarify what class A is:

Class A sets up all the database connections, validation of the INI properties, and sets the initial logging values. Class A also开发者_如何学C has a workflow/process for handling a specific request.

Class B needs class A's database, INI properties and logging but also offers a new workflow/process. I just wanted to extend the functionality of A into another class (as to make it more manageable).

So I'm thinking there should be a decision class C that decides to use Class A only or Class B which extends Class A.

Just wanted to confirm that this would be the best bet, thanks for the input

sounds like maybe you should be using a factory pattern, although hard to tell without more info. some sort of oop pattern is applicable here though. check this out.

http://www.php.net/manual/en/language.oop5.patterns.php

EDIT

Your idea is a step in the right direction, but it seems your application violates the single responsibility principle (SRP). Class A has several responsibilities, and therfore many reasons that it may change. You may want to instead have one class that initializes, one class that handles the DB connection, and one class that handles logging. This will make your application much easier to modify in the future. You would then pass these classes into whatever other classes need them using dependency injection (basically through construct or method arguments), or simply use them in the wrapper class when needed.

If class B only shows up as part of class A then you should make it at least obvious that it cannot be used outside of the class. Set some variable or something before you include b.php and error out if it's not set inside of b, so that if somebody else includes it, the variable will not be set, and it will be obvious that the class is not meant to be used outside of class A.

And is B really a subclass of A if you're creating a separate instance of it? your new object initialized as an A will act like a B during construction, but if some method requires a B object, you can't pass in the object you initialized as an A, whereas if you used a wrapper class, and it actually returned a B, it would work correctly for places that expect a B. It depends on how complex your situation is, if this may come up or not.

factory pattern is definitely one way to go here, but another thing to keep in mind is the difference between "is a" and "has a".

the way that you have everything working right now, using inheritance, is an "is a" kind of relationship b is an a.

the has a relationship woould make b its own class, with a property of the type of a. that way you could initialize b with an a class object, and make use of all data and validation in a, without the two classes having any inheritance based relationship.

not the best explanation of the differences... the important question though is whether or not those properties/methods from a actually belong as properties or methods on b.