abstract class problem

[ankitjain.bvcoe]

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():_pStart(0),_pCur(0),_pCurBuffer(0){}
virtual void LogAlarm(char*)=0;
virtual void ReadLog()=0;
void LogBuffer_LogAlarm(char * pLogAlarm)
{
printf("\nIn Log Alarm \n");

memcpy((void*)(&_pCurBuffer[_pCur]),(void*)pLogAlarm,strlen(pLogAlarm));

_pCur+=strlen(pLogAlarm);

}

void LogBuffer_ReadLog()
{
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 *_pSingletonFireWallBuffer;
public:
FireWallBuffer()
{
printf("\nIn FIreWall Constructor\n");
for(int i=0;i<1000;i++)
_aFireWallBuf[i]=' ';

}

void LogAlarm(char*pAlarm)
{
_pCurBuffer=_aFireWallBuf;
LogBuffer_LogAlarm(pAlarm);
}
void ReadLog()
{
_pCurBuffer=_aFireWallBuf;
LogBuffer_ReadLog();

}

static FireWallBuffer * instance()
{
if(_pSingletonFireWallBuffer!=NULL)
return _pSingletonFireWallBuffer;
else
{
_pSingletonFireWallBuffer=new FireWallBuffer;
return _pSingletonFireWallBuffer ;
}
}
};
FireWallBuffer * FireWallBuffer::_pSingletonFireWallBuffer=NULL;

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

void LogAlarm(char*pAlarm)
{
_pCurBuffer=_aAlarmBuf;
LogBuffer_LogAlarm(pAlarm);
}

void ReadLog()
{
_pCurBuffer=_aAlarmBuf;
LogBuffer_ReadLog();
}
static AlarmBuffer * instance()
{
if(_pSingletonAlarmBuffer!=NULL)
return _pSingletonAlarmBuffer;
else
{
_pSingletonAlarmBuffer=new AlarmBuffer;
return _pSingletonAlarmBuffer ;
}
}

};

AlarmBuffer * AlarmBuffer::_pSingletonAlarmBuffer=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]

On 26 Feb 2006 20:13:36 -0800, "an*************@gmail.com"
<an*************@gmail.com> wrote:

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

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]

an*************@gmail.com wrote:

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

************************************************** **********************************
<snip code snippet> ************************************************** *******************************************
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

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]

an*************@gmail.com wrote:

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

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]

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]

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]

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]

an*************@gmail.com wrote:

Hi Ben,
thanks for your reply .
Hi.

Your quoting style is unorthodox.
************************************************** **********************
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 .
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::string&) = 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::string& str) {
str_ = str;
}
virtual std::string ReadLog() {
return str_;
}
private:
std::string str_;
};
}

class AlarmBuffer : public LogBuffer {
virtual void LogAlarm(std::string& str) {
impl_.LogAlarm(str);
}
virtual std::string ReadLog() {
return impl_.ReadLog();
}
private:
impl::LogBufferImpl 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> SingletonAlarmBuffer;

// Create
SingletonAlarmBuffer alarmBuffer;

int main()
{
// Use
LogBuffer* myLog = alarmBuffer.Instance();
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.
Can u tell me some links or some book which could increase my
designing strength.

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...