Exposing properties through an interface

[ajaxx]

I'm doing some class modelling for objects that will be implemented in C#.  I like to do a lot of my abstract modelling through interfaces before providing concrete classes that implement them... nothing new there.

However, I can't seem figure out how you would model a property that is exposed by an interface and realized by an implementation.

For that matter, how could I do that with a class that is marked with the interface stereotype.  It appears that properties are exposed when an attribute is marked with a property flag.

Thanks for you help.

[Paolo F Cantoni]

I'm doing some class modelling for objects that will be implemented in C#.  I like to do a lot of my abstract modelling through interfaces before providing concrete classes that implement them... nothing new there.

However, I can't seem figure out how you would model a property that is exposed by an interface and realized by an implementation.

For that matter, how could I do that with a class that is marked with the interface stereotype.  It appears that properties are exposed when an attribute is marked with a property flag.

Thanks for you help.

Ajaxx,
you post is quite timely.

Today I spent some time implementing Inheritance in an object based language that has no native support for it.  (SAX Basic used by Embarcadero ER/Studio).  I used SAX Basic Properties (Property Get X, Property Let/Set X etc) to simulate the inheritance.
Fighting the compiler got me thinking about the problem of Properties in languages and UML models.

Here is an extract from my naming standards document:

[size=13]1.5.5
Properties[/size]
Properties are the public interface to either protected or private class member variables¹³ .  Since (by definition) they are local to the class, scoping is not required.  Also, since they are a public interface, they fall under section 1.4 Interface elements (above).  Accordingly, Properties are Pascal Cased.  NOTE: where the Property is a simple getter and setter of a member, then the member may be adorned as though they were the property.

¹³  While this is the intent, here is actually NO requirement that the private member variable be referenced at all!  For example, one can use Properties to create derived values.  Technically, properties are just methods with specific signatures.  Due to language restrictions on the notional member variable, there can be (at most) two methods with this name, one is parameterless (the getter) and the other has an implied or actual (depending on the language) parameter of the specified type (the setter).

I think your best bet is to create methods with appropriate name and signature and stereotype them «property».  You can then adjust the CTF templates to emit the appropriate code.

BTW, don't use the property flag in the Attribute since as you've seen from the above, it's actually quite spurious...

In C# I might (and have written)

   private bool mbEATypeIsElement;
   public bool EATypeIsElement
   {
       get
       {
           return mbEATypeIsElement;
       }
       set
       {
           mbEATypeIsElement = value;
       }
   }//property

Which would be defined in the model as:

«property» EATypeIsElement()      (The getter)
«property» EATypeIsElement(value)      (The setter)

But as I said above... Why bother?  Why not just write:
   public bool EATypeIsElement;

In my view (as of today), you should ONLY create a formal property when you either need to inhibit one of the getter or setter, or the one of the two does more than a simple assignment.  By having a specific naming standard for Properties and naming a simple variable as to that standard, you can change your mind later if you need to - with essentially no loss of generality!

HTH,
Paolo

[TrtnJohn]

I have a somewhat opposite view of properties than you Paolo.  Why such a resitance to using them?  I encouraged developers to add properties whenever exposing data from one class to another.  Some programming laguages require that you do this.  To me it is more consistent than using Public attributes in some cases and properties in others.  One of the reasons I discourage making attributes public is because it is too easy for programmers to just decide to quickly change an attribute to public to solve an issue on the fly.

[Paolo F Cantoni]

I have a somewhat opposite view of properties than you Paolo.  Why such a resistance to using them?  I encouraged developers to add properties whenever exposing data from one class to another.  Some programming languages require that you do this.  To me it is more consistent than using Public attributes in some cases and properties in others.  One of the reasons I discourage making attributes public is because it is too easy for programmers to just decide to quickly change an attribute to public to solve an issue on the fly.

Sorry Ajaxx,

I didn't make myself clear enough.  (You'll have to excuse me it was very late at night after a long day fighting SAX Basic).  I'm not against Properties.  They are great!  The point I was trying (unsuccessfully) to make was:

IF (and it's probably a big if) ALL you are doing is a simple set and get of a private variable, then just create a Public variable - but whose adornment is that of a Property.

I've only recently started programming in C#.  Two Weeks ago I would have "laid out" a simple Property as:


   private bool mbEATypeIsElement;
   public bool EATypeIsElement
   {
       get
       {
           return mbEATypeIsElement;
       }
       set
       {
           mbEATypeIsElement = value;
       }
   }//property

Two days ago, I started doing:


   private bool mbEATypeIsElement;
   public bool EATypeIsElement    {        get   {   return EATypeIsElement;        }        set        {    mbEATypeIsElement = value;        }    

Now, it's a bit more obvious that mbEATypeIsElement is adding no value.

So yesterday I decided...

   public bool EATypeIsElement;

Now as it turns out, in .NET there are useful consequences of this.  The C# compiler can do certain optimisations which is can't do if EATypeIsElement is a real property.

So, in summary, I'm certainly not against Properties.  I'm just saying that there's not much point in having two things do the job of one, in the simple case.

However, if you make the variable LOOK like a property, then you can replace the variable with a property later, and the rest of your code doesn't know the difference  

Paolo