473,245 Members | 1,575 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,245 software developers and data experts.

C++ OO design question

In a recent job interview, the interviewer asked me how I'd design
classes for the following problem: let's consider a hypothetical
firewall, which filters network packets by either IP address, port
number, or both. How should we design the classes to represent these
filters?

My answer was:

class FilterRule
{
public:
virtual bool Accept(const Packet&) const = 0; //Packet is a
representation of a network packet
};
class FilterByIP: public FilterRule { /* members here */ };
class FilterByPort: public FilterRule { /* members here */ };

class Filter
{
public:
bool Accept(const Packet&) const; //returns true if ALL
filterRules Accept() the Packet
private:
std::vector<FilterRulefilterRules;
};
However, the interviewer said that he preferred this solution instead:

class Filter
{
public:
virtual bool Accept(const Packet&) const = 0;
};
class FilterByIP: public Filter { /* members here */ }
class FilterByPort: public Filter { /* members here */ }
class FilterByIPAndPort: public Filter
{
protected:
FilterByIP ipFilter;
FilterByPort portFilter;
/* other members */
};

I reasoned that with his solution, there may be too many class numbers
if down the road we decide to filter packets by methods other than IP
address and Port, but somehow he was not convinced. Oh well, I didn't
get the job, but this question continues to haunt me to this day. What
do you C++ experts think? Or is there another better solution that I
did not consider? Thank you.

Sep 17 '07 #1
8 2191
in*************@gmail.com wrote:
In a recent job interview, the interviewer asked me how I'd design
classes for the following problem: let's consider a hypothetical
firewall, which filters network packets by either IP address, port
number, or both. How should we design the classes to represent these
filters?

My answer was:

class FilterRule
{
public:
virtual bool Accept(const Packet&) const = 0; //Packet is a
representation of a network packet
};
class FilterByIP: public FilterRule { /* members here */ };
class FilterByPort: public FilterRule { /* members here */ };

class Filter
{
public:
bool Accept(const Packet&) const; //returns true if ALL
filterRules Accept() the Packet
private:
std::vector<FilterRulefilterRules;
};
You mean

std::vector< some_smart_pointer<FilterRule filterRules;
>
However, the interviewer said that he preferred this solution instead:

class Filter
{
public:
virtual bool Accept(const Packet&) const = 0;
};
class FilterByIP: public Filter { /* members here */ }
class FilterByPort: public Filter { /* members here */ }
class FilterByIPAndPort: public Filter
{
protected:
FilterByIP ipFilter;
FilterByPort portFilter;
/* other members */
};

I reasoned that with his solution, there may be too many class numbers
if down the road we decide to filter packets by methods other than IP
address and Port, but somehow he was not convinced. Oh well, I didn't
get the job, but this question continues to haunt me to this day. What
do you C++ experts think? Or is there another better solution that I
did not consider? Thank you.
I like your idea of representing a filter just as a vector of filter rules.
If you want to actually reduce that to practice, you could use duck typing
instead of inheritance. E.g.:

typedef bool (sig) (Paket const &)
typedef std::tr1::function<sigFilterRule;

Now, FilterRule can hold any value that supports

bool operator() ( Paket const & )

In particular, the concrete classes could be:

class IpFilterRule {
...
public:

bool operator() ( Paket const & p ) {
}

};

class PortFilterRule {
...
public:

bool operator() ( Paket const & p ) {
}

};

and a Filter can now easily be represented as a std::vector< FilterRule >.

Note that there is no coupling between the classes. Should there be common
code, one can incorporate that into the classes using private inheritance.
It would be considered an implementation detail.

Also, the client code would use objects of type FilterRule (or IpFilterrule,
etc) instead of FilterRule* (or IpFilterRule*, etc).
Best

Kai-Uwe Bux
Sep 17 '07 #2
On 2007-09-17 09:24, in*************@gmail.com wrote:
In a recent job interview, the interviewer asked me how I'd design
classes for the following problem: let's consider a hypothetical
firewall, which filters network packets by either IP address, port
number, or both. How should we design the classes to represent these
filters?
This is really a question for a group discussing object-oriented design
so you should ask in comp.object or perhaps comp.programming.
My answer was:

