We Keep Coding

An object that securely provides both public API (read-only) and private API (read-write)

This is an architecture problem. Programmers encounter this encapsulation problem quite often, but I haven't yet seen a complete and clean solution.
Related questions:
readonly class design when a non-readonly class is already in place
Controlling read/write access to fields
Normally, in OOP paradigm, objects store their data in fields. The class' own methods have full access to its fields. When you need to return value, you just return a copy of the data, so that the outside code cannot break the data.
Now suppose that the data pieces are complex, so they're themselves encapsulated in class objects and that these objects cannot be easily copied. Now, if you return such object from some property, the outside code has the same access to it as your internal code. For example, if you return a List<int>, everyone can add values to it. This is usually undesirable.
This problem is usually worked around using read-only wrappers - you wrap your full-access internal objects in read-only wrappers before returning. The problem with this approach is that the wrapper may be a poor substitution for the wrapped value - the wrapper is a different class. (And if you derive the read-only wrapper from the modifiable class (or vise-versa), then anybody can up-cast/down-cast the "read-only" object to the modifiable object, breaking the protection.)
I want a pattern such that:
The data (say, an int value) has "public/read-only API" and "private/modifiable API".
Only the object creator has access to the "private/modifiable API".
The private/public APIs may have both passive parts (e.g. methods, properties) and active parts (e.g. events).
Delegates should not be used except at the object creation stage. All calls should be direct.
The access to the internal data from the "public/read-only API" (and, preferably, from the "private/modifiable API" too) should be as direct as possible. I don't want a big stack of wrappers to accumulate when composing such objects.
Here are the sample interfaces:
interface IPublicApi {
int GetValue();
}
interface IPrivateApi {
void SetValue(int value);
}
interface IPrivateConsumer {
void OnValueChanged(); //Callback
}
I have devised such scheme. I want you to critique my solution or give your own solution.

There are several sub-problems that have to be solved.
How to allow the "private API" code to access the private data without allowing the outside code to call it?
How to give the "private API" access to the object creator?
How to establish the two-way communication between the object and the code using the private API (calling/getting called)?
My system consists of these classes:
ReadableInt is the public API
ReadableInt.PrivateApi is the raw private API proxy object
ReadableInt.IPrivateConsumer is the public-to-private callback interface
public sealed class ReadableInt {
int _value;
IPrivateConsumer _privateConsumer;
public ReadableInt(IPrivateConsumer privateConsumer, Action<PrivateApi> privateConsumerInitializer) {
_privateConsumer = privateConsumer;
var proxy = new PrivateApi(this);
privateConsumerInitializer(proxy);
}
public int GetValue() {
return _value;
}
private void SetValue(int value) {
_value = value;
_privateConsumer.OnValueChanged();
}
public interface IPrivateConsumer {
void OnValueChanged();
}
public class PrivateApi {
ReadableInt _readableInt;
internal PrivateApi(ReadableInt publicApi) {
_readableInt = publicApi;
}
public void SetValue(int value) {
_readableInt.SetValue(value);
}
}
}
WritableInt is some private API consumer, which may reside in another assembly.
public sealed class WritableInt : ReadableInt.IPrivateConsumer {
ReadableInt _readableInt;
ReadableInt.PrivateApi _privateApi;
public WritableInt() {
_readableInt = new ReadableInt(this, Initialize);
}
void Initialize(ReadableInt.PrivateApi privateApi) {
_privateApi = privateApi;
}
public ReadableInt ReadOnlyInt { get { return _readableInt; } }
public void SetValue(int value) {
_privateApi.SetValue(value);
}
void ReadableInt.IPrivateConsumer.OnValueChanged() {
Console.WriteLine("Value changed!");
}
}
One can use the classes like this:
var writeableInt = new WritableInt();
var readableInt = writeableInt.ReadOnlyInt;
This is how the system works:
The private API (ReadableInt.PrivateApi) gains access to the main object (ReadableInt) private members by being an inner class. No up-casting/down-casting security breaches.
Notice that the ReadableInt.PrivateApi constructor is marked internal, so only ReadableInt can create the instances. I could not find a more elegant way to prevent anyone from creating a ReadableInt.PrivateApi from a ReadableInt object.
In general, ReadableInt needs a reference to the private API consumer to call it (notifications etc.). To decouple the public API from concrete private API consumers, the private API consumer is abstracted as the ReadableInt.IPrivateConsumer interface. ReadableInt receives the reference to a ReadableInt.IPrivateConsumer object through the constructor.
The private API controller object (ReadableInt.PrivateApi) is given to the creator (WriteableInt) via callback (Action<PrivateApi>) passed to the ReadableInt constructor. It's extremely ugly. Can anyone propose another way?
There is a small problem: WritableInt.OnValueChanged() method is private, but is effectively public as it's an interface method. This can be solved with a delegate or a proxy. Is there any other way?
This system works, but has some parts that I'm not proud of. I particularly dislike the initialization stage when all parts are linked together. Can this be simplified somehow?

