abstract class problem

[ankitjain.bvcoe@gmail.com]

Hi i have the following problem in my design ::::

i want to define an abstract class LogBuffer and derive two singleton
classes from it i.e
AlarmBuffer and FireWallBuffer. For this my design is such that i have
to define data members in class LogBuffer.i.e

*************** *************** *************** *************** *************** *********

class LogBuffer
{

private:
int _pStart;
int _pEnd;
int _pCur;
protected:
char * _pCurBuffer;
public:
LogBuffer():_pS tart(0),_pCur(0 ),_pCurBuffer(0 ){}
virtual void LogAlarm(char*) =0;
virtual void ReadLog()=0;
void LogBuffer_LogAl arm(char * pLogAlarm)
{
printf("\nIn Log Alarm \n");

memcpy((void*)( &_pCurBuffer[_pCur]),(void*)pLogAl arm,strlen(pLog Alarm));

_pCur+=strlen(p LogAlarm);

}

void LogBuffer_ReadL og()
{
printf("\nIn Read Alarm\n");
printf("\nThe logs are \n %s\ncur:%d",(&_ pCurBuffer[_pStart]),_pCur);
}

};


class FireWallBuffer: public LogBuffer
{
private:
char _aFireWallBuf[1000];
static FireWallBuffer *_pSingletonFir eWallBuffer;
public:
FireWallBuffer( )
{
printf("\nIn FIreWall Constructor\n") ;
for(int i=0;i<1000;i++)
_aFireWallBuf[i]=' ';

}

void LogAlarm(char*p Alarm)
{
_pCurBuffer=_aF ireWallBuf;
LogBuffer_LogAl arm(pAlarm);
}


void ReadLog()
{
_pCurBuffer=_aF ireWallBuf;
LogBuffer_ReadL og();

}

static FireWallBuffer * instance()
{
if(_pSingletonF ireWallBuffer!= NULL)
return _pSingletonFire WallBuffer;
else
{
_pSingletonFire WallBuffer=new FireWallBuffer;
return _pSingletonFire WallBuffer ;
}
}


};
FireWallBuffer * FireWallBuffer: :_pSingletonFir eWallBuffer=NUL L;

class AlarmBuffer:pub lic LogBuffer
{
private:
static AlarmBuffer *_pSingletonAla rmBuffer;
char _aAlarmBuf[1000];
public:
AlarmBuffer()
{
printf("\nIn Alarm Constructor\n") ;
for(int i=0;i<1000;i++)
_aAlarmBuf[i]=' ';
}

void LogAlarm(char*p Alarm)
{
_pCurBuffer=_aA larmBuf;
LogBuffer_LogAl arm(pAlarm);
}

void ReadLog()
{
_pCurBuffer=_aA larmBuf;
LogBuffer_ReadL og();
}
static AlarmBuffer * instance()
{
if(_pSingletonA larmBuffer!=NUL L)
return _pSingletonAlar mBuffer;
else
{
_pSingletonAlar mBuffer=new AlarmBuffer;
return _pSingletonAlar mBuffer ;
}
}

};

AlarmBuffer * AlarmBuffer::_p SingletonAlarmB uffer=NULL;

*************** *************** *************** *************** *************** *************** ***
The above piece of code is compiling but here is the design issue i am
concerned of.
An abstract class should only declare the interfaces which the child
classes define.
Is it ok to define data members in an abstract class and use them . I
mean is it a logical
mistake or fine.Because an abstract class cannot be instantiated .So
having data members
in it makes sense from c++ point of view or not ????

regards,
ankit jain

[Yellow Dog]

Re: abstract class problem

On 26 Feb 2006 20:13:36 -0800, "ankitjain.bvco e@gmail.com"
<ankitjain.bvco e@gmail.com> wrote:
[color=blue]
>Hi i have the following problem in my design ::::
>
>i want to define an abstract class LogBuffer and derive two singleton
>classes from it i.e
>AlarmBuffer and FireWallBuffer. For this my design is such that i have
>to define data members in class LogBuffer.i.e
>
> [code SNIPPED for Brevity]
>
>The above piece of code is compiling but here is the design issue i am
>concerned of.
>An abstract class should only declare the interfaces which the child
>classes define.
>Is it ok to define data members in an abstract class and use them . I
>mean is it a logical
>mistake or fine.Because an abstract class cannot be instantiated .So
>having data members
>in it makes sense from c++ point of view or not ????
>
>regards,
>ankit jain[/color]

