Interface design question
 

Hello,

Have a design related question and hope to hear some insights.

Interfaces using abstract classes impose restriction(s) on it's derived implementations.
- The most widely used restriction is to IMPLEMENT Function(s)

Question:
Is it permissible to have similar kind of restriction for any data members in the interface?
In a way that if some one wants to implement the interface it also must initialize certain variable.

Ex:

Say for a TCP/IP it absolutely necessary to have peer's IP address and Port number.
So, is wise to impose a restriction to pass above variable to initialize the class.

class IP4Connection
{
public:
explicit IP4Connection( string ip, uint port);
virtual int send() = 0;
virtual int listen() = 0;
virtual int reconnect() = 0;
protected:
std::string ip;
uint port;
};

Thanks,
Siva.

Re: Interface design question
 

bvssatish@gmail.com wrote:
> Hello,
>
> Have a design related question and hope to hear some insights.
>
> Interfaces using abstract classes impose restriction(s) on it's derived implementations.
> - The most widely used restriction is to IMPLEMENT Function(s)
>
> Question:
> Is it permissible to have similar kind of restriction for any data members in the interface?
> In a way that if some one wants to implement the interface it also must initialize certain variable.
>
> Ex:
>
> Say for a TCP/IP it absolutely necessary to have peer's IP address and Port number.
> So, is wise to impose a restriction to pass above variable to initialize the class.
I think, yes.
>
> class IP4Connection
> {
> public:
> explicit IP4Connection( string ip, uint port);
> virtual int send() = 0;
> virtual int listen() = 0;
> virtual int reconnect() = 0;
> protected:
> std::string ip;
> uint port;
> };
>
> Thanks,
> Siva.
>
I am not sure though why you need the abstract class and virtual methods for
this particular purpose; there is only one "concrete" TCP/IP connection (unless
you want derived classes for IPv4 and IPv6 but even then I would rather had it
as yet another state if I wanted to support both than introduce the hierarchy).

If you decide you do not need abstract class and virtual methods, I would also
make members private (and ended names with _ but it is a matter of style, I
guess :-) ).

-Pavel

Re: Interface design question
 

On Oct 11, 9:21*pm, bvssat...@gmail.com wrote:

> * * * Have a design related question and hope to hear some insights..
>
> * * * Interfaces using abstract classes impose restriction(s) on it's derived implementations.
> * * * * - The most widely used restriction is to IMPLEMENT Function(s)
>
> * * * Question:
> * * * * Is it permissible to have similar kind of *restriction for any data members in the interface?
> * * * * In a way that if some one wants to implement the interface it also must initialize certain variable.
>
> * * *Ex:
>
> * * * * Say for a TCP/IP it absolutely necessary to have peer's IP address and Port number.
> * * * * So, is wise to impose a restriction to pass above variable to initialize the class.
>
> * * * * class IP4Connection
> * * * * {
> * * * * * * * *public:
> * * * * * * * * * * explicit IP4Connection( string ip, uint port);
> * * * * * * * * * * virtual int send() = 0;
> * * * * * * * * * * virtual int listen() = 0;
> * * * * * * * * * * virtual int reconnect() = 0;
> * * * * * * * *protected:
> * * * * * * * * * * std::string ip;
> * * * * * * * * * * uint port;
> * * * * };


leaving aside the oddity of deriving from IP4Connection...

wouldn't any derived class constructor call the base class
constructor?

class LemonIPConnection: public IP4Connection
{
public:
LemonIPConnection (const strin& ip, uint port):
IP4Connection (ip, port)
{}
}

Re: Interface design question
 

i think that we don't design some data members in a abstract class.

Re: Interface design question
 

On Thursday, 11 October 2012 23:21:12 UTC+3, bvss...@gmail.com wrote:
> Interfaces using abstract classes impose restriction(s) on it's derived implementations.
>
> - The most widely used restriction is to IMPLEMENT Function(s)

Interface is not blueprint of a class, but blueprint of ability of class. It is
a way for object to communicate with other object. Interface declares the
inputs and outputs that are needed for such communication. That is wrong to
think of it as restriction.


> Question:
>
> Is it permissible to have similar kind of restriction for any data members in the interface?
> In a way that if some one wants to implement the interface it also must initialize certain variable.

Generally an interface should not have data members at all. It should be as
light as possible. It is bad to be intrusive. What if the implementer can reach the data from elsewhere without storing it locally?

> Ex:
>
> Say for a TCP/IP it absolutely necessary to have peer's IP address and Port number.
> So, is wise to impose a restriction to pass above variable to initialize the class.

Counter example: Why std::string? Are you certain that it is the best container to store IP address for all possible objects that implement the interface? What if the implementation wraps some operating system's socket resource that already contains the data? Your interface then enforces the data tobe present two times.

> class IP4Connection
> {
> public:
> explicit IP4Connection( string ip, uint port);

explicit is useless keyword here. Compilers should warn that you got worthless 'explicit' in code but for some reason they do not.

> virtual int send() = 0;
> virtual int listen() = 0;
> virtual int reconnect() = 0;
> protected:
> std::string ip;
> uint port;
> };
>
> Thanks,

NP, hope it helps.