How I do it
The question is quite interesting. I'm not in any way an expert in OOP (God! I wish I would!), but here is how I do it:
public interface IReadOnlyFoo
{
int SomeValue
{
get;
}
}
public class Foo: IReadOnlyFoo
{
public int SomeValue
{
get;
set;
}
}
public class Bar
{
private Foo foo;
public IReadOnlyFoo Foo
{
get
{
return foo;
}
}
}
It's not very secure, since you can cast IReadOnlyFoo to Foo. But my philosophy here is the following: when you cast, you take all the responsibility on yourself. So, if you shoot yourself in the foot, it's your fault.
How I would do if I were to avoid casting problem
First thing to consider here is that there are value types and reference types.
Value types
For the sake of this answer I would classify value types for pure data types (int, float, bool, etc.) and structures.
Pure data types
It is interesting that you explain your problem using int which is value type. Value types are get copied by assignment. So, you don't need any kind of wrapper or read only reference mechanics for int. This is for sure. Just make a read-only property or property with private/protected setter and that's it. End of story.
Structures
Basically, the same thing. In good designed code, you don't need any wrappers for structs. If you have some reference type values inside struct: I would say that this is a poor design.
Reference types
For reference types your proposed solution looks too complicated. I would do something like this:
public class ReadOnlyFoo
{
private readonly Foo foo;
public ReadOnlyFoo(Foo foo)
{
this.foo = foo;
}
public SomeReferenceType SomeValue
{
get
{
return foo.SomeValue;
}
}
}
public class Foo
{
public int SomeValue
{
get;
set;
}
}
public class Bar
{
private Foo foo;
public readonly ReadOnlyFoo Foo;
public Bar()
{
foo = blablabla;
Foo = new ReadOnlyFoo(foo);
}
}

C# Generics - Mimicking C++ Template Specialization

I've found a nice link on C++ Tenmplates:
http://www.cplusplus.com/doc/tutorial/templates/
and needed something similar in C#. I have a solution that seems to work but wanted opinions of others in how it relates to the above link, specifically the specialization section.
Here is a proof of concept I came up with:
public abstract class Piece
{
public object Value { get; set; }
}
public class Rook : Piece
{
public void Capture()
{
int i = (int)this.Value;
}
}
public class Pawn : Piece
{
public void CaptureEnPassant()
{
string s = (string)this.Value;
}
}
public class PieceFactory<P, T> where P : Piece, new()
{
P p;
public PieceFactory(T value)
{
p = new P();
p.Value = value;
}
public P GetPiece()
{
return p;
}
}
and then finally to call into the factory I do this:
var piece = new PieceFactory<Pawn, string>("exd6").GetPiece();
piece.CaptureEnPassant();
I've seen different solutions like using extension methods and other ways...
Just wanted to see if my way of thinking is along the lines of good patterns.
THanks so much,
David

