Beginner interface question

[^MisterJingo^]

I've been reading up on interfaces, one example I came across showed
that you can hide a method implemented from an interface from the class
which implements it. To use it, you must cast to the interface type
e.g.:

interface IFoo
{
void display();
}

class Blah : IFoo
{
void IFoo.display()
{
System.Console. WriteLine("hell o");
}
}

class MainApp
{
public static void Main()
{
Blah myBlah = new Blah();

myBlah.display( ); //error
((IFoo)myBlah). display(); //works
}
}

In what circumstances would you ever want to do this? The place I found
this didn't explain why this would ever be done.
Sorry if these questions are missing the obvious :).

Chris

[yoshijg]

The circumstances you would use an Interface in such a manner, is when
there is a need to limit accessibility to methods.

For example, suppose your "Blah" class was an abstraction of a
Database. Inside that class would be "Delete", "Create", "Update",
"Insert", "Select" functions. Now whoever uses the "Blah" object can
do some serious damage to the Database if they are not careful. So to
limit damage you might want to create an interface. Possible
interfaces would be as follows :

IDbAdmin -> Has access to all functions
IReadOnlyUser -> Has access to "Select" functions only.
IUpdateOnlyUser -> Has access to "Update" / "Insert" functions only.
ICreateOnlyUser -> Has access to "Create" functions only.
etc..

You can also chose to not create a "Delete" interface because you may
decide only admins have access to that feature.

I believe this is what they call a FACADE pattern.

Hope this was a good practical example.

enjoy,
Josh Go

[Dave Johnson]

I have the same Problem, and cannt figure it out as i am new to
Interfaces,

Classes:

1-DataRepository Class - Contains (GetClientInfo Method, GetOrderInfo
Method)
2-Client Class
3-Order Class

The DataRepository Class has all the Functions that deals with the
Database such as (Client & Order) database methods.

Required:

make the Client Class have only Access to the GetClientInfo Method
and not also the GetOrderInfo Method and vice versa

How to do it using Interfaces??

can u please show it in code, as i am new to Interfaces

Sharing makes All the Difference

--
Sent via .NET Newsgroups
http://www.dotnetnewsgroups.com

[yoshijg]

Hey Dave,

I replied to your original post about FACADEs.

Here is some sample code. In this example I create a "TextFile" object
which is an abstraction of a normal text file on disk. Now every file
on your computer has "Access" rights. I simulated those access rights
with interfaces. So in this example, there is a "IReadOnlyUser" ,
"IWriteOnlyUser ", and "IFileAdmin " interface. The first 2 interfaces
are pretty self-explanatory and the IFileAdmin is just an interface
that has both read/write capabilities.

using System;

namespace CS_InterfaceTes t
{
#region interfaces

interface IFileAdmin : IReadOnlyUser, IWriteOnlyUser{ }

interface IReadOnlyUser
{
void PrepareForRead( );
string ReadLine();
void CloseRead();
}
interface IWriteOnlyUser
{
void PrepareForWrite ();
void WriteLine(strin g p_String);
void CloseWrite();
}

#endregion

#region textfile class

class TextFile : IFileAdmin
{
private string m_Filename;
private System.IO.Strea mReader m_StreamReader;
private System.IO.Strea mWriter m_StreamWriter;

#region properties

public string Filename
{
get{return m_Filename;}
set{m_Filename = value;}
}

#endregion

#region read access

void IReadOnlyUser.P repareForRead()
{
m_StreamReader = new System.IO.Strea mReader(this.Fi lename);
}
string IReadOnlyUser.R eadLine()
{
string buff = null;
if( m_StreamReader. Peek() != -1 )
{
buff = m_StreamReader. ReadLine();
}
return buff;
}
void IReadOnlyUser.C loseRead()
{
m_StreamReader. Close();
}

#endregion

#region write access
void IWriteOnlyUser. PrepareForWrite ()
{
m_StreamWriter = new System.IO.Strea mWriter(this.Fi lename,
true);
}
void IWriteOnlyUser. WriteLine(strin g p_String)
{
m_StreamWriter. WriteLine(p_Str ing);
}
void IWriteOnlyUser. CloseWrite()
{
m_StreamWriter. Close();
}
#endregion

}

#endregion

#region main/testing code
class MainClass
{
[STAThread()]
public static void Main()
{
TextFile file = new TextFile();
file.Filename = "foo.txt";

Console.WriteLi ne("---- Admin Test ----");
FullyTrustedUse r((IFileAdmin)f ile);

Console.WriteLi ne("");

Console.WriteLi ne("---- Write Test ----");
SemiTrustedUser ((IWriteOnlyUse r)file);

Console.WriteLi ne("");

Console.WriteLi ne("---- Read Test ----");
UntrustedUser(( IReadOnlyUser)f ile);
}

//demonstrate read/write access
public static void FullyTrustedUse r(IFileAdmin p_Admin)
{
//Write something
p_Admin.Prepare ForWrite();
p_Admin.WriteLi ne("I am the admin");
p_Admin.CloseWr ite();

//Read it out
p_Admin.Prepare ForRead();
string buff = p_Admin.ReadLin e();

while( buff != null)
{
Console.WriteLi ne(buff);
buff = p_Admin.ReadLin e();
};
p_Admin.CloseRe ad();
}

//demonstrate read access
public static void UntrustedUser(I ReadOnlyUser p_Read)
{
p_Read.PrepareF orRead();
string buff = p_Read.ReadLine ();

while( buff != null)
{
Console.WriteLi ne(buff);
buff = p_Read.ReadLine ();
};
p_Read.CloseRea d();
}

//demonstrate write access
public static void SemiTrustedUser (IWriteOnlyUser p_Write)
{
p_Write.Prepare ForWrite();
p_Write.WriteLi ne("I am not fully trusted");
p_Write.CloseWr ite();
}
}
#endregion
}