class FilterRule
{
public:
virtual bool Accept(const Packet&) const = 0; //Packet is a
representation of a network packet
};
class FilterByIP: public FilterRule { /* members here */ };
class FilterByPort: public FilterRule { /* members here */ };

class Filter
{
public:
bool Accept(const Packet&) const; //returns true if ALL
filterRules Accept() the Packet
private:
std::vector<FilterRulefilterRules;
Slicing, you cannot store derived types in a vector parametrised by the
base type, you have to use pointers instead:

std::vector<FilterRulefilterRules;
};
However, the interviewer said that he preferred this solution instead:

class Filter
{
public:
virtual bool Accept(const Packet&) const = 0;
};
class FilterByIP: public Filter { /* members here */ }
class FilterByPort: public Filter { /* members here */ }
class FilterByIPAndPort: public Filter

I assume you forgot
class Filter
{
protected:
FilterByIP ipFilter;
FilterByPort portFilter;
/* other members */
};
This assumes that you can filter multiple IP addresses or ports with a
single FilterByIP object, which might allow some optimisations that are
not possible when you have more than one FilterByIP object (which your
solution allows). However it is also less flexible for the same reasons.
I reasoned that with his solution, there may be too many class numbers
if down the road we decide to filter packets by methods other than IP
address and Port, but somehow he was not convinced. Oh well, I didn't
get the job, but this question continues to haunt me to this day. What
do you C++ experts think? Or is there another better solution that I
did not consider? Thank you.
Yes, I also prefer your design, it is more flexible and more easily
extended, however I've never thought much about firewall design and
there might be some other reasons to use his design.

--
Erik Wikström
Sep 17 '07 #3
Erik Wikström a écrit :
On 2007-09-17 09:24, in*************@gmail.com wrote:
>In a recent job interview, the interviewer asked me how I'd design
classes for the following problem: let's consider a hypothetical
firewall, which filters network packets by either IP address, port
number, or both. How should we design the classes to represent these
filters?

This is really a question for a group discussing object-oriented design
so you should ask in comp.object or perhaps comp.programming.
>My answer was:
class FilterByIP: public FilterRule { /* members here */ };
class FilterByPort: public FilterRule { /* members here */ };
[snip] He prefered
class FilterByIP: public Filter { /* members here */ }
class FilterByPort: public Filter { /* members here */ }
class FilterByIPAndPort: public Filter
Yes, I also prefer your design, it is more flexible and more easily
extended, however I've never thought much about firewall design and
there might be some other reasons to use his design.
IMO in "either IP address, port number, or both.", the "both" means
ports related to specific IP addresses and not merely applying the rules
independantely; this makes sense with the interviewer's design and with
the field.

Michael
Sep 17 '07 #4
On 2007-09-17 11:24, Michael DOUBEZ wrote:
Erik Wikström a écrit :
>On 2007-09-17 09:24, in*************@gmail.com wrote:
>>In a recent job interview, the interviewer asked me how I'd design
classes for the following problem: let's consider a hypothetical
firewall, which filters network packets by either IP address, port
number, or both. How should we design the classes to represent these
filters?

This is really a question for a group discussing object-oriented design
so you should ask in comp.object or perhaps comp.programming.
>>My answer was:
class FilterByIP: public FilterRule { /* members here */ };
class FilterByPort: public FilterRule { /* members here */ };
[snip] He prefered
class FilterByIP: public Filter { /* members here */ }
class FilterByPort: public Filter { /* members here */ }
class FilterByIPAndPort: public Filter
>Yes, I also prefer your design, it is more flexible and more easily
extended, however I've never thought much about firewall design and
there might be some other reasons to use his design.

