OOP - OOD Question

  • Thread starter Thread starter David Ichilov
  • Start date Start date
D

David Ichilov

let's say i have a class

class baseclass
{
...
public int someProperty
{
....
}
}

and now i create new class, there i use "someProperty", but don't want the
users of my class use it, not in design time, not in real time....
 
What do you mean by "see"? Intellisense? Properties window?

An obvious solution would be to declare the property private or friend, but
you've probably figured that yourself. :-)

--
Greetz

Jan Tielens
________________________________
Read my weblog: http://weblogs.asp.net/jan
 
David,
let's say i have a class

class baseclass
{
...
public int someProperty
{
....
}
}

and now i create new class, there i use "someProperty",
but don't want the users of my class use it, not in design
time, not in real time....
Click to expand...

It's difficult to guess at what you are getting at here. There is bound to
be an ideal architecture that fits your situation. And there is a pretty
high percentage that I will not guess the right one. But one approach is:

abstract class baseclass
{
public abstract int someProperty{ get; }
}

sealed class newclass : baseclass
{
public override int someProperty
{
get
{
return 1;
}
}
}

class newclassForUser : baseclass
{
public override int someProperty
{
get
{
return 0;
}
}
}

This keeps the user from inheriting from your "sealed" class and behavior.
It also makes them implement their own version of "someProperty," but that
can be trivial and never used.

Hope that helps in some way.

Regards,

Randy
 
Use it in what way?

View it, Modify it, Set it? None of these?

If the user to have absolutely no access to the property then make it
private.

If you want them to just be able to view it but not change it the property
do this.

class baseclass
{
private int InternalValue;
public int someProperty
{
get
{
return InternalValue;
}
}
}

If you want them to be able just to set the value but not to read it then do
this:

class baseclass
{
private int InternalValue;
public int someProperty
{
set
{
InternalValue = return;
}
}
}

I can't think what else you'd mean but not use it?

Hope I've helped :)

Simon.
 
i meant:

i've that class and can't chage it

class baseclass
{
public int someProperty { set; get; }
}

now, i wrote that class

class newclass : baseclass
{
public void someFunction()
{
base.someProperty = 0;
}
}

and what i want, is that the user who uses my class:
"newclass ncObject;", he wouldn't be able to use baseclass::someProperty via
"ncObject"
 
i meant:

i've that class and can't chage it

class baseclass
{
public int someProperty { set; get; }
}

now, i wrote that class

class newclass : baseclass
{
public void someFunction()
{
base.someProperty = 0;
}
}

and what i want, is that the user who uses my class:
"newclass ncObject;", he wouldn't be able to use baseclass::someProperty via
"ncObject"
 
i meant:

i've that class and can't chage it

class baseclass
{
public int someProperty { set; get; }
}

now, i wrote that class

class newclass : baseclass
{
public void someFunction()
{
base.someProperty = 0;
}
}

and what i want, is that the user who uses my class:
"newclass ncObject;", he wouldn't be able to use baseclass::someProperty via
"ncObject"
 
David Ichilov said:
i meant:

i've that class and can't chage it

class baseclass
{
public int someProperty { set; get; }
}

now, i wrote that class

class newclass : baseclass
{
public void someFunction()
{
base.someProperty = 0;
}
}

and what i want, is that the user who uses my class:
"newclass ncObject;", he wouldn't be able to use baseclass::someProperty via
"ncObject"
Click to expand...

You're not going to be able to do that, in the long run, because anyone
could always say:

baseclass bcObject = ncObject;

bcObject.someFunction();

You could provide a new version of someFunction which just threw an
exception, but it's basically a nasty thing to do, and violates
Liskov's Substitutability Principle.

Do you absolutely *have* to derive from baseclass? A common solution to
this kind of problem is to make newclass have a reference to an
instance of baseclass, using composition rather than inheritence.
 
i've. couse, i'm writig custom control wich uses TreeView as a base class. I
do not want the users of my custom control to use "Nodes" ands some other
properties of TreeView. I tried to use ControlDesigner, with its
PreFilterProperties method, but, it only removes that properties from
"Properties" window in design time...

then i declared "new proteced ... Nodes { get; }", but it has no results
too.

i guess there's nothing let to do :((
 
David Ichilov said:
i've. couse, i'm writig custom control wich uses TreeView as a base class.
Click to expand...

Does it *have* to use TreeView as a base class? If you don't want users
to use it as they would use a TreeView, then it doesn't sound like it's
a good candidate to derive from TreeView.
 
David Ichilov said:
i've. couse, i'm writig custom control wich uses TreeView as a base
class. I do not want the users of my custom control to use "Nodes"
ands some other properties of TreeView. I tried to use
ControlDesigner, with its PreFilterProperties method, but, it only
removes that properties from "Properties" window in design time...

then i declared "new proteced ... Nodes { get; }", but it has no
results too.

i guess there's nothing let to do :((
Click to expand...

As Jon allready stated, composition is the correct aproach to achieve
your requirements (Build a special TrreView + Provide the user just one
interface for it).
-Build your own control and derive it from UserControl
-put a TreeView in your user Control and set its Dockstyle to "fill"
-Implement the Methods and Properties that you want to offer the user
and your own special stuff in the control
 
Back
Top