I am not an expert, but an abstract class is simply a class where one
or more methods are defined as pure virtual functions. While these
functions must be instantiated by the derived classes, there is
nothing prohibiting the abstract class from having concrete functions
defined or having data members that are inherited by the derived
classes. You just can't call them until the until the base class is
instantiated by a derived class.

The derived class inherits the concrete functions and the data members
and uses them as if they were it's own. The derived class also
supplies the missing virtual elements of the base class to create a
functioning object.

If it ain't broke....fix it anyway!

[Jaspreet]

Re: abstract class problem


ankitjain.bvcoe @gmail.com wrote:[color=blue]
> Hi i have the following problem in my design ::::
>
> i want to define an abstract class LogBuffer and derive two singleton
> classes from it i.e
> AlarmBuffer and FireWallBuffer. For this my design is such that i have
> to define data members in class LogBuffer.i.e
>
> *************** *************** *************** *************** *************** *********
>[/color]
<snip code snippet>[color=blue]
> *************** *************** *************** *************** *************** *************** ***
> The above piece of code is compiling but here is the design issue i am
> concerned of.
> An abstract class should only declare the interfaces which the child
> classes define.
> Is it ok to define data members in an abstract class and use them . I
> mean is it a logical
> mistake or fine.Because an abstract class cannot be instantiated .So
> having data members
> in it makes sense from c++ point of view or not ????
>
> regards,
> ankit jain[/color]

If all your derived classes would be using some common data, then I
guess we could put it in the abstract base class to avoid duplication
and have a single store-house for those data members. However, let the
experts confirm whether it is a good practice or not.

[Ben Pope]

Re: abstract class problem

ankitjain.bvcoe @gmail.com wrote:[color=blue]
> Hi i have the following problem in my design ::::
>
> i want to define an abstract class LogBuffer and derive two singleton
> classes from it i.e
> AlarmBuffer and FireWallBuffer. For this my design is such that i have
> to define data members in class LogBuffer.i.e[/color]

It looks to me like you want to define an interface, and then have two
classes that implement that interface. In your particular situation
they should be a singleton.

What I would do is create LogBuffer as a "pure abstract class", one
without any data members, and which describes only the interface.

Then, I would create the two base classes AlarmBuffer and
FireWallBuffer, not as singletons. If there was significant overlap in
implementation between the two, then I would consider factoring the
overlap into an implementation class, LogBufferImpl. AlarmBuffer and
FireWallBuffer can then have a LogBufferImpl data member.

You could also use LogBufferImpl as a public base, in which case the
constructor and destructor should probably be protected so that it
cannot be instantiated.

After that, I would wrap them with a singleton class. This can be a
generic solution, templated on type (AlarmBuffer or FireWallBuffer, in
this case).

Be sure to use base classes for polymorphic behaviour, not
implementation details. As a rule of thumb, public inheritance is for
flexibility, data members are for code re-use.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[ankitjain.bvcoe@gmail.com]

Re: abstract class problem

Hi Ben,
thanks for your reply .


*************** *************** *************** *************** ************
Then, I would create the two base classes AlarmBuffer and
FireWallBuffer, not as singletons. If there was significant overlap in

implementation between the two, then I would consider factoring the
overlap into an implementation class, LogBufferImpl. AlarmBuffer and
FireWallBuffer can then have a LogBufferImpl data member.


You could also use LogBufferImpl as a public base, in which case the
constructor and destructor should probably be protected so that it
cannot be instantiated.


After that, I would wrap them with a singleton class. This can be a
generic solution, templated on type (AlarmBuffer or FireWallBuffer, in
this case).

*************** *************** *************** *************** **********

Ben, I can't understand the design proposed by u.Another implementation
LogBufferImpl ???
Can u explain it a bit more .
Also ,i think the most important thing in C++ is how u design your
problem .
Can u tell me some links or some book which could increase my
designing strength.

regards,
ankit jain

[ankitjain.bvcoe@gmail.com]

Re: abstract class problem

Hi Ben,
thanks for your reply .


*************** *************** *************** *************** ************
Then, I would create the two base classes AlarmBuffer and
FireWallBuffer, not as singletons. If there was significant overlap in

implementation between the two, then I would consider factoring the
overlap into an implementation class, LogBufferImpl. AlarmBuffer and
FireWallBuffer can then have a LogBufferImpl data member.


You could also use LogBufferImpl as a public base, in which case the
constructor and destructor should probably be protected so that it
cannot be instantiated.


After that, I would wrap them with a singleton class. This can be a
generic solution, templated on type (AlarmBuffer or FireWallBuffer, in
this case).

*************** *************** *************** *************** **********

