Abstraction and Implementation

[Rajesh1978]

Hi,
I have the a doubt on how what is the benefit on separating the abstraction and implementation.

The below code

class FileProcessor
{
public:
virtual void processFile();
};

class DocProcessor : public FileProcessor
{
public:
void processFile();// Implementation is given it will implement to process the doc files
};

class ExcelProcessor : public FileProcessor
{
public:
void processFile();//Implements to process the excel files
};

Till now it is fine

suppose DocProcessor and ExcelProcessor uses two big algorithm to process these file types then

 I still can have subclasses like

class Algorithm1 : public DocProcessor
{
public:
void algorithm(); //which will be called as per the algorithm class instantiated for to process
};

class Algorithm2 : public DocProcessor
{
public:
void algorithm(); //which will be called as per the algorithm class instantiated for to process
};

same for ExcelProcessor class

Here everything looks fine to me. [ I have not used the bridge pattern to separate the abstraction and implementation]. The only thing i can achieve using bridge is that the number of classes will be reduced if new class like jpgProcessor is introduced or new algorithim is introduced.

Then why it is recommended that always separate the abstraction and implementation

please help
Regards

[D_Drmmr]

Here everything looks fine to me.

Not to me. Why would Algorithm1 be derived from DocProcessor? Why doesn't Algorithm1 simply take a poiner/reference to a FileProcessor (composition instead of inheritance)?

The only thing i can achieve using bridge is that the number of classes will be reduced if new class like jpgProcessor is introduced or new algorithim is introduced.

Then why it is recommended that always separate the abstraction and implementation

You mention a very good reason already. In your design you have (# processors * # algorithms) implementations, each of which needs to be written, tested, documented and maintained. By programming against an abstraction instead of an implementation, you have (#processors + #algorithms) implementations. If you have 4 of each, you already saved yourself half the work!

Have a look at the following articles:
http://www.objectmentor.com/resources/articles/ocp.pdf
http://www.objectmentor.com/resources/articles/lsp.pdf
http://www.objectmentor.com/resources/articles/dip.pdf

[Rajesh1978]

Thanks.
I agree.

i will now make two hierarchy one for FileProcessor and one for Algorithm.

File processor will use specialization of Algorithm base class.

now the number of classes will not increase in that rate what i have posted priviously.
Now it is exactly what the bridge patterns says.Abstraction and implementation is separated.

GOF says the client code will not change if we extend the implementation code in future.
This is how ?

both the abstractions and their implementations should be extensible by subclassing. In this case, the Bridge pattern lets you combine the different abstractions and implementations and extend them independently.
changes in the implementation of an abstraction should have no impact on clients; that is, their code should not have to be recompiled.
(C++) you want to hide the implementation of an abstraction completely from clients. In C++ the
representation of a class is visible in the class interface.

how we no need to recompile the client code

[GCDEF]

Maybe I'm not following, but why isn't Algorithm just a virtual member of the base class and overridden in the derived classes?

I agree with D_Drmmr, you're not using inheritance correctly here.

[Rajesh1978]

The whole point is that.
If we use virtual function as my first post the problems arise is pointed out by drmmr and also in bridge pattern.

My doubt is how the client code do not change as per GOF if we extend the application hierarchy?

[D_Drmmr]

My doubt is how the client code do not change as per GOF if we extend the application hierarchy?

Because the client should only depend on the abstraction. As long as that doesn't change, the client code does not have to be recompiled, regardless of how many implementations we add or change.