I put facts into the Working Set using the this.session.Insert(object fact1) or this.session.InsertAll(IEnumerable<object> fact) methods.
Now, one of the facts changes and I call the this.session.Replace(object fact).
How does NRules know which object to replace? Does it compare the references for equality? Does it call the Equals operator? I'm guessing you're probably using Dictionary logic, so the object's Equals() and GetHashCode() determine when two facts are the same, but I need some affirmation before I continue with my design.
When calling Update, UpdateAll, Retract or RetractAll in NRules, the engine indeed looks the facts up in the Dictionary. So, the engine uses object's Equals and GetHashCode implementation.
However, if updating/retracting the same object instance, it's not necessary to override Equals and GetHashCode, because default implementation for reference types, which uses ReferenceEquals, works just fine.
Related
The documentation for -[NSObject scriptingValueForSpecifier:] says:
You can override this method to customize the evaluation of object specifiers…
I want to do this to make AppleScript lookups in my app more efficient. There are certain types of whose tests where I could do a hash lookup instead of having AppleScript ask for every single object and then query their properties one-by-one. The problem is that if I receive a NSWhoseSpecifier, I can get its test, which is a NSSpecifierTest, but there doesn’t seem to be a way to look inside the NSSpecifierTest to figure out the property being tested. Everything but the initializers and the -isTrue method are private.
Let's make a distinction. If you merely want to customize the values returned by a whose clause — in the sense of fine-tuning results — then you would override scriptingValueForSpecifier for the object in question. For example, say you have an object called 'box' that has a property called 'color,' and you want a statement like every box whose color is blue to also return boxes whose color is 'aqua,' 'teal,' or 'navy' (which are all shades of blue), then you would override scriptingValueForSpecifier to implement that.
However, if your goal is to make a more efficient form of whose test, you're probably going to have to implement appropriate methods from the NSScriptingComparisonMethods protocol. These are the routines that AppleScript uses to evaluate scripting object comparisons through NSSpecifierTest (which is what NSWhoseSpecifier) relies on). Again, you'd override these methods on your object(s) to provide different methods for doing evaluations.
As a last resort, you might try subclassing NSWhoseSpecifier or NSSpecifierTest, with the understanding that these are opaque classes for which Apple discourages subclassing. I'm not entirely certain how you would implement those subclasses; you'd probably have to register your subclass with NSScriptSuiteRegistry commands.
It looks like it will be possible to override -scriptingValueForSpecifier: and then ask the NSScriptObjectSpecifier for its descriptor. This produces an NSAppleEventDescriptor that has the needed information, but it has to be interpreted manually.
There is a pattern or term that is used to avoid codes like
myObject.fieldA.fieldB.fieldC
something like this. I forgot what this term is called. Can anyone let me know about it?
It violates the Law of Demeter, which states that code should only access its own local variables, parameters, and instance members.
It could be a case of of feature envy, where a class calls a lot of getters or accesses a lot of data from another class.
If these are really fields, they are poorly encapsulated (i.e., not behind a function), and any change to these fields forces you to modify all code that's using them.
Testing such code becomes hard, as you will have to mock not only fieldA, but also that's fieldB, and in turn that's fieldC.
I think you are trying to create a new object and add certain properties to that object. If that is the case then it's Builder design patten where you seperate the construction and representation.
If you are trying to call a certain field with the above shown code then your design is very poor. An object should store only it's own properties.
I'm currently working on a project where I'm going to do a lot of comparison of similar non-database (service layer objects for this discuss) objects and objects retrieved from the database via LinqToSql. For the sake of this discussion, assume I have a service layer Product object with a string field that is represented in the database. However, in the database, there is also a primary key Id that is not represented in the service layer.
Accordingly (as I often do for unit testing etc), I overrode Equals(Object), Equals(Product), and GetHashCode and implemented IEquatable with the expectation that I would be able to write code like this:
myContext.Products.Where(p => p.Equals(passedInProduct).SingleOrDefault();
And so forth.
The Equals override is tested and works. The objects are mutable so the usual caveats apply to the GetHashCode override. However, for the purposes of this example, the objects are not modified except by LtS and could be made readonly.
Here's the simple test:
Create a test object in memory and commit to the LtS context. By committing, the test object is populated with a few auto-generated fields.
Create another identical test object in memory (separate reference)
Attempt to retrieve the first object from the database using the second object as the criteria. (see code line above).
// Setup
string productDesc = "12A";
Product testProduct1 = _CreateTestProductInDatabase(productDesc);
Product testProduct2 = _CreateTestProduct(productDesc);
// check setup
Product retrievedProduct1 = ProductRepo.Retrieve(testProduct1);
//Assert.IsNotNull(retrievedProduct1);
// execute - try to retrieve the 'equivalent' product object
Product retrievedProduct2 = ProductRepo.Retrieve(testProduct2);
A simplified version of Retrieve (cruft removed is just parameter checks etc):
using (var dbContext = new ProductDataContext()) {
Product retrievedProduct = dbContext.Products
.Where(p => p.Equals(product)).SingleOrDefault();
NB: The overridden Equals method knows not to care about the auto-generated fields from the database and only looks at the string that is represented in the service layer.
Here's what I observed:
Retrieve on testProduct1 succeeds (no surprise, equal by reference)
Retrieve on testProduct2 fails (null)
The overridden Equals method called in the Retrieve method is never hit during either Retrieve calls
However, the overridden Equals method is called multiple times by the context on SubmitChanges (called when creating the first test object in the database) (works as expected).
Statically, the compiler knows that the type of the objects being emitted and is able to resolve the type.
So my specific questions:
Am I trying to do something ill-advised? Seems like a straightforward use of Equals.
Corollary to first question: alternate suggestions to deal with linq to sql equality checking while keeping comparison details inside the objects rather than the repository
Why might I have observed the Equals method being resolved in SubmitChanges but not in the Where clause?
I'm as much interested in understanding as making my Equals calls work. But I also would love to learn how to make this 'pattern' work rather than just understand why it appears to be an 'anti-pattern' in the contest of LtS and C#.
Please don't suggest I just filter directly on the context with Where statements. Obviously, I can remove the Equals call and do that. However, some of the other objects (not presented here) are large and a bit complicated. For the sake of maintenance and clarity, I want to keep knowledge of how to compare itself to another of its own type in one place and ideally as part of the object in question.
Some other things I tried that didn't change the behavior:
Overloaded and used == instead
Casting the lambda variable to the type p => (Product)p
Getting an IQueryable object first and calling Equals in the Where clause
Some other things I tried that didn't work:
Creating a static ProductEquals(Product first, Product second) method: System.NotSupportedException:has no supported translation to SQL.
Thanks StackOverflow contributors!
Re Possible dups: I've read ~10 other questions. I'd love a pointer to an exact duplicate but most don't seem to directly address what seems to be an oddity of LinqToSql.
Am I trying to do something ill-advised?
Absolutely. Consider what LINQ to SQL does: it creates a SQL representation of your query. It doesn't know what your overridden Equals method does, so can't translate that logic into SQL.
Corollary to first question: alternate suggestions to deal with linq to sql equality checking while keeping comparison details inside the objects rather than the repository
You'd need to do something with expression trees to represent the equality that way - and then build those expression trees up into a full query. It won't be fun, but it should be possible. It will affect how you build all your queries though.
I would have expected most database representations to be ID-based though, so you should be able to just compare IDs for equality. Usually when I've seen attempts to really model data in an OO fashion but store it in a database, the leakiness of the abstraction has caused a lot of pain.
Why might I have observed the Equals method being resolved in SubmitChanges but not in the Where clause?
Presumably SubmitChanges is working against a set of in-memory objects to work out what's changed - it doesn't have to do any conversion to SQL to do that part.
When using the query operator Distinct() the types in the queried sequence must either provide suitable overloads of GetHashCode() and Equals() or you have to pass an implementation of IEqualityComparer<T>.
My question: Why is there no overload of Distinct() accepting a Delegate instance (e.g. Comparison<T>)? - If it was existent a more lighweight lambda expression could be passed (more lightweight than an implementation of IEqualityComparer<T>). - Am I missing something here?
Because it uses GetHashCode().
You cannot make a delegate that gives hash codes.
It could take two delegates, but that would be confusing.
It would be better to ask why there isn't a DistinctBy() method that takes a projection.
otherwise you can try MoreLINQ and its method DistincBy
I'm looking at some code I've written and thinking "should I be passing that object into the method or just some of its properties?".
Let me explain:
This object has about 15 properties - user inputs. I then have about 10 methods that use upto 5 of these inputs. Now, the interface looks a lot cleaner, if each method has 1 parameter - the "user inputs object". But each method does not need all of these properties. I could just pass the properties that each method needs.
The fact I'm asking this question indicates I accept I may be doing things wrong.
Discuss......:)
EDIT: To add calrity:
From a web page a user enters details about their house and garden. Number of doors, number of rooms and other properties of this nature (15 in total).
These details are stored on a "HouseDetails" object as simple integer properties.
An instance of "HouseDetails" is passed into "HouseRequirementsCalculator". This class has 10 private methods like "calculate area of carpet", "caclulateExtensionPotential" etc.
For an example of my query, let's use "CalculateAreaOfCarpet" method.
should I pass the "HouseDetails" object
or should I pass "HouseDetails.MainRoomArea, HouseDetails.KitchenArea, HouseDetails.BathroomArea" etc
Based on my answer above and related to your edit:
a) You should pass the "HouseDetails"
object
Other thoughts:
Thinking more about your question and especially the added detail i'm left wondering why you would not just include those calculation methods as part of your HouseDetails object. After all, they are calculations that are specific to that object only. Why create an interface and another class to manage the calculations separately?
Older text:
Each method should and will know what part of the passed-in object it needs to reference to get its job done. You don't/shouldn't need to enforce this knowledge by creating fine-grained overloads in your interface. The passed-in object is your model and your contract.
Also, imagine how much code will be affected if you add and remove a property from this object. Keep it simple.
Passing individual properties - and different in each case - seems pretty messy. I'd rather pass whole objects.
Mind that you gave not enough insight into your situation. Perhaps try to describe the actual usage of this things? What is this object with 15 properties?, are those "10 methods that use upto 5 of these input" on the same object, or some other one?
After the question been edited
I should definitely go with passing the whole object and do the necessary calculations in the Calculator class.
On the other hand you may find Domain Driven Design an attractive alternative (http://en.wikipedia.org/wiki/Domain-driven_design). With regard to that principles you could add methods from calculator to the HouseDetails class. Domain Driven Design is quite nice style of writing apps, just depends how clean this way is for you.