IMO in "either IP address, port number, or both.", the "both" means
ports related to specific IP addresses and not merely applying the rules
independantely; this makes sense with the interviewer's design and with
the field.
That can easily be solved with the OP's design by adding a class like
FilterByIPAndPort, and to be honest I thought that was just an omission
of the OP (just like leaving out a FilterByIPAndPort member in the
interviewer's design. I thought the issue was the question if a
container should be used or members like in the interviewer's design.

--
Erik Wikström
Sep 17 '07 #5
in*************@gmail.com wrote:
In a recent job interview, the interviewer asked me how I'd design
classes for the following problem: let's consider a hypothetical
firewall, which filters network packets by either IP address, port
number, or both. How should we design the classes to represent these
filters?

My answer was:

class FilterRule
{
public:
virtual bool Accept(const Packet&) const = 0; //Packet is a
representation of a network packet
};
class FilterByIP: public FilterRule { /* members here */ };
class FilterByPort: public FilterRule { /* members here */ };

class Filter
{
public:
bool Accept(const Packet&) const; //returns true if ALL
filterRules Accept() the Packet
private:
std::vector<FilterRulefilterRules;
};
However, the interviewer said that he preferred this solution instead:

class Filter
{
public:
virtual bool Accept(const Packet&) const = 0;
};
class FilterByIP: public Filter { /* members here */ }
class FilterByPort: public Filter { /* members here */ }
class FilterByIPAndPort: public Filter
{
protected:
FilterByIP ipFilter;
FilterByPort portFilter;
/* other members */
};

I reasoned that with his solution, there may be too many class numbers
if down the road we decide to filter packets by methods other than IP
address and Port, but somehow he was not convinced. Oh well, I didn't
get the job, but this question continues to haunt me to this day. What
do you C++ experts think? Or is there another better solution that I
did not consider? Thank you.
I think the first design, (while the second didn't give any detail)
overlook the one important thing,
The IP/PORT resources should be shared, not owned, we can't have every
instance of XXFilter to own one copy,

std::vector<some_smart_pointer<... as Kai-uwe mentioned else thread
still don't fullfill this purpose

should be
some_smart_ptr<std::vector<...
--
Thanks
Barry
Sep 17 '07 #6
Kai-Uwe Bux wrote:
in*************@gmail.com wrote:
>In a recent job interview, the interviewer asked me how I'd design
classes for the following problem: let's consider a hypothetical
firewall, which filters network packets by either IP address, port
number, or both. How should we design the classes to represent these
filters?

My answer was:

class FilterRule
{
public:
virtual bool Accept(const Packet&) const = 0; //Packet is a
representation of a network packet
};
class FilterByIP: public FilterRule { /* members here */ };
class FilterByPort: public FilterRule { /* members here */ };

class Filter
{
public:
bool Accept(const Packet&) const; //returns true if ALL
filterRules Accept() the Packet
private:
std::vector<FilterRulefilterRules;
};

You mean

std::vector< some_smart_pointer<FilterRule filterRules;
>>
However, the interviewer said that he preferred this solution instead:

class Filter
{
public:
virtual bool Accept(const Packet&) const = 0;
};
class FilterByIP: public Filter { /* members here */ }
class FilterByPort: public Filter { /* members here */ }
class FilterByIPAndPort: public Filter
{
protected:
FilterByIP ipFilter;
FilterByPort portFilter;
/* other members */
};

I reasoned that with his solution, there may be too many class numbers
if down the road we decide to filter packets by methods other than IP
address and Port, but somehow he was not convinced. Oh well, I didn't
get the job, but this question continues to haunt me to this day. What
do you C++ experts think? Or is there another better solution that I
did not consider? Thank you.

I like your idea of representing a filter just as a vector of filter
rules. If you want to actually reduce that to practice, you could use duck
typing instead of inheritance. E.g.:

typedef bool (sig) (Paket const &)
typedef std::tr1::function<sigFilterRule;

Now, FilterRule can hold any value that supports

bool operator() ( Paket const & )

In particular, the concrete classes could be:

class IpFilterRule {
...
public:

bool operator() ( Paket const & p ) {
}

};

class PortFilterRule {
...
public:

bool operator() ( Paket const & p ) {
}

};

and a Filter can now easily be represented as a std::vector< FilterRule >.

Note that there is no coupling between the classes. Should there be common
code, one can incorporate that into the classes using private inheritance.
It would be considered an implementation detail.

Also, the client code would use objects of type FilterRule (or
IpFilterrule, etc) instead of FilterRule* (or IpFilterRule*, etc).
I just realized that one can go even further with this idea:
#include <tr1/functional>
#include <vector>
#include <iostream>

typedef unsigned int Paket;

// machinery for predicates
// ========================

typedef bool(sig)(Paket const &);
typedef std::tr1::function<sigPaketPredicate;

class AndPredicate {

PaketPredicate the_lhs;
PaketPredicate the_rhs;

AndPredicate ( PaketPredicate const & lhs,
PaketPredicate const & rhs )
: the_lhs ( lhs )
, the_rhs ( rhs )
{}

public:

friend
AndPredicate operator&& ( PaketPredicate const & lhs,
PaketPredicate const & rhs );

bool operator() ( Paket const & p ) const {
return ( the_lhs(p) && the_rhs(p) );
}

};

AndPredicate operator&& ( PaketPredicate const & lhs,
PaketPredicate const & rhs ) {
return ( AndPredicate( lhs, rhs ) );
}

class OrPredicate {

PaketPredicate the_lhs;
PaketPredicate the_rhs;

OrPredicate ( PaketPredicate const & lhs,
PaketPredicate const & rhs )
: the_lhs ( lhs )
, the_rhs ( rhs )
{}

public:

friend
OrPredicate operator|| ( PaketPredicate const & lhs,
PaketPredicate const & rhs );

bool operator() ( Paket const & p ) const {
return ( the_lhs(p) || the_rhs(p) );
}

};

OrPredicate operator|| ( PaketPredicate const & lhs,
PaketPredicate const & rhs ) {
return ( OrPredicate( lhs, rhs ) );
}

class NotPredicate {

PaketPredicate the_lhs;

NotPredicate ( PaketPredicate const & lhs )
: the_lhs ( lhs )
{}

public:

friend
NotPredicate operator! ( PaketPredicate const & lhs );

bool operator() ( Paket const & p ) const {
return ( ! the_lhs(p) );
}

};

NotPredicate operator! ( PaketPredicate const & lhs ) {
return ( NotPredicate( lhs ) );
}

class ForallPredicate
// [should use private inheritance]
: public std::vector< PaketPredicate >
{

typedef std::vector< PaketPredicate base;

public:

bool operator() ( Paket const & p ) const {
for ( base::const_iterator iter = this->begin();
iter != this->end(); ++iter ) {
if ( ! (*iter)(p) ) {
return ( false );
}
}
return ( true );
}

};

class ExistsPredicate
// [should use private inheritance]
: public std::vector< PaketPredicate >
{

typedef std::vector< PaketPredicate base;

public:

bool operator() ( Paket const & p ) const {
for ( base::const_iterator iter = this->begin();
iter != this->end(); ++iter ) {
if ( (*iter)(p) ) {
return ( true );
}
}
return ( false );
}

};
// basic paket properties
// ======================

class Divisible {

unsigned int the_modulus;

public:

Divisible ( unsigned int m )
: the_modulus ( m )
{}

bool operator() ( Paket const & p ) const {
return ( p % the_modulus == 0 );
}

};

// sanity check
// ============
int main ( void ) {
for ( unsigned int i = 0; i < 100; ++i ) {
std::cout << i << " "
<< ((Divisible(2) && Divisible(3)) || Divisible(5))(i)
<< '\n';
}
std::cout << '\n';
Divisible even ( 2 );
Divisible five ( 5 );
PaketPredicate ten = even && five;
for ( unsigned int i = 0; i < 20; ++i ) {
std::cout << i << " " << ten(i) << '\n';
}
std::cout << '\n';
ForallPredicate rare;
rare.push_back( ten );
rare.push_back( ! Divisible( 7 ) );
for ( unsigned int i = 60; i < 100; ++i ) {
std::cout << i << " " << rare(i) << '\n';
}

}
/*
For actual paket filtering, you may have Predicates that
check whether IP addresses are inside a specified range.
*/
// E.g.:

class DestinationIpInRange {};
class SourcePortInRange {};

/*
Other predicates can then be defined in terms of these
basic paket properties using the logic machinery. In the
end, a filter would be just a ForallPredicate.
*/

Best

Kai-Uwe Bux
Sep 17 '07 #7
Erik Wikström a écrit :
On 2007-09-17 11:24, Michael DOUBEZ wrote:
>Erik Wikström a écrit :
>>On 2007-09-17 09:24, in*************@gmail.com wrote:
In a recent job interview, the interviewer asked me how I'd design
classes for the following problem: let's consider a hypothetical
firewall, which filters network packets by either IP address, port
number, or both. How should we design the classes to represent these
filters?

This is really a question for a group discussing object-oriented
design so you should ask in comp.object or perhaps comp.programming.

My answer was:
class FilterByIP: public FilterRule { /* members here */ };
class FilterByPort: public FilterRule { /* members here */ };
[snip] He prefered
class FilterByIP: public Filter { /* members here */ }
class FilterByPort: public Filter { /* members here */ }
class FilterByIPAndPort: public Filter
>>Yes, I also prefer your design, it is more flexible and more easily
extended, however I've never thought much about firewall design and
there might be some other reasons to use his design.

IMO in "either IP address, port number, or both.", the "both" means
ports related to specific IP addresses and not merely applying the
rules independantely; this makes sense with the interviewer's design
and with the field.

That can easily be solved with the OP's design by adding a class like
FilterByIPAndPort, and to be honest I thought that was just an omission
of the OP (just like leaving out a FilterByIPAndPort member in the
interviewer's design. I thought the issue was the question if a
container should be used or members like in the interviewer's design.
And IMHO it is the same misunderstanding that happened during the
interview: whether thinking in terms of C++ design or field idiom. Only
the OP and the interviewer can tell.

Michael
Sep 17 '07 #8
That can easily be solved with the OP's design by adding a class like
FilterByIPAndPort, and to be honest I thought that was just an omission
of the OP (just like leaving out a FilterByIPAndPort member in the
interviewer's design. I thought the issue was the question if a
container should be used or members like in the interviewer's design.

And IMHO it is the same misunderstanding that happened during the
interview: whether thinking in terms of C++ design or field idiom. Only
the OP and the interviewer can tell.
Thanks for all the replies. To be honest, the thought that filtering
by IP address and port can correlate never crossed my mind during the
interview. I always thought that they are independent of each other,
as probably can be seen on my solution to the problem. Maybe it's true
that the interviewer and I understood the problems differently, which
explains his dissatisfaction with my answer. As Erik has mentioned, my
oversight can easily be solved by adding a FilterByIPAndPort to my
design. Had I done that, I might've gotten the job :P

Sep 17 '07 #9

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: Don Vaillancourt | last post by:
Hello all, Over the years as I design more database schemas the more I come up with patterns in database design. The more patterns I recognize the more I want to try to design some kind of...
9
by: sk | last post by:
I have an applicaton in which I collect data for different parameters for a set of devices. The data are entered into a single table, each set of name, value pairs time-stamped and associated with...
2
by: Test User | last post by:
Hi all, (please excuse the crosspost as I'm trying to reach as many people as possible) I am somewhat familiar with Access 2000, but my latest project has me stumped. So, I defer to you...
6
by: rodchar | last post by:
Hey all, I'm trying to understand Master/Detail concepts in VB.NET. If I do a data adapter fill for both customer and orders from Northwind where should that dataset live? What client is...
17
by: tshad | last post by:
Many (if not most) have said that code-behind is best if working in teams - which does seem logical. How do you deal with the flow of the work? I have someone who is good at designing, but...
17
by: roN | last post by:
Hi, I'm creating a Website with divs and i do have some troubles, to make it looking the same way in Firefox and IE (tested with IE7). I checked it with the e3c validator and it says: " This...
6
by: JoeC | last post by:
I have a question about designing objects and programming. What is the best way to design objects? Create objects debug them and later if you need some new features just use inhereitance. Often...
0
by: | last post by:
I have a question about spawning and displaying subordinate list controls within a list control. I'm also interested in feedback about the design of my search application. Lots of code is at the...
19
by: neelsmail | last post by:
Hi, I have been working on C++ for some time now, and I think I have a flair for design (which just might be only my imagination over- stretched.. :) ). So, I tried to find a design...
0
by: abbasky | last post by:
### Vandf component communication method one: data sharing ​ Vandf components can achieve data exchange through data sharing, state sharing, events, and other methods. Vandf's data exchange method...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Aftab Ahmad | last post by:
Hello Experts! I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.