Creating a read-only property

[Michael McMullin]

Hi, this is my first post, very new to EA and UML, but love it so far!

I'm putting a class diagram together, and I've hit a wall. My target language is C#, and I'm creating a class that is derived from one of the existing System classes. I've imported the appropriate binary module, and created the derived class... so far so good.

One of the base class properties is protected, but I'd like to create a public read-only property in the derived class that returns its value. This is what I've tried so far:

Attempt #1: Created an attribute and checked the 'Property' box. Filled in the appropriate details. However, it creates a new attribute with the same name as the attribute in the base class, which obviously won't compile without manually removing it from the generated code.

Attempt #2: Instead of creating an attribute, I created an operation, and gave it a stereotype of 'property'. However, I can't figure out how to restrict it to read-only, and the resulting code looks like this:

Code: [Select]

public IList Regions{

get{


return <unknown>;

}

set{


<unknown> = value;

}
}

The <unknown> text should obviously be the value from the base class. I've probably overlooked something obvious from the manual, but if anyone can point me in the right direction, I'd really appreciate it!

[«Midnight»]

Welcome Michael,

Don't panic, you're almost there.

You had it right on Attempt #1, but were missing the 'magic' ingredient.

Open the Options dialog - use Tools | Options or control-F9, then choose the Source Code Engineering page. Do not go to the C# page for this, since you want to set a general option.

Near the bottom you will see the heading Remove prefixes when generating Get/Set properties. This is a semicolon-separated list. (AFAIK) Case is significant here, at least as far as C# is concerned. Make sure the prefix you use is in the list - or use one from the list later in this process if you want - and set the nearby check boxes as you prefer.

Now make sure your private attribute has an appropriate prefix, and repeat Attempt #1. You will notice that the proposed property name is now different (and derived from the attribute name). You can now uncheck the Write box, and the property will be created.

For example, in class Foo you can have a private attribute mFoobar. The dialog will create a public (or whatever you set) read-only property named Foobar.

Voila!

David

PS: The options on the above dialog are 'sticky' and will be the default in future EA sessions until you change them again.

[Michael McMullin]

Hi David,

Thanks for the reply, your advice actually helped with another problem I was having!

In this case, however, I might be missing something. You see, the private attribute is part of an existing System class, so unfortunately, I have no control over how it is named.

Specifically, there is a class called MasterPage that contains a protected property called ContentPlaceHolders.

There is another class called Page that contains a property called Master (of type MasterPage). I need to be able to read the value of Master.ContentPlaceHolders, so I figured I'd create a class (say, MyMasterPage) which is derived from MasterPage, but contains a public property that returns the value of ContentPlaceHolders.

It's actually quite easy to code by hand:

Code: [Select]

public class MyMasterPage : MasterPage{
 public IList MyContentPlaceHolders{
   get { return ContentPlaceHolders; } // from base class
 }
}

I'm just not sure how to represent this in EA. The closest I get is something like:

Code: [Select]

public class MyMasterPage : MasterPage{
 protected IList ContentPlaceHolders; // ERROR -- ContentPlaceHolders already exists in MasterPage.

 public IList MyContentPlaceHolders{
   get { return ContentPlaceHolders; } // from base class
 }
}

[Michael McMullin]

As an update, I just tried something else:

First, I left out the public property and generated the C# code. The result was:

Code: [Select]

...
public class MyMasterPage : MasterPage {
 public MyMasterPage(){
 }

 ~MyMasterPage(){
 }
}//end MyMasterPage...

Next, I manually added the appropriate property to the code file:

Code: [Select]

...
public class MyMasterPage : MasterPage {
 public MyMasterPage(){
 }

 ~MyMasterPage(){
 }

 public IList MyContentPlaceHolders{
   get{
     return ContentPlaceHolders;
   }
 }
}//end MyMasterPage...

Then I went back to the model and synchronized it with the code. The property now appeared in the class diagram without the base protected property showing, which is what I'm looking for.

However, when I generate the code from this new model, EA seems to have changed it:

Code: [Select]

...
public class MyMasterPage : MasterPage {
 public MyMasterPage(){
 }

 ~MyMasterPage(){
 }

 public IList MyContentPlaceHolders{
   get{
     return <unknown>;
   }
 }
}//end MyMasterPage...

...That <unknown> text is back!

[Michael McMullin]

A-ha! When I synchronized the model with the code previously, I was deleting the source file afterwards and re-generating it. If I don't delete it, EA retains the manual changes.

Amazing how obvious things become after a good night's sleep...

Is this the most appropriate way of getting what I'm looking for? I can live with it, but I'd like to be sure it's good practice.

[«Midnight»]

Hi Michael,

That's  progress, but somehow it seems like far too much work to get the desired result.

I need to study this a bit, but I still think this can be made to work the first time through.

David

[«Midnight»]

Michael,

Code: [Select]

public class MyMasterPage : MasterPage{
 protected IList ContentPlaceHolders; // ERROR -- ContentPlaceHolders already exists in MasterPage.

 public IList MyContentPlaceHolders{
   get { return ContentPlaceHolders; } // from base class
 }
}
I think you've done it the wrong way around. Assuming that the prefix "My" is in the list I mentioned above, you want the attribute to have the prefix. Thus, you want to declare:

protected IList MyContentPlaceHolders;

When you set the attribute in EA, it will strip the prefix, and generate (assuming you clear the Read box):

public IList ContentPlaceHolders{
   get { return MyContentPlaceHolders; }
}

David

[Michael McMullin]

Hi David,

Yes, it does seem like a clumsy way of getting the desired result!

Unfortunately, in this case, I cannot rename the attribute as it already exists in the base class. So, I'm trying to create a property in EA that returns the value of an attribute in the base class, without re-creating the original attribute in the derived class. I've called the property MyContentPlaceHolders for now, but the name can be anything other than ContentPlaceHolders really, otherwise it will conflict with the base attribute name.

I've come up with another way, see what you think. I've created an operation called MyContentPlaceHolders, and set the stereotype to property. In the Behavior tab, I added the initial code:

get { return ContentPlaceHolders; }

That seems to generate the correct code that I need.

Thanks a million for your input on this one so far, I really appreciate it!

[«Midnight»]

Good stuff Michael,

BTW, if you were not trying to generate your subclass, but were coding it by hand, how would you go about naming things? It strikes me that this might be less of a problem with EA (or any other tool) than a design issue.

I don't know offhand how EA handles "Shadows" clauses and such, or other scenarios where this kind of naming conflict comes up. It might be worth looking into this (for me if not for you).

David

[Michael McMullin]

In this case, the base class and attribute were named by Microsoft, and I just prefixed the subclass and property with 'My' for testing purposes. However, I do recognize that I've become a little lazy about naming conventions of late, and using EA has certainly helped to focus my attention a lot more.

For private attributes, I use camel case, and for public properties and classes, I use pascal case. I don't usually use prefixes (except an 'I' for interfaces), but the different cases seem to work ok for me. Maybe I should give this a little more thought though.

BTW, I'm not familiar with the term 'Shadows' clauses -- is that the correct name for the scenario I've been describing? For now, I have enough information to proceed, but I'll certainly look into it a bit more.