What would you call this interface?

[Crash]

2 Questions, but first Consider this:
I'm looking at a C++ class (patterned using the Singleton Design
Pattern). It has some public and private operations. It runs quite
happily seving the time and date to everybody. The private operations
setTheTime() and setTheDate() I require to be called/influenced
externally. For instance a class SubsysA has the right to call
setTheTime() only, and class SubsysB has the right to setTheDate()
only.

Questions:
Did I break the rules of C++ ?
What would you call this interface design pattern?

Here's how I did it.
//Note: constructor/destructor/singleton
// stuff purposely left out for brievity

Example:
class TimeDateManager
{
public:
TimeDateManager* getInstance()
timeStruct getTheTime();
dateStruct getTheDate();

private:
void setTheTime(const timeStruct& the_time);
void setTheDate(const dateStruct& the_date);
timeStruct theTime;
dateStruct theDate;
}

....And...

class SubsysA
{ //needs the right to set the time during its execution
void execute();
}
class SubsysB
{ //needs the right to set the date during its execution
void execute();
}

So, I created 2 classes I call "The Privatized Polymorphic Interface"
class PPI_A
{ friend class SubsysA;
private:
//create a virtual function same name and
//arguments as in the TimeDateManager
virtual void setTheTime(const timeStruct& the_time);
}
class PPI_B
{ friend class SubsysB;
private:
//create a virtual function same name and
//arguments as in the TimeDateManager
virtual void setTheDatee(const dateStruct& the_date);
}

Make the TimeDateManager inherit both these PPI's
class TimeDateManager : public class PPI_A, public class PPI_B
{ ...
}

Now the SubsysA has the right to do upcast in its execute()
( (PPI_A*) TimeDateMngr::getInstance()
)->set_theTime(new_time_data);

Now the SubsysB has the right to do this in its execute()
( (PPI_B*) TimeDateMngr::getInstance()
)->set_theDate(new_date_data);

Wow! It works. It meets my requirements to. Quick and clean. The PPI
parent, by v-table-polymorphism, saw its child's private operation in
the TimeDateManager! I had to predeclare some classes so circular
dependecy in the #include didn't happen.

What would you all call this type of interface?

 

[BigBrian]

2 Questions, but first Consider this:
I'm looking at a C++ class (patterned using the Singleton Design
Pattern). It has some public and private operations. It runs quite
happily seving the time and date to everybody. The private operations
setTheTime() and setTheDate() I require to be called/influenced
externally. For instance a class SubsysA has the right to call
setTheTime() only, and class SubsysB has the right to setTheDate()
only.

Questions:
Did I break the rules of C++ ?
What would you call this interface design pattern?

Here's how I did it.
//Note: constructor/destructor/singleton
// stuff purposely left out for brievity

Example:
class TimeDateManager
{
public:
TimeDateManager* getInstance()
timeStruct getTheTime();
dateStruct getTheDate();

private:
void setTheTime(const timeStruct& the_time);
void setTheDate(const dateStruct& the_date);
timeStruct theTime;
dateStruct theDate;
}

...And...

class SubsysA
{ //needs the right to set the time during its execution
void execute();
}
class SubsysB
{ //needs the right to set the date during its execution
void execute();
}

So, I created 2 classes I call "The Privatized Polymorphic Interface"
class PPI_A
{ friend class SubsysA;
private:
//create a virtual function same name and
//arguments as in the TimeDateManager
virtual void setTheTime(const timeStruct& the_time);
}
class PPI_B
{ friend class SubsysB;
private:
//create a virtual function same name and
//arguments as in the TimeDateManager
virtual void setTheDatee(const dateStruct& the_date);
}

Make the TimeDateManager inherit both these PPI's
class TimeDateManager : public class PPI_A, public class PPI_B
{ ...
}

Now the SubsysA has the right to do upcast in its execute()
( (PPI_A*) TimeDateMngr::getInstance()
)->set_theTime(new_time_data);

Now the SubsysB has the right to do this in its execute()
( (PPI_B*) TimeDateMngr::getInstance()
)->set_theDate(new_date_data);

