I have a POstSHarp attribute implementing OnMethodBoundaryAspect. The mark up is as follows:
[ExceptionLogging("RepositoryLayer")]
What I want to do within the implementation of the aspect is access the string that was passed with the attribute markup above. The idea is that based on this value I can see (in a very rudimnentary manner) where the aspect is being called in the architecture, in this case in the Repository Layer.
How do I get access to this value with the aspect implementation? I cannot find it anywhere in the EVentArgs or anywhere else.
Many thanks
Brian
The constructor should store the string in an instance field of the aspect class; then you can access the instance field from the OnException method.
Related
Basically, I want a function that goes through the drawing and searchs for attribute definition text, I can do it normally, but if I make a block with said attribute text the function can't find them anymore. I don't know if it's even possible to do it.
To achieve your task, you'll want to look at the value (Textstring property) of the attribute references, as opposed to the attribute definitions.
Attribute references are held by the block reference and their values may vary between multiple references of the same block, whereas attribute definitions reside within the single block definition (i.e. the blueprint for the block) and hold an optional default value.
The attribute references may be accessed either through Vanilla AutoLISP using the entnext function to iterate over the attribute reference subentities which follow a block reference entity in the drawing database (example), or through Visual LISP by invoking the ActiveX getattributes method (example).
My existing Count Attribute Values program should provide some insight into how to accomplish this - you'll only need to differentiate the references by block name in addition to attribute value.
I am from a C# background and have been doing programming for quite some time now. But only recently i started giving some thoughts on how i program. Apparently, my OOP is very bad.
I have a few questions maybe someone can help me out. They are basic but i want to confirm.
1- In C#, we can declare class properties like
private int _test;
and there setter getters like
public int Test {get; set;}
Now, lets say i have to use this property inside the class. Which one will i use ? the private one or the public one ? or they both are the same ?
2- Lets say that i have to implement a class that does XML Parsing. There can be different things that we can use as input for the class like "FILE PATH". Should i make this a class PROPERTY or should i just pass it as an argument to a public function in the class ? Which approach is better. Check the following
I can create a class property and use like this
public string FilePath {get; set;}
public int Parse()
{
var document = XDocument.Load(this.FilePath);
.........//Remaining code
}
Or
I can pass the filepath as a parameter
public int Parse(string filePath)
On what basis should i make a decision that i should make a property or i should pass something as argument ?
I know the solutions of these questions but i want to know the correct approach. If you can recommend some video lectures or books that will be nice also.
Fields vs Properties
Seems like you've got a few terms confused.
private int _test;
This is an instance field (also called member).
This field will allow direct access to the value from inside the class.
Note that I said "inside the class". Because it is private, it is not accessible from outside the class. This is important to preserve encapsulation, a cornerstone of OOP. Encapsulation basically tells us that instance members can't be accessed directly outside the class.
For this reason we make the member private and provide methods that "set" and "get" the variable (at least: in Java this is the way). These methods are exposed to the outside world and force whoever is using your class to go trough your methods instead of accessing your variable directly.
It should be noted that you also want to use your methods/properties when you're inside the current class. Each time you don't, you risk bypassing validation rules. Play it safe and always use the methods instead of the backing field.
The netto result from this is that you can force your logic to be applied to changes (set) or retrieval (get). The best example is validation: by forcing people to use your method, your validation logic will be applied before (possibly) setting a field to a new value.
public int Test {get; set;}
This is an automatically implemented property. A property is crudely spoken an easier way of using get/set methods.
Behind the scenes, your code translates to
private int _somevariableyoudontknow;
public void setTest(int t){
this._somevariableyoudontknow = t;
}
public int getTest(){
return this._somevariableyoudontknow;
}
So it is really very much alike to getters and setters. What's so nice about properties is that you can define on one line the things you'd do in 7 lines, while still maintaining all the possibilities from explicit getters and setters.
Where is my validation logic, you ask?
In order to add validation logic, you have to create a custom implemented property.
The syntax looks like this:
private int _iChoseThisName;
public int Test {
get {
return _iChoseThisName;
}
set {
if(value > 5) { return _iChoseThisName; }
throw new ArgumentException("Value must be over 5!");
}
}
Basically all we did was provide an implementation for your get and set. Notice the value keyword!
Properties can be used as such:
var result = SomeClass.Test; // returns the value from the 'Test' property
SomeClass.Test = 10; // sets the value of the 'Test' property
Last small note: just because you have a property named Test, does not mean the backing variable is named test or _test. The compiler will generate a variablename for you that serves as the backing field in a manner that you will never have duplication.
XML Parsing
If you want your second answer answered, you're going to have to show how your current architecture looks.
It shouldn't be necessary though: it makes most sense to pass it as a parameter with your constructor. You should just create a new XmlParser (random name) object for each file you want to parse. Once you're parsing, you don't want to change the file location.
If you do want this: create a method that does the parsing and let it take the filename as a parameter, that way you still keep it in one call.
You don't want to create a property for the simple reason that you might forget to both set the property and call the parse method.
There are really two questions wrapped in your first question.
1) Should I use getters and setters (Accessors and Mutators) to access a member variable.
The answer depends on whether the implementation of the variable is likely to change. In some cases, the interface type (the type returned by the getter, and set by the setter) needs to be kept consistent but the underlying mechanism for storing the data may change. For instance, the type of the property may be a String but in fact the data is stored in a portion of a much larger String and the getter extracts that portion of the String and returns it to the user.
2) What visibility should I give a property?
Visibility is entirely dependent on use. If the property needs to be accessible to other classes or to classes that inherit from the base class then the property needs to be public or protected.
I never expose implementation to external concerns. Which is to say I always put a getter and setter on public and protected data because it helps me ensure that I will keep the interface the same even if the underlying implementation changes. Another common issue with external changes is that I want a chance to intercept an outside user's attempt to modify a property, maybe to prevent it, but more likely to keep the objects state in a good or safe state. This is especially important for cached values that may be exposed as properties. Think of a property that sums the contents of an array of values. You don't want to recalculate the value every time it is referenced so you need to be certain that the setter for the elements in the array tells the object that the sum needs to be recalculated. This way you keep the calculation to a minimum.
I think the second question is: When do I make a value that I could pass in to a constructor public?
It depends on what the value is used for. I generally think that there are two distinct types of variables passed in to constructors. Those that assist in the creation of the object (your XML file path is a good example of this) and those that are passed in because the object is going to be responsible for their management. An example of this is in collections which you can often initialize the collection with an array.
I follow these guidelines.
If the value passed in can be changed without damaging the state of the object then it can be made into a property and publicly visible.
If changing the value passed in will damage the state of the object or redefine its identity then it should be left to the constructor to initialize the state and not be accesible again through property methods.
A lot of these terms are confusing because of the many different paradigms and languages in OO Design. The best place to learn about good practices in OO Design is to start with a good book on Patterns. While the so-called Gang of Four Book http://en.wikipedia.org/wiki/Design_Patterns was the standard for many years, there have since been many better books written.
Here are a couple resources on Design Patterns:
http://sourcemaking.com/design_patterns
http://www.oodesign.com/
And a couple on C# specific.
http://msdn.microsoft.com/en-us/magazine/cc301852.aspx
http://www.codeproject.com/Articles/572738/Building-an-application-using-design-patterns-and
I can possibly answer your first question. You asked "I have to use this property inside the class." That sounds to me like you need to use your private variable. The public method which you provided I believe will only do two things: Allow a client to set one of your private variables, or to allow a client to "see" (get) the private variable. But if you want to "use this property inside the class", the private variable is the one that should be your focus while working with the data within the class. Happy holidays :)
The following is my personal opinion based on my personal experience in various programming languages. I do not think that best practices are necessarily static for all projects.
When to use getters, when to use private instance variables directly
it depends.
You probably know that, but let's talk about why we usually want getters and setters instead of public instance variables: it allows us to aquire the full power of OOP.
While an instance variable is just some dump piece of memory (the amount of dumbness surely depends on the language you're working in), a getter is not bound to a specific memory location. The getter allows childs in the OOP hirarchy to override the behaviour of the "instance variable" without being bound to it. Thus, if you have an interface with various implementations, some may use ab instance variable, while others may use IO to fetch data from the network, calculate it from other values, etc.
Thus, getters do not necessarily return the instance variable (in some languages this is more complicated, such as c++ with the virtual keyword, but I'll try to be language-independent here).
Why is that related to the inner class behaviour? If you have a class with a non-final getter, the getter and the inner variable may return different values. Thus, if you need to be sure it is the inner value, use it directly. If you, however, rely on the "real" value, always use the getter.
If the getter is final or the language enforces the getter to be equal (and this case is way more common than the first case), I personally prefer accessing the private field directly; this makes code easy to read (imho) and does not yield any performance penalty (does not apply to all languages).
When to use parameters, when to use instance variables/properties
use parameters whereever possible.
Never use instance variables or properties as parameters. A method should be as self-contained as possible. In the example you stated, the parameterized version is way better imo.
Intance variables (with getters or not) are properties of the instance. As they are part of the instance, they should be logically bound to it.
Have a look at your example. If you hear the word XMLParser, what do you think about it? Do you think that a parser can only parse a single file it is bound to? Or do you think that a parser can parse any files? I tend to the last one (additionally, using an instance variable would additionally kill thread-safety).
Another example: You wish to create an XMLArchiver, taking multiple xml documents into a single archive. When implementing, you'd have the filename as a parameter of the constructor maybe opening an outputstream towards the file and storing a reference to it as an instance variable. Then, you'd call archiver.add(stuff-to-add) multiple times. As you see, the file (thus, the filename) is naturally bound to the XMLArchiver instance, not to the method adding files to it.
How can one obtain a default deserialized object in a custom Jackson deserializer?
I have an object which contains some fields which are not to be serialized, but which I wish to always be populated upon deserialization. In other words, a post-deserialize step.
I have created my own deserializer and annotated the class with a corresponding #JsonDeserialize, but I don't want to deserialize each field in the domain object by hand. Is there a way to get the regular deserialized object so I can just populate my custom fields? (Or else, just register a post-deserialization processor on a bean)
I have seen the answer to this question which hints at an answer, but I'm sufficiently unaware of the Jackson API to determine how best to actually effect this.
This can be achieved by using a BeanSerializerModifier and extending BeanSerializerBase, as per #ryanp's answer to this question.
I am having the following problem:
I obtain an object from an external component and what I'd like to do is override several of the object's functions in order to change parts of its behavior.
I tried doing this via a decorator by inheriting from the original object's class and storing the original object as a member variable, but then I would have to override all the functions in that object.
I also don't have access to most of the object's internal data, so I cannot just clone it into my derived object's base class.
So bottom line is: is there anyway to override a couple of an already instantiated object's functions while retaining the data and not having to override the entire object functionality?
Thanks,
PM
The short answer is, No.
The longer answer is to write a wrapper around it and yes that means implementing all the methods. YOu can do this via composition.
.Net isn't a dynamic language although it has some dynamic feature but I don't think you component will be dynamic.
Can you not inherit the object its self and then just add your methods to it?
If this isn't possible I'd store the component in a variable and then replicate all of the components methods. Not the nicest of the solutions but it would work, I just hope the component doesn't have to many methods.
Finally have you tried if your license agreement allows it using something like reflector on it, might show up a possible solution.
What are setters and getters? Why do I need them? What is a good example of them in use in an effective way? What is the point of a setter and getter?
Update:
Can I get some coding examples please?
A getter is a method that gets the value of a property. A setter is a method that sets the value of a property. There is some contention about their efficacy, but the points are generally:
for completeness of encapsulation
to maintain a consistent interface in case internal details change
More useful is when you need to add some logic around getting or setting, like validating a value before you write it.
A getter/setter is used to hide a private field from the publicity (you can avoid direct access to a field).
The getter allows you to check a provided value before you use it in your internal field. The setter allows you for instance to apply a different format or just to restrict write access (e.g. to derived classes).
A useful application of a getter can be some kind of lazy loading: The backing field (the private field that is hidden by the getter) is initialized to null. When you ask the getter to return the value, it will check for null and load the value with a more time consuming method. This will happen only the first call, later the getter will provide the already loaded value all the time.
Getters & setters separate interface (getter/setter functions) from implementation (how the data is actually stored).
Getters and Setters allow you to control how data members of an object can be accessed or changed.
In contrast, if you expose your data members directly to the user of the object, the user can change them at will, and the object wouldn't even know that they had been changed.
Don't want people to read a data member? Make the data member private, and don't write a getter that gives the value back. Don't want people to modify a data member? Make the data member private, and don't write a setter for it. Want to control the range of allowed values? Put that in the setter.
One question which might pop out of this is if using a method instead of a direct field access might decrease performance.
Answer is not really as compilers optimize code so that if your method is only doing return field;, where field is the field in your class that you hide with the setter/getter, it will actually access the field directly. Thus you get in most cases the same performance, at the same time keeping the option of later on change what set/get methods do.
Effective Java Programming of Joshua Block is a great book with tips on how to write good code, and explains why as well. Why using setter/getter is one of the hints.
Note: You might notice that in some books/documentation fields that present a setter/getter instead of being directly accessible are called 'properties' instead of fields. E.g. in C#, you can even specify that a field is a property and you don't need to define set/get anymore (nice feature I think).
public accessors(getter and setter) make sometimes sense.
(I'm annoyed that I have not only to document the member variable of a class but also the 2 mostly meaningless accessor methods. )
It usually doesn't help with encapsulation except in cases mentioned by Jason S.
An java example for some char loaded from a database but should be represented as a boolean value
char boolFromDb;
public boolean getBoolFromDb() {
return boolFromDb == 'T';
}
public void setBoolFromDb(boolean newValue) {
boolFromDb = newValue ? 'T' : 'F';
}