Here's a bit of code:
======================
[Player.cpp]
======================
#include "TmTeam.h"
#include "TmPlayer.h"
#include "Player.h"
void Player::doTurn()
{
(...)
Tm_doPost();
(...)
}
===================
[Player.h]
===================
class Player
{
(...)
public:
(...)
virtual void Tm_doPost() = 0;
(...)
};
===================
[TmPlayer.cpp]
===================
#include "TmPlayer.h"
#include "TmTeam.h"
void TmPlayer::Tm_doPost()
{
(...)
}
===================
[TmPlayer.h]
===================
#include "Player.h"
class TmPlayer : public Player
{
public:
(...)
void Tm_doPost();
(...)
};
===================
[Team.cpp]
===================
#include "TmTeam.h"
#include "TmPlayer.h"
#include "Team.h"
void Team::doTurn()
{
(...)
Tm_doPost();
}
===================
[Team.h]
===================
class Team
{
(...)
public:
(...)
virtual void Tm_doPost() = 0;
(...)
};
===================
[TmTeam.cpp]
===================
#include "TmTeam.h"
#include "TmPlayer.h"
void TmTeam::Tm_doPost()
{
(...)
}
===================
[TmTeam.h]
===================
#include "Team.h"
class TmTeam : public Team
{
(...)
public:
(...)
void Tm_doPost();
(...)
};
I'm wondering which implementation of Tm_doPost() will execute in both the calls that are shown here... I presume that the one in Team.cpp will use the definition provided by TmTeam.cpp (please correct me if I'm wrong), but what about the call made in Player.cpp? Will it use the definition that's in TmPlayer.cpp, or will just return 0 like it says in Player.h? And in both Player.h and Team.h, what does the keyword virtual does there?
By the way I tried to be as accurate as possible with the includes on top of each block of code, in case it's relevant to the question...
I will try my best to answer your questions, so to be clear I quoted the part of your question that I'm answering.
Your Question 1: I'm wondering which implementation of Tm_doPost() will execute in both the calls that are shown here... I presume that the one in Team.cpp will use the definition provided by TmTeam.cpp (please correct me if I'm wrong),
I think your wording is making it misleading. You see, you can't make an instance of a "Team" object, because it does not implement the virtual function "Tm_doPost()". If you look at the Team.cpp file, that it only implements Team::doTurn().
However, the class "Team"'s subclass "TmTeam" does implement the virtual function "Tm_doPost()", so it can be instantiated.
You could have a list of "Team"s, which contains many "TmTeam" instances. In fact, any superclass can be used as a overarching class name for the subclasses. It's called "polymorphism."
example:
List<Team> myList = new List<Team>();
myList.push_back(new TmTeam());
myList.push_back(new TmTeam());
myList.push_back(new TmTeam2()); // <--- if you have a class like this: " class TmTeam2 : Team"
//Notice there's mixed items on a list of "Team"s, because each item shares the same parent class.
Now, if we did this code:
//pseudocode, iterating through each item in myList, giving it the variable name "x"
for (each Team, x, in myList)
{
x.Tm_doPost();
}
Which implementation of Tm_doPost() will be executed? Will it be the one in TmTeam.cpp? Not necessarily. The TmTeam objects in myList will use that function, but the TmTeam2 object will use its definition. You can have many subclasses, and each subclass must implement the virtual functions for it to be able to be instantiated. Whenever it is in a list of Team objects, the compiler wonders: 'I need to call "Tm_doPost()" but I'm not sure which subclass this is. Is it a TmTeam or a TmTeam2?' However, it doesn't need to wonder, because C++ is designed that it finds out what the object really is, whether it's TmTeam or TmTeam2. Then, it calls the function on the TmTeam object, which naturally uses the definition of that function within its own class definitions. TmTeam2 will use its definition. Just like normal C++ behavior is expected to work.
So, since in Team.cpp, "Tm_doPost()" is virtual, it will have to find out what is the actual (instantiatable) object is and then call its implementation of "Tm_doPost()."
Your Question 2: but what about the call made in Player.cpp? Will it use the definition that's in TmPlayer.cpp,
It depends. Since Player is not able to be an instantiated object, then when calls are made on it (as if there is a list of Players, like the example above), it must find out what the object REALLY is - which will be some subclass of Player. If the subclass happens to be TmPlayer, then it will call TmPlayer class's implementation of Tm_doPost():
void TmPlayer::Tm_doPost()
However, if it happens to be another (theoretical) subclass of Player, such as "TmPlayer2", then it will call its implementation of Tm_doPost():
void TmPlayer2::Tm_doPost()
You see, the method that is called really depends on what the actual instance class is.
Your Question 3: or will just return 0 like it says in Player.h?
In Player.h, the line I think you are referring to:
virtual void Tm_doPost() = 0;
does not mean that it will return anything. It is just some syntax that tells the compiler that this function will not be implemented in this class - only the subclasses will be allowed to implement it.
The syntax could have been
virtual void Tm_doPost() ~ $;
and get the job done still - there's not special meaning to it. I guess a nice way to look at it, is to say that this function's implementations in this class equals 0 (or, none).
Your Question 4: And in both Player.h and Team.h, what does the keyword virtual does there?
It makes it so whenever that function is called, it will look up what the instance object's real function is, and execute that.
It also makes it so any subclasses can choose to override the function by declaring another function with the same name. But, they can also choose not to override it, and then the parent class's default function can be used instead. (This is if there is no "=0;" syntax - if it's not a pure virtual function.)
If it is a pure virtual function and you do not override it in a subclass, then that subclass cannot be instantiated either, and its subclass can only be instantiated if it overrides it.
Final comments & recommendations:
This is my best understanding at the moment of virtual functions, but I highly recommend the whole Chapter 12 of this site: http://www.learncpp.com/cpp-tutorial/122-virtual-functions/ It is where I learned what I know.
I honestly found that the best way for me to learn virtual functions was to follow online tutorials while also doing little practice-program experiments, making a bunch of classes, some which inherited from others, and had different functions, and then I got to find out which function got executed, depending on what it printed to the terminal.
Then of course, using stack overflow along the way helps for bug-related issues.
The functions declared as
virtual void Tm_doPost() = 0;
don't return 0. They are purely virtual, and define the interface of the class. Both subclasses you're asking about will call their ancestors methods and the Player::doTurn() method will call current object's Tm_doPost() method.
Member functions declared with virtual keyword are called using object's virtual methods table. So when an object of a class is instantiated all virtual methods are called by referencing the addresses stored in the table. That's why the superclass Player doesn't need to know the implementation of the Tm_doPost method.
When you call a function like this,
void Player::doTurn()
{
//...
Tm_doPost();
//...
}
i.e. within the member function of the class Player, the compiler should look for the function in that class, which in this case happens to be a pure virtual function without definition, so you can't call it. This name lookup business hardly has anything to do with files.
I don't know what your code does, but since you have a Team, a Player and a TeampPlayer class, I assume you're trying to aggregate players in a team and achieve polymorphism with the call to tm_doPost()? This is the way to do it
#include <iostream>
struct player{
virtual void foo(void){std::cout<<"player::foo";}
};
struct teamPlayer: public player{
virtual void foo(void){std::cout<<"teamPlayer::foo";}
};
then when you'll have dynamic binding with the function foo;
int main(int argc, char** argv){
teamPlayer t;
player* p = &t;
p->foo(); //outputs "teamPlayer::foo"
return 0;
}
Related
Can the same function be defined differently for different objects of the same class??
in A.h
class Hello{
public:
void myfunction();
}
main.cpp
Hello B0,B1;
// Here I want to define the function 'myfunction' for each object differently
int main(){
B0.myfunction();
B1.myfunction();
}
Is this possible?
Not directly, and I'd wonder why you want to do that if you really do want them to be objects of the same class type? This is what inheritance and virtual functions are for! If you want them to behave differently, you should make them different (but related) classes.
That said, I can think of one way to achieve something like this. std::function.
Have a class member like std::function<void(Hello*)> myfunctionimpl;, and then a member function void myfunction() { myfunctionimpl(this); }
Then in the constructor of Hello, you can set myfunctionimpl as a pointer to some other function, or with a lambda. For example, the following:
#include <functional>
#include <iostream>
class Hello {
public:
typedef std::function<void(Hello*)> MyFunctionType;
private:
MyFunctionType myfunctionimpl; // this holds the customisable function object
public:
Hello(const MyFunctionType& mf) // construct with a custom function object passed in
: myfunctionimpl(mf)
{}
Hello() // construct with a default function object
: myfunctionimpl([](Hello *h) {
std::cout << "Default function called on " << h << '\n';
})
{}
Hello(int){} // dummy to leave function object unset
void myfunction() {
// call the function object, only if it is safe to do so
if (this->myfunctionimpl) {
this->myfunctionimpl(this);
}
else {
std::cerr << "myfunctionimpl not set!\n";
}
}
};
void freeFunction(Hello*)
{
std::cout << "freeFunction\n";
}
int main()
{
Hello h1; // default
Hello h2(1); // not set
Hello h3(freeFunction); // custom function
h1.myfunction();
h2.myfunction();
h3.myfunction();
}
prints:
Default function called on 0x7fffa12518e0
myfunctionimpl not set!
freeFunction
So here the member function myfunction behaves the same way for every instance; calls the myfunctionimpl function object (if it is set). But you can customise the function object that is called for each instance, since that is just class data.
The default constructor demonstrates use of lambdas, which allow you to write small functions in place, which is probably what you will want to do to provide custom behaviour when each object is constructed. There are lots of tutorials for lambdas, for instance.
No, a member function of all instances of the same class behave the same. However, the behaviour can depend on the state of the object. For example, you could store a function pointer in a data member and call the pointed function in the member function. So, the member function does exactly the same thing for each instance: calls the function pointed by the member, but the observed behaviour may be completely different if the pointed function is different.
Also, if the function is virtual, then instances of different subclasses can override the virtual function differently.
As from your comment
I am trying to create a kind of framework using c++ and opengl. Suppose i have a object of a class lets say Button which has a function onClick. On clicking button different users should be able to define the function in their own way.
See here for an excellent article by Herb Sutter on the subject of virtuality, since that is what you would look for when considering to build functionality described in your question and building framework.
The questions are old, but people still keep asking them,
One building framework could be interested on
Polymorphism pointers and class inheritance;
Virtual functions a member functions whose behavior can be overridden in derived classes.
This is another, "My code isn't working and i don't know why, " question i'm afraid. I just don't have enough knowledge of the stl to know why std::map::insert would throw an exception. If you know what cases it throws an exception, you can probably skip this wall of text and just answer. If you just desperately need some background on the issue, then have at it. I'll post my code and explain what is done, and i would be very grateful if all you with a better knowledge of the stl could explain what could be wrong with my call to insert.
I wrote an object awhile ago that i use occasionally as my go to factory object. It's main purpose is basically to take a string and store both the string and a "create new object function" pointer, so that in the end, you can call a function, pass a string, and if there is a valid registration for it, it returns a new instance of a derived object. Less talk, more code, here's what i got:
factory.h
#ifndef FACTORY_H
#define FACTORY_H
// library tools
#include <map>
#include <string>
// Simplified registration macros
#define DECLARE_DERIVED(T, base) static Factory<base>::DerivedRegister<T> reg;
#define DEFINE_DERIVED(T, base, s) Factory<base>::DerivedRegister<T> T::reg(s);
template<class base>
class Factory
{
protected:
template<class T>
static base * createT() { return new T;}
public:
typedef std::map<std::string, base*(*)()> map_type;
virtual ~Factory(){ }
static base * createInstance(const std::string & s)
{
if(!m_Map.count(s))
return nullptr;
std::map<std::string, base*(*)()>::iterator it = m_Map.find(s);
return it->second();
}
template <class T>
struct DerivedRegister;
protected:
static map_type m_Map;
};
template<class base>
template<class T>
struct Factory<base>::DerivedRegister : public Factory<base>
{
DerivedRegister(std::string const & s)
{
m_Map.insert(std::pair<std::string, base*(*)()>(s, &createT<T>));
}
};
#endif
here's a better explanation of what it does real quick. Let's say you have a base class, class A . and then you have any number of derived classes. I make a factory object somewhere templated to A, and then either create a derived register object manually, or use the macro at the top within the derived classes declaration to create a static registry object. Then you define it in the implementation and call it's constructor, passing in a string to be used to identify the object. using the factory member createInstance you can pass in a string identifier and have a derived object returned, pointed to by an A *.
example:
A.h
class A
{
};
A.cpp
// the map for this factory template has to be defined somewhere, as it is static
Factory<A>::map_type Factory<A>::m_Map;
b.h
#include <A.h>
class B : public A
{
// anywhere in declaration of derived B
DECLARE_DERIVED(A, B)
};
b.cpp
// just somewhere in cpp file
DEFINE_DERIVED(A, B, "B")
main.cpp
int main()
{
A * ptr;
Factory<A> factory;
ptr = factory.createInstance("B");
}
This object has worked for me in the past, mostly without a hitch. Now i'm doing a project a little more complicated. I've taken a liking to the data organization/ api design involved with game engines, and i'm just trying to implement a solution of cataloging, (but not instantiated) shaders, so that you have a whole list of the shaders you've programmed, but they will not be instantiated at run-time unless needed. That aside, this question actually has nothing to do with d3d11, or at least i hope not.
So here is what's going on. I have an object that represents a graphics-shader abstract class. All the shaders you wish to write must derive from this object. The you derive from and implement it's functions differently for all your different shaders.
let's call the base object "SYNC::D3D11Shader" in namespace sync and the derived shaders "ColorShader" "LightShader" and "TextureShader". Since i do not simply want to make an std::map of instances of these shaders within the rendering object, i make a factory within the rendering object like this.
D3D11Renderer.h
class D3D11Renderer
{
// many other members...
Factory<D3D11Shader> m_ShaderFactory;
// many other member...
};
D3D11Renderer.cpp
// define this templated classes map or you'll get undefined errors
Factory<SYNC::D3D11Shader>::map_type Factory<SYNC::D3D11Shader>::m_Map;
and then in the ColorShader i use the macros like so
D3D11ColorShader.h
class D3D11ColorShader : public SYNC::D3D11Shader
{
// ...lotsa members
DECLARE_DERIVED(D3D11ColorShader, SYNC::D3D11Shader)
// lotsa member...
};
D3D11ColorShader.cpp
// define the registery object with it's key here
DEFINE_DERIVED(D3D11ColorShader, SYNC::D3D11Shader, "ColorShader")
this all compiles fine, and where it throws it's exception is where i first call the registryObjects constructor in D3D11ColorShader.cpp, spefically at the insert call. the exception error is this:
Unhandled exception at 0x772315de in Syncopate.exe: 0xC0000005: Access
violation reading location 0x00000004.
So in reality, the question boils down to, when does std::map::insert throw an exception and why. I just knew everyone would be asking for some background on what i'm doing. Low and behold, a giant wall of text has appeared! All i really need is a hunch.
also should i or should i not tag d3d11, because the question doesn't really pertain to it?
Here's a problem:
std::map<std::string, base*(*)()>::iterator it = m_Map.find(s);
return it->second();
if the call to find fails (i,e. it can't find 's' in the map), then it will return m_Map.end(). Dereferencing that is a no-no.
My guess would be that this is due to the order of initialization of static variables. There is no way to control this order. So you are not guaranteed that your initialization:
Factory<A>::map_type Factory<A>::m_Map;
gets called before this initialization:
DEFINE_DERIVED(A, B, "B")
In this case the latter statement must be getting initialized first and so you map has not been allocated.
An alternative design pattern would control the initialization of the singleton factories. If you have an explicit Initialize function on each which creates the factory object then you can call this at the start of your main. E.g.
Factory.h
class Factory {
private:
static Factory* instance_;
public:
static Initialize(){instance_=new Factory;}
Factory* instance(){return instance_;}
}
Factory.cpp
static Factory* Factory::instance_ = NULL;
If you have a lot of factories you will probably want a single initialize function that initializes them all, and you will have to remember to add in the new factories as you create them.
Okay, i have actually been laboring over this error for about a day, and only now do i realize what is wrong.
problem 1:
the derived shaders header was never actually included anywhere throughout the project, and despite the fact that it never needs to be directly instantiated, it still has to be included somewhere so it can be linked and included in build.
problem 2:
interesting enough, just like combinatorial said, the initialization order was not done one after the other, but then looking over my old code, it seemed to initialize correctly before. what the difference here was, i put the factory of the derived objects within a different object then the base class. what i used to do was declare a static function and static factory within the base class so that you could instantiate any of it's registered derived classes from the base class itself. When the factory is included within the base class instead, and instantiation is done through a static function, the initialization order of all the statics seems to be constently in order ( not sure if this is always true). It runs fine now after changing this.
so now, my answer, you can get operating system exceptions like this for trying to use references to objects that were never actually included anywhere in your project. I don't have a very good knowledge of compilers or linkers to tell you why it seemed to compile fine, despite this object never being included. If someone wants to extend my answer, please.
I use MSVC++ 2010 express if that pertains to this predicament.
A is a base class, B is an inherited class. A takes member function pointers from B bound with boost::bind+boost::function to store and execute from other base class functions later. The A and B classes are in separate include files. I would like to restrict the developer who implements inherited classes from A that the bound member function pointers in the inherited classes are private functions. The environment is C++, gcc 4.x and Linux.
Sample:
------ INCLUDE FILE -----
#include <boost/bind.hpp>
#include <boost/function.hpp>
struct A
{
protected:
void Register(const char* name, boost::function<void()> FuncPtr)
{
// (I am not intended to pass the name argument, but probably somebody
// knows something gcc magic which would use it to solve the problem.)
// I want to ensure that FuncPtr points to a private member
// function. What can be known: "B::CalledFunction" string and FuncPtr.
// If it is not a private member function then drop an error message
// during run-time or during compilation (???).
}
};
------ OTHER INCLUDE FILE -----
...
struct B : public A
{
B() : A()
{
Register("B::CalledFunction", boost::bind(&B::CalledFunction, this));
}
private:
void CalledFunction()
{
}
};
Any kind of macro magic or similar stuff can also be appreciated before/instead of a simple direct call to A::Register().
Rather than expand the comments, I will propose an alternative based on really using inheritance
#include <iostream>
#include <memory>
class A
{
public:
void call_a() { some_func_a(); }
private:
virtual void some_func_a() = 0; // pure virtual
};
class B : public A
{
private:
void some_func_a() { std::cout << "B::some_func_a" << std::endl; }
};
int main(void)
{
std::auto_ptr<A> a(new B);
// a->some_func_a(); // causes compiler error
a->call_a();
}
If you leave out the definition of some_func_a in B, you'll get a compiler error when you try to instantiate B.
Unfortunately, the restriction you ask for is not possible. Access restrictions are only present at compile time, not runtime; the only thing they do is control (based on lexical scope) what identifiers can be referenced.
Since the calling context producing these bound member functions obviously has access to all its member functions, you cannot distinguish between private and public member functions locally - this rules out any macro hacks. Further, member function pointers do not retain access control information (this is why you can call a pointer to a private member function from another class). As such, checking elsewhere is also not possible.
You may be able to implement this as a compiler pass in something like clang, as the information is available there at compile time; however this is not possible with a normal C++ compiler. However, this may be prone to false positives and false negatives, as the situation in which this is an issue is somewhat ill-defined (what if some derived class B really wants a bound public member function, that it'll use elsewhere?)
Hey i'm trying to make a very simple GUI using SFML, and i want to be able to attach a function to my Button class in the constructor, as so the user can define what happens when the button is pressed.
I've worked a little before with GLUT and noticed these declerations:
glutReshapeFunc(Resize);
glutDisplayFunc(Draw);
Which apparently define what function should be called when the window is resized or displayed. I want something exactly like this for my button so upon construction you can define what function should be called. I want to be able to pass a function name just like glut, not having define a new class wich overides a virtual functin.
I also doubt it's possible however to pass parameters for these
called functions, as you never know what or how many there would be.
Am i right?
So anyway..... How do i accomplish this or something like it?? Thanks!
You can store a callback using e.g. std::function (for C++0x; boost::function is also available and has a similar interface).
#include <functional>
class Button {
public:
template<typename T>
explicit
Button(T const& t): callback(t) {}
void
press()
{
callback();
}
private:
std::function<void()> callback;
};
// example use with a lambda
Button b([] { do_stuff(); });
b.press(); // will call do_stuff
In C++ it's better to use virtual function approach to address such kind of problems. That's more maintainable at long run.
You can choose to redesign a little bit to your code, where you can have a common handle to various subclasses. Now based on subclass chosen you can call a particular function. For example:
class Shape
{
public:
virtual void Resize () = 0;
virtual void Draw () = 0;
};
class Triangle : public Shape
{
public:
// implement above to functions
};
class Square : public Shape
{
public:
// implement above to functions
};
Now, just pass the handle of Shape* wherever you want and call the above abstract methods;
void foo(Shape *p)
{
p->Resize();
}
(Rewrote everything), I had misread the question.
You seem to be wanting to pass plain old function pointers around to other functions. All you need to do is just pass the name of the function you want, but do so inside an if (or something like that) so the function passed is actualy what you want:
if(i am feeling lucky today){
glutDisplayFunc(DrawMyLuckyShape);
}else{
glutDisplayFunc(DrawAFoo);
}
The bad news is that since C is a nasty language you can't set up to pass extra parameters to your functions (ie, use closures). Therefore, you need to rely on a) the functions being passed some parameter quen being called or b) the functions looking at some global state.
I have a simple, low-level container class that is used by a more high-level file class. Basically, the file class uses the container to store modifications locally before saving a final version to an actual file. Some of the methods, therefore, carry directly over from the container class to the file class. (For example, Resize().)
I've just been defining the methods in the file class to call their container class variants. For example:
void FileClass::Foo()
{
ContainerMember.Foo();
}
This is, however, growing to be a nuisance. Is there a better way to do this?
Here's a simplified example:
class MyContainer
{
// ...
public:
void Foo()
{
// This function directly handles the object's
// member variables.
}
}
class MyClass
{
MyContainer Member;
public:
void Foo()
{
Member.Foo();
// This seems to be pointless re-implementation, and it's
// inconvenient to keep MyContainer's methods and MyClass's
// wrappers for those methods synchronized.
}
}
Well, why not just inherit privatly from MyContainer and expose those functions that you want to just forward with a using declaration? That is called "Implementing MyClass in terms of MyContainer.
class MyContainer
{
public:
void Foo()
{
// This function directly handles the object's
// member variables.
}
void Bar(){
// ...
}
}
class MyClass : private MyContainer
{
public:
using MyContainer::Foo;
// would hide MyContainer::Bar
void Bar(){
// ...
MyContainer::Bar();
// ...
}
}
Now the "outside" will be able to directly call Foo, while Bar is only accessible inside of MyClass. If you now make a function with the same name, it hides the base function and you can wrap base functions like that. Of course, you now need to fully qualify the call to the base function, or you'll go into an endless recursion.
Additionally, if you want to allow (non-polymorphical) subclassing of MyClass, than this is one of the rare places, were protected inheritence is actually useful:
class MyClass : protected MyContainer{
// all stays the same, subclasses are also allowed to call the MyContainer functions
};
Non-polymorphical if your MyClass has no virtual destructor.
Yes, maintaining a proxy class like this is very annoying. Your IDE might have some tools to make it a little easier. Or you might be able to download an IDE add-on.
But it isn't usually very difficult unless you need to support dozens of functions and overrides and templates.
I usually write them like:
void Foo() { return Member.Foo(); }
int Bar(int x) { return Member.Bar(x); }
It's nice and symmetrical. C++ lets you return void values in void functions because that makes templates work better. But you can use the same thing to make other code prettier.
That's delegation inheritance and I don't know that C++ offers any mechanism to help with that.
Consider what makes sense in your case - composition (has a) or inheritance (is a) relationship between MyClass and MyContainer.
If you don't want to have code like this anymore, you are pretty much restricted to implementation inheritance (MyContainer as a base/abstract base class). However you have to make sure this actually makes sense in your application, and you are not inheriting purely for the implementation (inheritance for implementation is bad).
If in doubt, what you have is probably fine.
EDIT: I'm more used to thinking in Java/C# and overlooked the fact that C++ has the greater inheritance flexibility Xeo utilizes in his answer. That just feels like nice solution in this case.
This feature that you need to write large amounts of code is actually necessary feature. C++ is verbose language, and if you try to avoid writing code with c++, your design will never be very good.
But the real problem with this question is that the class has no behaviour. It's just a wrapper which does nothing. Every class needs to do something other than just pass data around.
The key thing is that every class has correct interface. This requirement makes it necessary to write forwarding functions. The main purpose of each member function is to distribute the work required to all data members. If you only have one data member, and you've not decided yet what the class is supposed to do, then all you have is forwarding functions. Once you add more member objects and decide what the class is supposed to do, then your forwarding functions will change to something more reasonable.
One thing which will help with this is to keep your classes small. If the interface is small, each proxy class will only have small interface and the interface will not change very often.