My opinion is that your sketch is far more complex and confusing than necessary. Why does the base class have a "value" that has different meanings and different types in each derived class? Why is there a factory that takes a type parameter that must be of a particular type argument, and if it is not, then the program crashes at runtime? Get rid of all that brittle, confusing, fragile stuff. If a pawn needs a string, then make a public constructor on Pawn that takes a string, end of story. There's no need for the factory pattern at all here.
Don't be so in love with the tool that you build stuff out of it that doesn't actually make any sense. Generic types are great for things like collection classes. They're not a good fit for the chess domain.

FYI I tried converting my own template-programmed chess engine into C# for fun, and found it was slower by roughly a factor of 20 across the board [sic].
That includes stuff like parsing the gamefile format. Position lookup and move generation just had a lot of mechanical sympathy in the C++ version, that applying all the tricks could not make up for:
compiletime optimization
non-shared generics (mono specific - see here, e.g.)
unsafe code (pinned arrays, raw pointers),
unchecked blocks (as in array bounds/arithmetic overflow
value typed arrays and ref passing
short, inlinable functions
garbage prevention (custom allocation in preallocated 'realms' (just large arrays of structs preallocated)
That said, the performance benefit from using generic collections is significant, esepcially for, say List<T> where T : struct. Note however, the caveats from the link above (especially for the new constraint which has rather pathetic performance on MS. NET due to code sharing; it is basically as slow as using reflection to call the constructor, even for value types).
YMMV, but in the end I'd say
1. Go with the C# way. If you must optimize, do it the C# way
2. If all else fails, resort to P/Invoke (C++/CLR is a sweet spot if you target Windows)

I would just use generics on your base class. Does this break something in your code?
void Main()
{
var factory = new PieceFactory<Rook, int>(20);
factory.GetPiece().Dump();
}
abstract class Piece<TValue>
{
public TValue Value { get; set; }
}
class Rook : Piece<int>
{
public int Capture()
{
// Do something...
return base.Value;
}
}
class Pawn : Piece<string>
{
public string EnPassant()
{
// Do something...
return base.Value;
}
}
class PieceFactory<TKey, TValue> where TKey : Piece<TValue>, new()
{
private readonly TKey piece;
public PieceFactory(TValue value)
{
this.piece = new TKey();
this.piece.Value = value;
}
public TKey GetPiece()
{
return this.piece;
}
}
I have also put some access keywords (like this and base) and a readonly modifier in your factory.

C# class design without using "Internal" or "Static"?

I have a bunch of data I want to instantiate in a class, and for each variable I want to ensure a specific set of methods are also defined. IE:
[TypeA] VarA
[TypeB] VarB
[TypeC] VarC
FA1() which is a function of VarA and VarB
FA2() which is a function of VarA and VarC
FB1() which is a function of VarB and VarA
FB2() which is a function of VarB and VarC
...
As there will be a large number of variables (and hence even more functions) I want to split my source code up into manageable chunks. So I am looking for an automatic way of ensuring that all of the functions for each variable are instantiated.
I have come up with 3 possible methods to organize my code and I am not too happy with each of them and I am looking or advice as to which method is the better (or even if I have missed a completely different implementation method):
1. Partial Class
partial class Base
{
}
partial class Base
{
[TypeA] VarA;
FA1 { .. }; // function of VarA and VarB
FA2 { .. }; // function of VarA and VarC
}
partial class Base
{
[TypeB] VarB;
FB1 { .. }; // function of VarB and VarA
FB2 { .. }; // function of VarB and VarC
}
Pros:
Simple
Variables can only be accessed from within class Base.
If there are two variables of the same type then the functions for each variable can implement its own function differently.
Cons:
Cannot automatically ensure that all functions are created for each variable
Need to manually ensure that there are no name collisions between each function name.
Note that the Cons may be solved by a code generator of some sort (maybe time to learn T4??)
2. Internal class
class Base
{
internal [ClassA] ObjA = new [ClassA]();
internal [ClassB] ObjB = new [ClassB]();
}
class [BaseClassA]
{
public [TypeA] VarA;
public virtual F1 { .. };
public virtual F2 { .. };
}
class [ClassA] : [BassClassA]
{
public override F1 { .. }; // function of VarA and ObjB.VarB
public override F2 { .. }; // function of VarA and ObjC.VarC
}
...
Pros:
Class hierarchy enforces that all functions are created and that variables are there to be accessed.
Through use of virtual functions can create instance specific implementations of functions
Cons:
Use of Internal means that data is visible everywhere in the assembly.
3. Static data
abstract class Data
{
static [TypeA] VarA;
static [TypeB] VarB;
...
}
abstract class [BaseClassA] : Data
{
public virtual F1 { .. };
public virtual F2 { .. };
}
class [ClassA] : [BassClassA]
{
public override F1 { .. }; // function of VarA and VarB
public override F2 { .. }; // function of VarA and VarC
}
class Base
{
[ClassA] ObjA = new [ClassA]();
[ClassB] ObjB = new [ClassB]();
}
Pros:
System ensures that all routines are instantiated
Data is not blasted all around the assembly
Within each function you can directly reference the other variables as per the 'partial class' solution
Cons:
The use of static smells like I have just re-invented global data.
What I want is to somehow cherry pick the best points of each method:
The direct manner of accessing variables of the "Partial class" and "Static" methods
The local data of the "Partial class" method
The automatic enforcing of function implementation of the "Internal" and "Static" methods.
And I want to avoid:
The lack of enforcing function generation in the "Partial class"
The global access of data in the "Internal" method
The re-invention of global data in the "Static" method
If I was going to have my druthers I'd say that what I want is to somehow apply an interface to an instance of a variable - like:
[TypeA] VarA : IFunctions;
[TypeB] VarB : IFunctions;
And somehow have the compiler auto-generate the final function names from the interface names and the vaiable name.
So can people suggest which of the 3 methods they would prefer to implement, or suggest any other methods that may suit.

You present four code samples, the 'simple' version so that you can explain the problem and then 3 'better' solutions to fix the problem. The only version that was self-explanatory was the simple version. So, I'm thinking of the poor developer that has to come in a maintain this next year (which might be you after forgetting what you did).
So, could you consider a different mechanism altogether for "ensuring that all of the functions for each variable are instantiated". You mentioned a willingness to use T4 to auto-generate stubs for you during compile time. What about using Microsoft FxCop to catch any instances where you forgot to add something.
If you're not familiar with it, Microsoft FxCop (also embedded in some flavors of Visual Studio) scans the compiled assemblies and evaluates hundreds of framework rules against your code, from proper spelling and casing of variables to unused locals.
While I personally agree with most of the rules that Microsoft has bundled into FxCop, I think the real beauty of it is the ability to create your own rules. I have created rules that I add to FxCop that enforces CRUD principles, such as if you have a CreateXxx method, you must have a DeleteXxx method etc. So, if you identify a class that matches the pattern you desire, you can get a list of all variables {A, B, C} and then guarantee that FuncAB(A, B) exists and that FuncAC(A, C) exists etc.
Then, even a junior developer would be caught out by FxCop the next time he implements IBiVariableFunction and forgets a function on a pair.
Cheers, Adrian

Your question is largely without any real context and is difficult to understand. You have provided three "answers" without a clear question (imo.)
Frankly, if you want to ensure that each "variable" as you call it has associated methods, you should consider using interfaces, and use properties in the place of fields (since interfaces cannot specify fields.)
interface IAStuff {
TypeA AProp { get; }
void DoSomethingToA();
}
interface IBStuff {
TypeB BProp { get; }
void DoSomethingToB();
}
public class Foo : IAStuff, IBStuff {
TypeA AProp { get; private set; }
TypeB BProp { get; private set; }
void DoSomethingToA() { ... }
void DoSomethingToB() { ... }
}
If the class declares that it implements an interface, it has no choice but to provide the specified members or it will not compile.
Hope this helps,
-Oisin

Could you not use suggestion 2 but with protected instead of internal?

C# virtual static method

Why is static virtual impossible? Is C# dependent or just don't have any sense in the OO world?
I know the concept has already been underlined but I did not find a simple answer to the previous question.

virtual means the method called will be chosen at run-time, depending on the dynamic type of the object. static means no object is necessary to call the method.
How do you propose to do both in the same method?

Eric Lippert has a blog post about this, and as usual with his posts, he covers the subject in great depth:
https://learn.microsoft.com/en-us/archive/blogs/ericlippert/calling-static-methods-on-type-parameters-is-illegal-part-one
“virtual” and “static” are opposites! “virtual” means “determine the method to be called based on run time type information”, and “static” means “determine the method to be called solely based on compile time static analysis”

The contradiction between "static" and "virtual" is only a C# problem. If "static" were replaced by "class level", like in many other languages, no one would be blindfolded.
Too bad the choice of words made C# crippled in this respect. It is still possible to call the Type.InvokeMember method to simulate a call to a class level, virtual method. You just have to pass the method name as a string. No compile time check, no strong typing and no control that subclasses implement the method.
Some Delphi beauty:
type
TFormClass = class of TForm;
var
formClass: TFormClass;
myForm: TForm;
begin
...
formClass = GetAnyFormClassYouWouldLike;
myForm = formClass.Create(nil);
myForm.Show;
end

Guys who say that there is no sense in static virtual methods - if you don't understand how this could be possible, it does not mean that it is impossible. There are languages that allow this!! Look at Delphi, for example.

I'm going to be the one who naysays. What you are describing is not technically part of the language. Sorry. But it is possible to simulate it within the language.
Let's consider what you're asking for - you want a collection of methods that aren't attached to any particular object that can all be easily callable and replaceable at run time or compile time.
To me that sounds like what you really want is a singleton object with delegated methods.
Let's put together an example:
public interface ICurrencyWriter {
string Write(int i);
string Write(float f);
}
public class DelegatedCurrencyWriter : ICurrencyWriter {
public DelegatedCurrencyWriter()
{
IntWriter = i => i.ToString();
FloatWriter = f => f.ToString();
}
public string Write(int i) { return IntWriter(i); }
public string Write(float f) { return FloatWriter(f); }
public Func<int, string> IntWriter { get; set; }
public Func<float, string> FloatWriter { get; set; }
}
public class SingletonCurrencyWriter {
public static DelegatedCurrencyWriter Writer {
get {
if (_writer == null)
_writer = new DelegatedCurrencyWriter();
return _writer;
}
}
}
in use:
Console.WriteLine(SingletonCurrencyWriter.Writer.Write(400.0f); // 400.0
SingletonCurrencyWriter.Writer.FloatWriter = f => String.Format("{0} bucks and {1} little pennies.", (int)f, (int)(f * 100));
Console.WriteLine(SingletonCurrencyWriter.Writer.Write(400.0f); // 400 bucks and 0 little pennies
Given all this, we now have a singleton class that writes out currency values and I can change the behavior of it. I've basically defined the behavior convention at compile time and can now change the behavior at either compile time (in the constructor) or run time, which is, I believe the effect you're trying to get. If you want inheritance of behavior, you can do that to by implementing back chaining (ie, have the new method call the previous one).
That said, I don't especially recommend the example code above. For one, it isn't thread safe and there really isn't a lot in place to keep life sane. Global dependence on this kind of structure means global instability. This is one of the many ways that changeable behavior was implemented in the dim dark days of C: structs of function pointers, and in this case a single global struct.

Yes it is possible.
The most wanted use case for that is to have factories which can be "overriden"
In order to do this, you will have to rely on generic type parameters using the F-bounded polymorphism.
Example 1
Let's take a factory example:
class A: { public static A Create(int number) { return ... ;} }
class B: A { /* How to override the static Create method to return B? */}
You also want createB to be accessible and returning B objects in the B class. Or you might like A's static functions to be a library that should be extensible by B. Solution:
class A<T> where T: A<T> { public static T Create(int number) { return ...; } }
class B: A<B> { /* no create function */ }
B theb = B.Create(2); // Perfectly fine.
A thea = A.Create(0); // Here as well
Example 2 (advanced):
Let's define a static function to multiply matrices of values.
public abstract class Value<T> where T : Value<T> {
//This method is static but by subclassing T we can use virtual methods.
public static Matrix<T> MultiplyMatrix(Matrix<T> m1, Matrix<T> m2) {
return // Code to multiply two matrices using add and multiply;
}
public abstract T multiply(T other);
public abstract T add(T other);
public abstract T opposed();
public T minus(T other) {
return this.add(other.opposed());
}
}
// Abstract override
public abstract class Number<T> : Value<T> where T: Number<T> {
protected double real;
/// Note: The use of MultiplyMatrix returns a Matrix of Number here.
public Matrix<T> timesVector(List<T> vector) {
return MultiplyMatrix(new Matrix<T>() {this as T}, new Matrix<T>(vector));
}
}
public class ComplexNumber : Number<ComplexNumber> {
protected double imag;
/// Note: The use of MultiplyMatrix returns a Matrix of ComplexNumber here.
}
Now you can also use the static MultiplyMatrix method to return a matrix of complex numbers directly from ComplexNumber
Matrix<ComplexNumber> result = ComplexNumber.MultiplyMatrix(matrix1, matrix2);

While technically it's not possible to define a static virtual method, for all the reasons already pointed out here, you can functionally accomplish what I think you're trying using C# extension methods.
From Microsoft Docs:
Extension methods enable you to "add" methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type.
Check out Extension Methods (C# Programming Guide) for more details.

In .NET, virtual method dispatch is (roughly) done by looking at the actual type of an object when the method is called at runtime, and finding the most overriding method from the class's vtable. When calling on a static class, there is no object instance to check, and so no vtable to do the lookup on.

To summarize all the options presented:
This is not a part of C# because in it, static means "not bound to anything at runtime" as it has ever since C (and maybe earlier). static entities are bound to the declaring type (thus are able to access its other static entities), but only at compile time.
This is possible in other languages where a static equivalent (if needed at all) means "bound to a type object at runtime" instead. Examples include Delphi, Python, PHP.
This can be emulated in a number of ways which can be classified as:
Use runtime binding
Static methods with a singleton object or lookalike
Virtual method that returns the same for all instances
Redefined in a derived type to return a different result (constant or derived from static members of the redefining type)
Retrieves the type object from the instance
Use compile-time binding
Use a template that modifies the code for each derived type to access the same-named entities of that type, e.g. with the CRTP

The 2022+ answer, if you are running .Net 7 or above, is that now static virtual members is now supported in interfaces. Technically it's static abstract instead of "static virtual" but the effect is that same. Standard static methods signatures can be defined in an interface and implemented statically.
Here are a few examples on the usage and syntax in .Net 7

Use C++ CLI template class in C#

I have the following class in C++/CLI and an explicit template instantiation for the int primitive..
template<typename T>
public ref class Number
{
T _value;
public:
static property T MinValue
{
T get()
{
return T::MinValue;
}
}
static property T MaxValue
{
T get()
{
return T::MaxValue;
}
}
property T Value
{
T get()
{
return _value;
}
void set(T value)
{
if( value<MinValue || value > MaxValue)
throw gcnew System::ArgumentException("Value out of range");
_value = value;
}
}
};
template ref class Number<int>;
On compiling this and inspecting the generated assembly using reflector I am able to see a class called Number<int> but while trying to instantiate this same class in C# the compiler complains about some System::Number class not taking a template argument. What am I doing wrong? Can this be done at all?

I have a work around, declare an additional class inheriting the Number<int> class. This class is now visible in C# and can be instantiated.
public ref class MyInt32 : public Number<int>
{
};

Reflector is lying a little bit here. The name of the class is not actually Number<int>. It is actually 'Number<int>'. Notice the single quotes. These are only visible when you view the type name with ildasm.
I believe this is done to make the type unbindable in most languages as they have no way of understanding how a C++ template actually works. This makes it effectively only visible to the C++ compiler which is appropriate since it's the only MS compiler that actually supports templates (templates != generics).

If your goal is to create a parametrized type in C++ CLI, and then use that type from C#, I think that you need to create a generic type rather than a template type (see Stan Lippman's Blog for the reasons why both methods exist). See here for information on how to create generic types in C++ CLI.