Ben, I can't understand the design proposed by u.Another implementation
LogBufferImpl ???
Can u explain it a bit more .
Also ,i think the most important thing in C++ is how u design your
problem .
Can u tell me some links or some book which could increase my
designing strength.

regards,
ankit jain

[ankitjain.bvcoe@gmail.com]

Re: abstract class problem

Hi Ben,
thanks for your reply .


*************** *************** *************** *************** ************
Then, I would create the two base classes AlarmBuffer and
FireWallBuffer, not as singletons. If there was significant overlap in

implementation between the two, then I would consider factoring the
overlap into an implementation class, LogBufferImpl. AlarmBuffer and
FireWallBuffer can then have a LogBufferImpl data member.


You could also use LogBufferImpl as a public base, in which case the
constructor and destructor should probably be protected so that it
cannot be instantiated.


After that, I would wrap them with a singleton class. This can be a
generic solution, templated on type (AlarmBuffer or FireWallBuffer, in
this case).

*************** *************** *************** *************** **********

Ben, I can't understand the design proposed by u.Another implementation
LogBufferImpl ???
Can u explain it a bit more .
Also ,i think the most important thing in C++ is how u design your
problem .
Can u tell me some links or some book which could increase my
designing strength.

regards,
ankit jain

[Ben Pope]

Re: abstract class problem

ankitjain.bvcoe @gmail.com wrote:[color=blue]
> Hi Ben,
> thanks for your reply .[/color]

Hi.

Your quoting style is unorthodox.
[color=blue]
> *************** *************** *************** *************** ************
> Then, I would create the two base classes AlarmBuffer and
> FireWallBuffer, not as singletons. If there was significant overlap in
>
> implementation between the two, then I would consider factoring the
> overlap into an implementation class, LogBufferImpl. AlarmBuffer and
> FireWallBuffer can then have a LogBufferImpl data member.
>
>
> You could also use LogBufferImpl as a public base, in which case the
> constructor and destructor should probably be protected so that it
> cannot be instantiated.
>
>
> After that, I would wrap them with a singleton class. This can be a
> generic solution, templated on type (AlarmBuffer or FireWallBuffer, in
> this case).
>
> *************** *************** *************** *************** **********
>
> Ben, I can't understand the design proposed by u.Another implementation
> LogBufferImpl ???
> Can u explain it a bit more .[/color]

Where you had implementation details in the abstract class, you move
them into an implementation class. This is things that are common to
many implementation of the interface, but not strictly required.

I'm thinking something like this:


#include <string>
#include <iostream>

// Pure Abstract Class, Interface Only.
class LogBuffer {
public:
LogBuffer() {}
virtual void LogAlarm(std::s tring&) = 0 {}
virtual std::string ReadLog() = 0 {}
virtual ~LogBuffer() {}
private: // noncopyable
LogBuffer(const LogBuffer&);
LogBuffer& operator=(const LogBuffer&);
};

// Implementation details in here
namespace impl {
// Create this only if there is significant overlap
class LogBufferImpl : public LogBuffer {
public:
virtual void LogAlarm(std::s tring& str) {
str_ = str;
}
virtual std::string ReadLog() {
return str_;
}
private:
std::string str_;
};
}

class AlarmBuffer : public LogBuffer {
virtual void LogAlarm(std::s tring& str) {
impl_.LogAlarm( str);
}
virtual std::string ReadLog() {
return impl_.ReadLog() ;
}
private:
impl::LogBuffer Impl impl_;
};

// similarly to above for FireWall


// Generic SingletonHolder
template<class T>
class SingletonHolder {
public:
SingletonHolder () : t_(0) {}
T* Instance() {
if (!t_) {
t_ = new T;
}
return t_;
}
private:
T* t_;
};

// Define AlarmBuffer Singleton
typedef SingletonHolder <AlarmBuffer> SingletonAlarmB uffer;

// Create
SingletonAlarmB uffer alarmBuffer;

int main()
{
// Use
LogBuffer* myLog = alarmBuffer.Ins tance();
myLog->LogAlarm(std:: string("Foo"));
std::cout << myLog->ReadLog() << std::endl;
return 0;
}


The code compiles, and appears to work, but is untested. It may not be
the best singleton in the world, I usually use the one in Loki.
[color=blue]
> Can u tell me some links or some book which could increase my
> designing strength.[/color]

Talking of Loki, "Modern C++ Design" by Andrei Alexandrescu gives some
very powerful insights into the use of templates.

"Design Patterns" by Gamma et. al. (Also known as the "Gang of Four" or
"GoF" book)

They're ones I have, that I can recommend.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...