It's a follow up question on previously answered legal prose question by Joel.(created separate question on request)
#LegalProseReference(uri = "foo.bar.com/my-legal-doc.html")
public class MyContract implements Contract {
#Override
public void verify(LedgerTransaction tx) {
// Contract logic.
}
}
As the answer suggests, I got this legal doc my-legal-doc.html. so what happens in case the verify method doesn't throw an exception? and what happens in case verify does throw an exception do I show this legal doc to the user that read this legal doc. That this is why the contract failed? as mentioned in answer legal contract takes precedence-> so if verify method throws exception then how does legal doc takes precedence? I go through this doc find what's wrong and manually verify the tx? also how manually?
Ideally, the contract code and the legal prose should be in perfect alignment. They should be identical, except that one expresses the contract in code, and the other expresses the contract in legal terms.
However, suppose you find that there is a bug in the contract code that means that the contract code doesn't actually fully reflect the legal prose. The idea is that you could use the legal prose document in a court of law to have the transaction reversed, on the basis that you were actually entering into an agreement on the basis of the legal prose document, and this document was not correctly reflected in the contract code.
For example, suppose you discover that a bug in the AssetContract governing AssetStates allowed counterparties to transfer themselves your assets without your agreement (in practice, we'd expect the contract code bugs to be less obvious than this). You could go to court and use the legal prose document to prove that this was a bug in the contract, rather than its true intent.
However, it's ultimately up to the individual countries' legal systems whether the contract code or legal prose takes precedence. Currently, we'd expect the legal prose to define the terms of the contract. This may change in the future as courts become more comfortable with the idea of code-as-law.
Related
I have an application that, for a specific resource at URI x, generates a system of URIs such as x#a, x#b and so on, and stores them in an RDF graph at any position in a triple, even as predicates.
This is fine but the issue arises when the resource that should be described in this way is provided "inline" i.e. without a URI. In RDF I have the option to use blank nodes, but there are two issues I have with them:
Blank nodes are mostly regarded with existential meaning, i.e. they denote some node. The nodes produced by the application are not just some nodes – they are exactly the nodes produced from one specific resource that was given to them at one specific time. In contrast, a blank node can be "satisfied" by a concrete URI node with the same relations to other nodes, becoming redundant in presence of such a node.
Blank nodes cannot be unfortunately used as predicates in RDF (or at least in some formatting schemes).
This means that I have to find a URI, but I am wondering what scheme to choose. So far I have considered these options:
Generate a new UUID and use urn:uuid:. This is sufficient, but I would prefer something that expresses the temporary status of the URI better, so that it would be apparent it was generated for this one case only. In comparison, UUIDs can be used as stable identifiers for more permanent resources as well, and there is no inherent distinction.
Use a proprietary URI, like nodeID: which is sometimes used for blank nodes, but is still a valid URI nonetheless. I would append a new UUID to that as well. This seems a bit better to me since it mimics blank nodes but without their different semantics, but I would still prefer something more standardized.
Use tag: URIs. Tags have a time component to them, so the temporal notion is expressed sufficiently. However, I am not sure about the authority since whoever runs the application will in essence become the authority. Another option is to use my own domain and somehow "grant" the rights of minting tags to anyone running the application (or just to anyone in general). This way, I can express everything I need (the temporary notion of the resource, the uniqueness since I would also include a new UUID in the URI, and a description of the purpose and use of the tags on the website itself).
This is in my opinion not a bad solution, but it somewhat limits the usage of the application, as once my control of the domain expires, users of the application will no longer have the rights to mint new tags under the original authority, and they will have to find a new one (unless I leave the authority blank; while it is not strictly stated by the specification, anything is technically valid since implementations must not reject non-conforming authorities). I am also concerned about the time component itself, as it might pose a security risk (although it can be less specific). I am also not overly accustomed to the concept of tags, so I am not sure if it isn't against their spirit.
I can provide all of these methods as options in the application, but I would like to know if there are perhaps better options.
Problem
I need to overwrite the method
#Override protected final void layoutChartChildren(double top, double left, double width, double height)
of the XYChart class. Obviously I'm not allowed to.
Question
Why do people declare methods as "final"? Is there any benefit in that?
This answer is just a verbatim quote of text by Richard Bair, one of the JavaFX API designers, which was posted on a mailing list in response to the question: "Why is almost everything in the [JavaFX] API final?"
Subclassing breaks encapsulation. That's the fundamental reason why
you must design with care to allow for subclassing, or prohibit it.
Making all the fields of a class public would give developers
increased power -- but of course this breaks encapsulation, so we
avoid it.
We broke people all the time in Swing. It was very difficult to make
even modest bug fixes in Swing without breaking somebody. Changing the
order of calls in a method, broke people. When your framework or API
is being used by millions of programs and the program authors have no
way of knowing which version of your framework they might be running
on (the curse of a shared install of the JRE!), then you find an awful
lot of wisdom in making everything final you possibly can. It isn't
just to protect your own freedom, it actually creates a better product
for everybody. You think you want to subclass and override, but this
comes with a significant downside. The framework author isn't going to
be able to make things better for you in the future.
There's more to it though. When you design an API, you have to think
about the combinations of all things allowed by a developer. When you
allow subclassing, you open up a tremendous number of additional
possible failure modes, so you need to do so with care. Allowing a
subclass but limiting what a superclass allows for redefinition
reduces failure modes. One of my ideals in API design is to create an
API with as much power as possible while reducing the number of
failure modes. It is challenging to do so while also providing enough
flexibility for developers to do what they need to do, and if I have
to choose, I will always err on the side of giving less API in a
release, because you can always add more API later, but once you've
released an API you're stuck with it, or you will break people. And in
this case, API doesn't just mean the method signature, it means the
behavior when certain methods are invoked (as Josh points out in
Effective Java).
The getter / setter method problem Jonathan described is a perfect
example. If we make those methods non-final, then indeed it allows a
subclass to override and log calls. But that's about all it is good
for. If the subclass were to never call super, then we will be broken
(and their app as well!). They think they're disallowing a certain
input value, but they're not. Or the getter returns a value other than
what the property object holds. Or listener notification doesn't
happen right or at the right time. Or the wrong instance of the
property object is returned.
Two things I really like: final, and immutability. GUI's however tend
to favor big class hierarchies and mutable state :-). But we use final
and immutability as much as we can.
Some information:
Best practice since JavaFX setters/getters are final?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
At work, our service calls follow the pattern of:
Create a proxy that allows you to hit a service on our business tier
upon hitting the service, it creates a new response instance
instantiates a new instance of one of our business code classes
Assigns the result of calling whatever function on the new instance to the response
Returns the response back through the proxy
So it always looks like this:
Dim someRequest as Request = CreateSomeSortOfRequest()
Dim results as Response = Nothing
using proxy as IResultProxy = OurLibrary.Proxy(Of IResultProxy).Create()
results = proxy.GetResults(request)
End Using
Then:
Dim results as Response = Nothing
Using whateverBusiness as new BusinessClass
results = whateverBusiness.ComputeWhatever(request)
End Using
Return results
Pretty basic stuff, right? Well the guys who have worked there for a little over 20 years now will go on and on about how none of these business classes should ever have any member variables of any kind. Ever. Wanna perform some really complicated operation? Better be prepared to pass 10 to (and I've seen it) 30 parameters.
All of this, to me, seems like bad practice. As long as you remain in that narrow scope, hand off a request to a new instance of a business class, ask it to perform whatever, it performs whatever logic necessary within itself, return the result, and carry on with your day.
I've investigated and we only ever use threading ourselves in one location in the system, and that just fires off different service calls (all of which follow the above pattern). We don't use instance pools, static variables, or anything else like that, especially since we have the above stated issue that we have a running belief that there should never be any class scoped variables.
Am I crazy for thinking that having these classes with extremely tight and locked down entry points (i.e. no outside access to internal variables) is perfectly fine, especially since there is no way to access the instances of the business class outside the scope of the service call? Or are my elders correct for stating that any private member variable in a class is non-threadsafe and should never be used?
I guess I should mention that the business classes pretty much always load some data from the database, try to piece that data together into, often, very deep hierarchal structures, then return (or the opposite; taking the object, breaking it apart, and performing, sometimes, hundreds of database calls to save).
Wanna perform some really complicated operation? Better be prepared to pass 10 to (and I've seen it) 30 parameters
Sounds like they don't want any state (public anyway) on their business classes, an understandably noble vision as it is but rarely does it prove to be useful or practical as a general rule. Instead of 30 parameters, maybe they should pass in a struct or request class.
You could point out to them that in their effort to prevent state, that 10-30 parameters comes with its own set of problems.
As stated in the documentation for the brilliant code analysis tool nDepend:
nDepend:
NbParameters: The number of parameters of a method. Ref and Out are also counted. The this reference passed to instance methods in IL is not counted as a parameter.
Recommendations: Methods where NbParameters is higher than 5 might be painful to call and might degrade performance. You should prefer using additional properties/fields to the declaring type to handle numerous states. Another alternative is to provide a class or structure dedicated to handle arguments passing (for example see the class System.Diagnostics.ProcessStartInfo and the method System.Diagnostics.Process.Start(ProcessStartInfo)) - Holy swiss cheese Batman, tell me more.
It's arguably no different to when the client passes a request object to the WCF service. You are passing request objects aren't you?
OP:
Am I crazy for thinking that having these classes with extremely tight and locked down entry points (i.e. no outside access to internal variables) is perfectly fine
OK it sounds like the system has been around for a while and has had some best practices applied by your elders during its construction. That's good. However such a system is arguably only going to continue being robust as someone follows what-ever rules that were setup...and from what you say sound quite bizarre and somewhat ill-informed.
It might also be an example of accidental architecture where the system is just because it is.
e.g. if someone goes and adds a public method and say some public properties or makes what was a private field public is likely to upset the applecart.
I once had the misfortune of working on a legacy system and though it appeared to run without incident, it was all rather fragile due to the exorbitant amount of public fields. (mind you this was c++!)
Someone could have said:
"well don't touch the public fields"
to which I could reply:
"well maybe we shouldn't make the fields public"
Hence their desire to have no instance fields. The notion that c# classes with "member variables of any kind" is naughty is not the real source of concern. Instead I suspect the problem is that of thread safety and for that they should be looking into how the caller or callers be made thread-safe not the business class in this case.
Enforcing thread safety by not having state, though effective is kind of a sledgehammer approach and tends to annoy other parts of OO sub-systems.
WCF Threading Models
It sounds to me they are performing applying old-school threading protection in WCF where WCF has it's own way of guaranteeing thread-safety in a way quite similar to how the Apartment model was successful for COM.
Instead of worrying about lock()s; and synchronisation, why not let WCF serialise calls for you:
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession,
ConcurrencyMode = ConcurrencyMode.Single)]
public partial class MyService: IMyService, IDisposable
{
// ...
}
InstanceContextMode.PerSession essentially tells WCF to create a unique private instance of the service per client proxy. Got two clients calling? Well that means two instances of MyService will be created. So irrespective of what instance members this class has its guaranteed not to trod on the other instance. (note I don't refer to statatics here)
ConcurrencyMode = ConcurrencyMode.Single tells WCF that calls to this service instance must be serialised one after the other and that concurrent calls to the service are not allowed. This ties in with the InstanceContextMode setting.
Just by setting these two but very powerful settings in WCF you have told it to not only create private instances of your WCF service such that multiple clients can't trod on it, but that even if the client shared it's client proxy in a thread and attempted to call one particular service instance concurrently, WCF guarentees that calls to the service will be serialised safely.
What does this mean?
Feel free to add instance fields or properties to your service class
such members won't be trodden on by other threads
when using WCF, there is generally no need for explicit thread locking in your service class (depending on your app, this could apply to subsequent calls. see below)
It does not mean that per-session-single services only ever allow one client at a time. It means only one call per client proxy at a time. Your service will most likely have multiple instances running at a particular moment having a jolly good time in the knowledge that one can't throw stones at the other.
Roll-on effects
As long as you remain in that narrow scope, hand off a request to a new instance of a business class
Since WCF has established a nice thread-safe ecosystem for you, it has a nice follow-on effect elsewhere in the call-stack.
With the knowledge that your service entry point is serialised, you are free to instantiate the business class and set public members if you really wanted to. It's not as if another thread can access it anyway.
Or are my elders correct for stating that any private member variable in a class is non-threadsafe
That depends entirely on how the class is used elsewhere. Just as a well designed business processing layer should not care whether the call stack came from WCF; a unit test; or a console app; there may be an argument for threading neutrality in the layer.
e.g. let's say the business class has some instance property. No drama, the business class isn't spawning threads. All the business class does is fetch some DB data; has a fiddle and returns it to the caller.
The caller is your WCF service. It was the WCF service that created an instance of the business class. But what's that I hear you say - "the WCF service instance is already thread-safe!" Exactly right and thank-you for paying attention. WCF already set up a nice thread safe environment as mentioned and so any instance member in the business class shouldn't get obliterated by another thread.
Our particular WCF thread is the only thread that is even aware of this particular business class's instance.
Conclusion
Many classes in .NET have state and many of those are in private fields. That doesn't mean it's bad design. It's how you use the class that requires thought.
A WinForms Font or Bitmap object has both state; I suspect even with private members; and shouldn't arguably be fiddled with concurrently by multiple threads. That's not a demonstration of poor design by Microsoft's part rather something that should have state.
That's two classes created by people much smarter than you, me and your elders I suspect, in a codebase larger than anything we will ever work on.
I think it is fantastic that you are questioning your elders. Sometimes we don't always get it right.
Keep it up!
See Also
Lowy, Juval, "Programming WCF Services: Mastering WCF and the Azure AppFabric Service Bus", Amazon. The WCF bible - a must read for prior to any serious dabbling into WCF goodness
nDepend, a truly marvelous and powerful code analysis tool. Though one may be forgiven into thinking it's a FxCop-type-tool and though it does support such a feature, it does that and more. It analyses your entire Visual Studio solution (and stand-alone libraries if you wish) investigating coupling for one and excessive use of parameters as another. Be prepared for it pointing out some embarrassing mistakes made by the best of us.
Comes with some groovy charts too that look impressive on any dashboard screen.
is there a way to get the recursive superclass concepts of a concept from freebase? For example, i would call the topic "/games/game_publisher" a concept, and I would like to know if it has any superclasses (e.g., /organization/organization would make sense).
Many thanks!
Freebase Types (the equivalent of your "concept") don't have an inheritance structure. They do however have "included types". One key difference is that an included type only gets added to a topic by when it's main type does by convention of the web client (or other client), but after that it can be removed or re-added independently. For example, Deceased Person has Person as an included type and it's unlikely anyone would ever remove the latter, but Author also has Person as included type because that's the case for the overwhelming majority of authors, but for so-called "corporate authors" one would remove Person and add Organization.
So, the included types does carry some semantic information, but it's not as strong as a super/sub-class relationship.
I am trying to define when to name a class as a Context and I am having a very difficult time. Could someone please define "Context" for me and explain when to name a class "Context"?
Dictionary.com (Random House Dictionary, © Random House, Inc. 2011) defines context as:
the parts of a written or spoken statement that precede or follow a specific word or passage, usually influencing its meaning or effect: You have misinterpreted my remark because you took it out of context.
the set of circumstances or facts that surround a particular event, situation, etc.
The second definition is the applicable definition in this case. Taking the HTTPContext class for example, we know that the class contains information about the web site at the current moment (including the request, the response, the session, the user, etc.)
Therefore, I would define a 'Context' in this regard as a class that provides information about a particular application or service; or provides access to objects and methods that describe the current state of an application (or a particular facet of an application, such as a DataContext class in Linq To SQL or Entity Framework).
If you look up the Oxford English Dictionary for "context" it tells us:
the circumstances that form the
setting for an event, statement, or
idea, and in terms of which it can be
fully understood:
In programming a "context" class would be a class that provides your application code or code running within a framework with a set of data or objects relevant and meaningful to the task at hand.
For example, ASP.NET's HttpContext object provides information about the current HttpRequest (cookies, headers, user agent and so on). This data is meaningful only in the "context" of the current request as it may and will change for other requests.