[Jeff Louie]

yoshig... one caution, limiting access through the type of a reference
is a weak guarantee. once I have access to the reference of the limited
type, I can just cast it to the type of the full reference.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Jeff Louie]

How about:

using System;
using System.Collecti ons.Generic;
using System.Text;

namespace LimitedAccess
{
interface IData
{
int ClientInfo { get;set;}
int OrderInfo { get;set;}
}
interface IClient
{
int ClientInfo { get;}
}
interface IAdministrator
{
int ClientInfo { get;set;}
int OrderInfo { get;set;}
}
// not thread safe
class Data : IData
{
private int clientInfo = 0;
private int orderInfo = 0;
public Data(int clientInfo, int orderInfo) {
this.clientInfo = clientInfo;
this.orderInfo= orderInfo;
}
public int ClientInfo
{
get { return this.clientInfo ; }
set { this.clientInfo = value; }
}
public int OrderInfo
{
get { return this.orderInfo; }
set { this.orderInfo = value; }
}
}
class Client : IClient
{
private IData data = null;
//ASSERT data not null
public Client(IData data)
{
if (data == null) { throw new ArgumentExcepti on(); }
this.data = (Data)data;
}
public int ClientInfo
{
get { return data.ClientInfo ; }
}
class Administrator : IAdministrator
{
private IData data = null;
// ASSERT data not null
public Administrator(I Data data)
{
if (data == null) { throw new ArgumentExcepti on(); }
this.data = data;
}
public int ClientInfo
{
get
{
return data.ClientInfo ;
}
set
{
this.data.Clien tInfo = value;
}
}
public int OrderInfo
{
get { return this.data.Order Info; }
set { this.data.Order Info = value; }
}

static void Main(string[] args)
{
IData data= new Data(2,3);
Administrator adm = new Administrator(d ata);
Client c = new Client(data);
System.Console. WriteLine(adm.O rderInfo);
System.Console. WriteLine(c.Cli entInfo);
//System.Console. WriteLine(c.Ord erInfo); // error Client
does not contain a definition...
System.Console. ReadLine();
}
}
}
}
Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[yoshijg]

Hey Jeff,

You are totally correct and thanks for pointing that out. Interfaces
are not the way to go for "securing access". I should have picked a
better example than "read/write access"...sorry about that.
The idea behind my solution was to be able to relate a bunch of
functions, but still deal with the exact same object.

I actually like your example, it's very clear and assertive. The data
and logic are completely broken as they should be.

Now as for Dave Johnson's request...the 2nd post. What's your take on
that?

[Jeff Louie]

Hmm... A correction:

private IData data = null;
//ASSERT data not null
public Client(IData data)
{
if (data == null) { throw new ArgumentExcepti on(); }
this.data = data; // no need to cast to (Data)
}

So you can pass any concrete class that implements IData.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Daniel Jin]

Here's how I would use explicit interface implementation

1. the obvious one is to avoid method collision. when two interfaces have
the same method defined, but will require different implementations .
although I don't remember ever run into this situation.
2. if the member should be exposed using an alternative name better suited
in the context of the object that implements it. I'd hide the interface name
instead of exposing both.
3. if a method is rarely / never called directly off of the object, most
times it's something required for the framework support and used indirectly
by something else. IComparable.Com pareTo is always a good candidate for that.
4. related to 3, when implementing an internal interface. typically, these
should always be hidden from the consumers.

"^MisterJin go^" wrote:

I've been reading up on interfaces, one example I came across showed
that you can hide a method implemented from an interface from the class
which implements it. To use it, you must cast to the interface type
e.g.:

interface IFoo
{
void display();
}

class Blah : IFoo
{
void IFoo.display()
{
System.Console. WriteLine("hell o");
}
}

class MainApp
{
public static void Main()
{
Blah myBlah = new Blah();

myBlah.display( ); //error
((IFoo)myBlah). display(); //works
}
}

In what circumstances would you ever want to do this? The place I found
this didn't explain why this would ever be done.
Sorry if these questions are missing the obvious :).

Chris

[^MisterJingo^]

Thanks for the replies all, it makes more sense now. I thought it might
be a bit 'fiddly' casting to the interface type to call certain
methods, but after playing around, I found out this:

public interface IShape
{
double area();
double circumference() ;
int sides();
void blah();
}

public class Oblong :IShape
{
public int side;

public double area() { return (double)((side * side) * 2); }

public double circumference() { return ((double)(6 * side)); }

public int sides() { return 4; }
public Oblong() { side = 0;}

void IShape.blah(){ Console.WriteLi ne("Test"); }
}

public class Shape
{
public static void Main(string[] args)
{
Oblong myOb = new Oblong();
myOb.side = 5;
Console.WriteLi ne("Displaying Info:");
displayInfo(myO b);
}

static void displayInfo(ISh ape myShape)
{
Console.WriteLi ne("Area: {0}", myShape.area()) ;
Console.WriteLi ne("Sides: {0}", myShape.sides() );
Console.WriteLi ne("Circumferen ce: {0}",
myShape.circumf erence());
myShape.blah();
}
}

using a method taking the interface type, I can perhaps see uses for
that.

A quick question:
If I had a number of objects which were not derived from the same base
class. Each of these objects had a load and save method, which were
called on every instanced object when the user selected a save event.
Would it be best to create a load/save interface, and then use a method
such as above. Or would it be best to use a function which calls every
object in turn, decides what form the object is and then load/save. Or
even factoring all objects which need load and save functionality into
a common base class? (the load or save could be something like
drawToScreen etc).

I'm trying to get my head around when best to use interfaces etc.

Thanks,

Chris