I want to know how C# collections are represented in memory? Are they represented as linked list or an array.In my project I have to make extensive use of list and performance is critical, so shall I create custom generic Linked List(with some additional features) or shall I use generic List class. Any help will be highly appericiated.
Use Reflection (or ILSpy, etc) to view internal realization of c# collections
Related
I've seen the usage of gosu enhancements a lot within Guidewire application. However, it seems to me it is being overused. Like the following examples:
An entity querying another entity (i.e. looks to me an entity modeling problem).
An entity calling a webservice (i.e. its beyond the purpose of the entity).
Are there any recommended use cases when to use enhancements?
Yes, Enhancements are supposed to be used only for straight forward calculations which the business does not want to store in Database tables.
Instead of using the enhancements, I think its better to have a helper Gosu class Where we shall execute the complex queries and some logical calculations.
The recommended approach is that enhancements should be used to extend existing classes with new methods or properties closely related to the original class object.
I agree that enhancements seem to be overused, that is probably because its the easy way to add some logic in existing (OOTB) parts of the Guidewire system.
Your observations are totally valid. Enhancements should preferably be used for simple calculations where a permanent data model change is not required. Webservice calls and complex queries are recipes for performance issues when used inside an enhancement.
Enhancements can be used for standard getter/setter operations that could be obtained in a relatively straightforward calculation.
What is the best way to represent a "mixin" using UML?
As documented in this article:
In object-oriented programming languages, a mixin refers to a defined
amount of functionality which can be added to a class. An important
aspect of this is that it makes it possible to concentrate more on the
properties of a particular behaviour than on the inheritance
structures during development.
I will give more details about my particular use case.
I have a collection of classes that model different types of objects. Because all of them can be stored on a storage, I want to use a mixin to implement all the functionality related to "being stored".
Of course, I can use abstract classes but I do not like it because these classes should be part of a different hierarchy of classes and the fact that they can be stored is only a secondary property.
Another option can be to use composition and add the "storage node" as a field of this classes. I do not like this option either for the same reason: I do not want to create any dependency between the classes and the storage.
I have already implemented the solution in Java using a mixin based on dynamic proxies and I would like to document the solution with a clear UML class diagram. Is there a standard way to represent this mixin?
I am also wondering whether it is a good idea to model also how the mixin has been implemented (using proxies) or it is better to use a more abstract representation.
Thanks
Actually there are many ways to model this in UML:
One approach could be to stereotype the operations and properties with <<mixin>> or the like and then use tagged values to describe where you got them from.
Another (I'd prefer) is to actually use a <<mixin>> stereotyped Generalization and attach a note to that telling which operations/properties should be mixed. That would give the implementer a guide to just "lean implementation of the general class".
Eventually you could create <<mixin>> sub-classes with subsets of the ops/props you want to mix in the final class and then Generalize from those.
Probably one could come up with more solutions. Use an approach which suits you best. There is not generic mixin pattern in UML (to my knowledge).
From Apple's Core Data Programming Guide:
Core Data dynamically generates efficient public and primitive get and
set attribute accessor methods and relationship accessor methods for
managed object classes.
...
Primitive accessor methods are similar to "normal" or public key-value
coding compliant accessor methods, except that Core Data uses them as
the most basic data methods to access data, consequently they do not
issue key-value access or observing notifications. Put another way,
they are to primitiveValueForKey: and setPrimitiveValue:forKey: what
public accessor methods are to valueForKey: and setValue:forKey:.
I would then expect the primitive accessor methods to be better performant then the public accessors because they do not trigger KVO notifications. Is there a way to effectively test this theory with Time Profiler? (Surely it can't be as easy as putting the two call in their own for-loops that iterate a zillion times and compare the results...)
Obviously the primitive accessors aren't to be called by objects or functions outside of the Managed Object subclass, but when shouldn't you use them from within the class?
edelaney05,
As you appear to know, Core Data depends upon the KVC/KVO features of Objective-C. Yes, you are correct that the path length is slightly longer through the accessors. What of it? Performance of Core Data is dominated by the performance of the I/O subsystem.
IOW, tuning your fetch request is much more important than avoiding the accessor overhead. Can you do what you're proposing? Yes. Should you? No. You should, IMO, focus upon how to get your data into a MOC efficiently and then refine it with predicates and other filter techniques. Learning how to use the various key path operators and predicate language after the fetch is very important to writing performant CD code. Only after Instruments can document that you are spending an appreciable amount of time in the accessors would I consider your strategy of avoiding them.
In answer to your specific question, you should generally restrict your use of the primitive accessors to within your reimplementation of the public accessors. Sticking with accessors for all of your code then becomes your standard pattern. This gives you the long term engineering benefit of having the ability to associate arbitrary behavior with any property. Finally, if you can use the various key path and set operators, then the CD team has already optimized those access patterns. They are quite performant.
Andrew
I have to model an already written object library in UML.Now, I've read tutorials and examples, but they only discuss real life examples such as cars and their components or students, professors and classes. Obviously, those are very easy to model in UML. However, the particular thing about this library is that it contains both classes which define different objects and Windows forms that allow the user to interact with them. A form can both represent an object graphically by all kinds of Windows controls and allow the user to modify it. In addition, there's also a sort of 'main class' which uploads and downloads these objects to and from a remote server. Obviously, this 'main class' handles all aspects of communication and acts like a data channel. So, schematically this is how the library looks like:
Object1Class [Field1, Field2, ....]
Object2Class [Field1, Field2, ....]
...
Object1Form
Object2Form
...
MainClass (NB: this class doesn't create any forms. It just uses the objects created by the forms. The forms are used externally by software systems which rely on this library)
So how would I model this using UML?
Thanks in advcance,
AlgolDocks
I did not understand the context but it seems to me that a good reverse of the object library could be a good start. You can get class and sequence diagram showing static architecture or methods interactions. You can also revers more than one library which is really useful if you need to understand what is going on.
Having said that I found an example of Jar reverse engineering at: http://www.ejb3.org/jar_file_reverse/jar_file_reverse.html
You should certainly have other tools providing this kind of reverse but I don't know about them providing such an advanced feature therefore can not help further.
All of my Visio experience is with LAN/WAN documentation. I recently had a desire to visualize the relationship between objects in the Nagios configuration and I realized I didn't know how to do it properly and moved on to something more important. I was reading the responses to this thread and realized this is something software developers must do a lot.
So this is probably a soft-pitch question, but what is the proper method for documenting object relationships in Visio? Is there a better template to use? What stencil collection is the proper stencil in?
In my probably naive view I imagine an object being a large box with a single "reception" connector and containing multiple smaller boxes, each of which represents an object member and having its own connector. So, each object member field would connect out to the "reception" connector on the object of the member's type. In and of itself those objects are fairly easy to build. The problem I ran into is that the connector lines didn't respect the objects and ran over the top of them, making an awful, unusable mess.
Thanks for any pointers.
You can use a UML static class diagram with << stereotype >> annotations, which is the kind of thing you would do in Rational Rose for using UML for things that aren't necessarily classes and methods, such as databases.
I've been using these UML stencils for diagramming object models and entity relationship diagrams. It is fairly comprehensive. Be sure to take a look at the "tips" document... very important.