Wow! It works. It meets my requirements to. Quick and clean. The PPI
parent, by v-table-polymorphism, saw its child's private operation in
the TimeDateManager! I had to predeclare some classes so circular
dependecy in the #include didn't happen.

IMHO, this doesn't seem clean to me. It seems weird that you create a
TimeDateManager which allows for setting both the time and date, but
then go through all of this trouble to separate access to setting the
date and time by insuring that subsysB and only modify the date and
subsysA and only modify the time. Why not just separate the
TimeDateManager into a TimeManager which only subsystemA can use, and a
DataManager which only subsystemB can use.

What would you all call this type of interface?

It seems overly complex to me. But maybe I'm missing something.

-Brian

 

[Jonathan Mcdougall]

2 Questions, but first Consider this:
I'm looking at a C++ class (patterned using the Singleton Design
Pattern). It has some public and private operations. It runs quite
happily seving the time and date to everybody. The private operations
setTheTime() and setTheDate() I require to be called/influenced
externally.

In this case they shouldn't be private. That's a flaw in your design.

For instance a class SubsysA has the right to call
setTheTime() only, and class SubsysB has the right to setTheDate()
only.

Specific friendship (you're a friend of this function only) is
impossible in C++. Trying to emulate it can only result in bad looking
code. However, if that's what you want, feel free.

You seem to have write access to all these classes. Couldn't you try to
change the design a bit?

Questions:
Did I break the rules of C++ ?
No.

What would you call this interface design pattern?

Umm.. you don't really want to know that.

Here's how I did it.
//Note: constructor/destructor/singleton
// stuff purposely left out for brievity

Example:
class TimeDateManager
{
public:
TimeDateManager* getInstance()
timeStruct getTheTime();
dateStruct getTheDate();

private:
void setTheTime(const timeStruct& the_time);
void setTheDate(const dateStruct& the_date);
timeStruct theTime;
dateStruct theDate;
}

...And...

class SubsysA
{ //needs the right to set the time during its execution
void execute();
}
class SubsysB
{ //needs the right to set the date during its execution
void execute();
}

So, I created 2 classes I call "The Privatized Polymorphic Interface"
class PPI_A
{ friend class SubsysA;
private:
//create a virtual function same name and
//arguments as in the TimeDateManager
virtual void setTheTime(const timeStruct& the_time);
}
class PPI_B
{ friend class SubsysB;
private:
//create a virtual function same name and
//arguments as in the TimeDateManager
virtual void setTheDatee(const dateStruct& the_date);
}

Make the TimeDateManager inherit both these PPI's
class TimeDateManager : public class PPI_A, public class PPI_B
{ ...
}

Now the SubsysA has the right to do upcast in its execute()
( (PPI_A*) TimeDateMngr::getInstance()
)->set_theTime(new_time_data);

Now the SubsysB has the right to do this in its execute()
( (PPI_B*) TimeDateMngr::getInstance()
)->set_theDate(new_date_data);

Wow! It works. It meets my requirements to. Quick and clean.

Well i'd say quick and dirty.

The PPI
parent, by v-table-polymorphism, saw its child's private operation in
the TimeDateManager! I had to predeclare some classes so circular
dependecy in the #include didn't happen.

What would you all call this type of interface?

Why are you so interested in finding a name?

You just showed an example of bad design and bad code in general, with
non compilable examples, ugly casts, missing semi-colons and wrong
member function names.

The next time you face a problem, try to solve it with the words
"long-term" in your mind. What if a third "subsystem" needs to acces
another member? You'll make TimeDataManager inherit from another PPI
thing again? Come on!

Get away from the keyboard for a minute, take a piece of paper and
think the design through before continuing.


Jonathan

 

[Dan Cernat]

I think the "visitor" pattern might help here.

Dan

 

[Crash]

Jonathan Wrote: What if a third "subsystem" needs to acces

another member? You'll make TimeDataManager inherit from another PPI
thing again? Come on!

Why - Yes! Eureka!

Jonathan Wrote: Specific friendship (you're a friend of this function only) is
impossible in C++. Trying to emulate it can only result in bad looking
code. However, if that's what you want, feel free.

OK I feel. Sorry you didn't like it, I guess beauty is in the eye of
the beholder!

You hit the nail right on the head. Specific Interface that's the
beauty of the PPI interface. Maybe Stroustrup wrote about this and
decided that C++ didn't need this capability, but it sounds perfectly
logical to me. Specific attribute/operation Friendship WOW... it
seems that if you can have a public interface, then you should also
have a private interface kind available too in C++.
I mean you got 3 types of data hiding: public: protected: private: and
C++ is missing the 4th - Hey Stroustup could add "SpecificProtected:"
to the list.

<Jonathan Wrote: Why are you so interested in finding a name?

Because a name is cool - just in like Gamma, Helm, Johnson, Vlissides
book "Design Patterns" Maybe they'll read this posting.
Private Polymorphic Interface (PPI) - A Design Pattern for Specific
attribute/operation Friendship. Nice! I like it!

 

[Crash]

BigBrian wrote: It seems overly complex to me. But maybe I'm missing something.
Upcasting is not overly complex. Inheritance is not overly complex.
Why wouldn't you think that a "Specific Friendship Interface" is
possible in C++? All I ask is give it some time. Think about it for a
while. Private Polymorphic Interface - a way to create a specific
interface to an element(or group of elements) of a class while hiding
it from all others and doing it in the least amount of code. Very
powerful.

I'm getting more ideas of how to define this technique by corresponding
about it. Thanks everyone.
-Crash

 

[BigBrian]

Upcasting is not overly complex. Inheritance is not overly complex.

No, but your code is ugly, IMHO. Ugly code is usually equivilent to
overly complex.

Why wouldn't you think that a "Specific Friendship Interface" is
possible in C++?

I never said that it wasn't.

All I ask is give it some time. Think about it for a
while. Private Polymorphic Interface - a way to create a specific
interface to an element(or group of elements) of a class while hiding
it from all others and doing it in the least amount of code. Very
powerful.

I don't see this as all that powerful. Why not just implement the
public interface so the class behaves correctly for everybody? If a
class needs to look different to different users of that class, then I
would probably ask myself if that class really wasn't logically two
separate classes, or if there were a simplier way to design the system.

 

[Crash]

Jon wrote:
In this case they shouldn't be private. That's a flaw in your design.

Um... this was the requirement given to me. Yes they should be private,
otherwise Tom/Dick/&Harry can set stuff they aren't supposed to. Doh!

Specific friendship (you're a friend of this function only) is
impossible in C++. Trying to emulate it can only result in bad looking
code.

IMHO, ...again...designing to requirements must be a new concept to
this group...

You seem to have write access to all these classes. Couldn't you try to
change the design a bit?

Not true. Every set function is private.

You just showed an example of bad design and bad code in general,...
Get away from the keyboard for a minute, take a piece of paper and
think the design through before continuing.
Jonathan

Dude, have you ever thought that given:
1) requirements,
2) old reuse code to modify (not redesign), and
3) a time table to deliver,
all those things might dictate a creative method/solution to
restrict/encapsulate using the dictates of the compiler instead of some
verbal agreed-to rule? Ex. "Don't use that public accessor method".
When everything is "public accessable" so, your boss gets to slap your
hand for using attributes and operations unintended for your piece of
the code pie? Come on.

The moral of the story boys and girls:
*** Having the compiler do the private restrictions check work is much
safer than having all public attributes and operations. ***

 

[Shezan Baig]

The moral of the story boys and girls:
*** Having the compiler do the private restrictions check work is much
safer than having all public attributes and operations. ***

The purpose of private restrictions is not to prevent "certain people"
from accessing your methods. It is to protect the integrity of your
object's state. If the collection of public operations in your class
cannot guarantee this, then I doubt that many people will want to use
your class.

Try to rethink your understanding of encapsulation/information hiding.

Hope this helps,
-shez-