Can someone explain what is it legal prose in Corda? I understood that it is a document, which is used to solve conflicts, but i didnt find any information how it looks like. And how is it linked with smart contract?
A Contract class can be annotated with the #LegalProseReference annotation. This annotation associates the contract with a document that restates the constraints imposed by verify in legal prose terms. This is not required, but can be useful in contexts where it is expected that legal contracts will take precedence over the software implementations in case of disagreement.
#LegalProseReference takes a single parameter, uri, which identifies the legal prose document the contract is associated with:
#LegalProseReference(uri = "foo.bar.com/my-legal-doc.html")
public class MyContract implements Contract {
#Override
public void verify(LedgerTransaction tx) {
// Contract logic.
}
}
Related
Apologies in advance for the basic question and please ignore the mix of kotlin/java!
I’ve spun up a very simple example building upon the example-cordapp and I wish to demonstrate the ability to override flows to put in some additional node operator specific logic from another cordapp. For example: a certain node owner may not want to do business under certain scenarios, so add in some additional checks prior to the initiating or responder signing phase.
I’ve successfully overridden the responder flow fine and I can see it being executed on the node with the extending cordapp however I’m not having much luck with initiator flow.
From reading here: https://www.corda.net/blog/extending-and-overriding-flows-from-external-cordapps/ it suggests that I would have to have my api/rpc client directly invoke the extended version directly, however I was hoping it would work similar to the responder flow and automatically pick it up based on the hops.
Base flow:
public class BondFlow {
#InitiatingFlow
#StartableByRPC
public static class Initiator extends FlowLogic<SignedTransaction> {
// Stuff
public Initiator(int bondValue, Party obligee, Party principal) {
this.bondValue = bondValue;
this.obligee = obligee;
this.principal = principal;
}
// More Stuff
Overridden (in a separate Cordapp):
public class MyCustomFlow {
#StartableByRPC
public static class Initiator extends BondFlow.Initiator {
// Stuff
public Initiator(int bondValue, Party obligee, Party principal) {
super(bondValue, obligee, principal);
}
// More stuff
My RPC client just calls the Initiator as you may expect:
val signedTx = proxy.startTrackedFlow(::Initiator, bondValue, obligeeParty, principalParty).returnValue.getOrThrow()
I could change my api/rpc client call to allow configuration of the initiator flow to be called but I'd like to understand if there is an alternative.
Many Thanks
I would honestly suggest that you give flows different names for each different flows. We had named a couple of our flows simple as initiator and responder out of the simplicity purpose.
However, it is still fine to have same names cross different CorDapps. You just need to call their full name including the package name.
Run flow list in your node shell and you should see it.
For example:
our signature YoFlow in the yo-Cordapp has a full name of net.corda.examples.yo.flows.YoFlow,
but in single cordapp scenario, you can just call it by run flow start YoFlow
Basic concept in DI is that dependency objects should be passed instead of creating them in the dependent object.
Only reasons I could find for this is in this answer:
To hide the construction details of dependency from dependent to make code less ugly.
To facilitate mocking in Unit Testing.
Are there any other reasons?
If not, can you please explain these reasons more to justify DI?
Let's look at the real life example. Let's say you have a car. Car needs an engine.
class Car
{
private $engine;
public function __construct()
{
$this->engine = new V6Engine();
}
}
The car has a dependency on the engine. In this case, the car itself needs to construct a new engine!
Does it make sense?
Well.. NO!
Also, the car is coupled to the specific version of the engine.
This makes more sense.
Someone else needs to provide the car engine. It could be some engine supplier, engine factory... It is not car's job to create engine!
class Car
{
private $engine;
public function __construct(Engine $engine)
{
$this->engine = new $engine;
}
}
interface Engine
{
public function start();
}
class V6Engine implements Engine
{
public function start()
{
echo "vrooom, vrooom V6 cool noise"
}
}
Also, you could easily swap the engine, you are not coupled to the specific engine. That new engine only needs to be able to start.
Martin Fowler has written a very good article about the inversion of control and dependency injection.
https://martinfowler.com/articles/injection.html
Please read it - because he will explain the DI much better than I can do :)))
Also, there is very good video by the Miško Hevery "The Clean Code Talks - Don't Look For Things!". You will be much clever after watching it :)
https://www.youtube.com/watch?v=RlfLCWKxHJ0
I would add that creating the object inside your service hides the scope of your service.
Requiring it as an hard dependency makes it explicit that your service needs an instance of such object in order to work. By making it part of the contract, the dependency is no more an implementation detail.
That also opens for flexibility, you may typehint against e.g. EngineInterface instead of a concrete implementation, meaning that you don't care about what implementation is passed to your service but rely on the contract imposed by the interface (imagine a mailer that send mails for production, but a no-op for testing).
The typechecker considers this class requirement by the interface IBase to be cyclic:
<?hh // strict
interface IBase {
require extends Derived;
}
class Derived implements IBase {}
// Cyclic class definition : IBase Derived (Typing[4013])
As I understand it, the constraint just prevents all descendants from implements IBase without extends Derived. Is there a hole with this that I'm not seeing?
Why do I care?
I'm interested in an interface that wants to compare against other instances of itself or its subtypes.
<?hh // strict
interface Comparable<-T as Comparable<T>> {
require extends ArtificialCeiling;
public function compare(T $comparee): bool;
}
abstract class ArtificialCeiling implements Comparable<ArtificialCeiling> {
abstract public function compare(ArtificialCeiling $comparee): bool;
}
(this is not the answer here, because this isn't sound in contravariant positions, especially in interfaces)
Suppose now we want to accept and store a wrapper of Comparable but we don't care about what type of Comparable it's lugging around. Normally, we'd just parameterize with the upper bound, or mixed if its unconstrained.
The problem is that the upper bound for Comparable is Comparable<Comparable<Comparable<... forever, but I don't have the stamina to type that for all eternity. Without existential types like Scala or multiple constraints like TComparable as Comparable & ArtificialCeiling, we have to resort to something less obvious. require extends ArtificialCeiling would be just like a multiple constraint and, without this mysterious cyclic problem, it would be a tidy fix.
The other natural alternative is for the accepting class to append the parameter to its own parameter list as TComparable as Comparable<TComparable>, but that defeats the principle of not caring about TComparable.
Well, I'm not an expert, but the message seems clear to me:
the definition is cyclic, because Derived uses IBase and IBase references Derived.
According to the documentation:
require extends should be taken literally. The class must extend the
required class; thus the actual required class does not meet that
requirement. This is to avoid some subtle circular dependencies when
checking requirements.
I think the way to go is to specify the requirement for an ancestor class, and implement the interface in the non-abstract derived class(es). Or maybe just implement compare as a normal method in the ancestor class, instead of using a trait.
Why not getters? And how it combined with encapsulation principe? Does it safe?
Upd:
Yes, I'm about Request. Safety: I mean that anybody in code (by using listener) can do $request->attributes = null;
If you are talking about the Request and Response objects, there was a discussion about this on the Symfony developers mailing list a few days ago. I invite you to take a look at it here.
Why not getters? Not sure if there is a definitive answer to this but I think it is a decision based on personal tastes mainly.
Does it break encapsulation? Not really in my opinion for this particular case. My reasoning is that for now, no special logic is performed on the various objects that are public right now. So in the end, you would end up retrieving the object via a getter and read or modify it directly. There is not much difference with retrieving the object using a public property.
// With Getters
$parameterBag = $request->getQuery();
$parameterBag->get('key');
// With Public Properties
$parameterBag = $request->query;
$parameterBag->get('key');
Encapsulation should be enforced when you need to be sure that a property has a particular value or format. For example, say you have a class with a cost property and this property should never be negative. So if the cost property was public, it could be possible to set it to a negative value by doing something like $receipt->cost = -1;. However, if you make it private and the user of the class is only able to set it via a setter, then you could ensure that the cost is never below 0 by doing some special validation in the setter code.
In our case, we are talking about a collection object, a ParameterBag object to be precise. I don't think there are special requirements on this object but I could be wrong. So for me, it is correct to have access to those properties via public properties.
The main argument I could see in favor of the getters is that it would be more consistent with the other parts of the framework where getters are used. However, the getters could co-exist with the public properties.
To conclude, I think it is safe for this particular case. Public properties should be used only in special cases where it seems to be beneficial and where it is correct to do so.
Do you mean the Request object? Or what properties are you thinking of?
If you're worried about safety, then take a look at the Security component, use Test-Driven-Development, use tested libraries (don't invent your own authentication, cryptography and related solutions) and do code reviews.
What's the point to encapsulate what already's been encapsulated? I mean - each of this properties is a parameterBag instance with it's encapsulation.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
could some body explain me abstraction and interface in asp.net, C# by taking an apprpriate example...pleasse
i am not understanding it for long
I often find the following sample quite illuminating when it comes to explaining this:
Disclaimer: the code examples are written directly into the text, and may contain errors that I have overseen. Please let me know if you find such errors.
Let's say you have a database with a Customer table, and in your code you have a customer class:
class Customer
{
public int Id { get; set; }
public string Name { get; set; }
}
In order to provide a mechanism to get customer data from the database, you need to write some class doing that. This can be placed in something called a repository. Now, we don't want our code to rely too much on what exact database we use. It could be SQL server, it could be a text file. So we want an abstraction layer shielding the code from this knowledge. All we need to know is what such a repository looks like:
public interface ICustomerRepository
{
Customer GetCustomer(int id);
IEnumerable<Customer> FindCustomers(string beginningOfName);
}
We can now implement this interface for the data storage that we use:
public class SqlServerCustomerRepository : ICustomerRepository
{
public Customer GetCustomer(int id)
{
using(SqlConnection connection = new SqlConnection(connectionString))
{
// code to fetch data and populate Customer objects go here
}
}
// implementations of other members of ICustomerRepository
// left out to keep code short. Just imagine they are here :)
}
Finally, when we want to use this code, we can have a factory create the concrete ICustomerRepository implementation to use:
public static class RepositoryFactory
{
public static ICustomerRepository CreateCustomerRepository()
{
return new SqlServerCustomerRepository();
}
}
...and in our code where we need the data:
ICustomerRepository repository = RepositoryFactory.CreateCustomerRepository();
IEnumerable<Customer> customers = repository.FindCustomers("A");
This way, there is no hard coupling between the consuming code, and the particular kind of repository in use (except for in the factory method, but that is the one and only place where this knowledge exists). This makes it easy to replace the concrete repository implementation. This is also useful for testing, where you can easily create a mock repository returning hard coded results for given input, so that you can unit test the code that needs data from the repository.
Well abstract classes and interfaces are not strictly asp.net technic they are OOP concept.
Interface
An interface is like a class but all the methods and properties are abstract. An Interface cannot be instantiated like abstract class. All the methods and properties defined in Interface are by default public and abstract.
Interface generally refers to an abstraction that an entity provides of itself to the outside. Interface can help in separating the methods for external and internal communication without effecting in the way external entities interact with the type..
Example:
If you have interface IDoSomething { void Do(); }
The class that implements the interface must provide a body for Do() method e.g.
class SomeClass : IDoSomething
{
public void Do()
{
//body of the method
}
}
The advantage of this is when you make something that need only Do method you pass the interface not the class.
public static void SomeMethod(IDoSomething obj)
{
obj.Do();
}
Now SomeMethod(IDoSomething obj) will work with any class that implements IDoSomething
Abstract Class
An abstract class is a class with at least one method defined as abstract. This type of class cannot be instantiated. An abstract class can have one or more abstract methods and properties and other methods and properties like normal classes.
The idea is the same but in abstract class you can have methods with implemented logic, fields and so on.
Abstraction
Abstraction is the process of hiding how the object is working, and its only showing the information of the object the way we can understand it. Means it represent the essential details with out showing ground details. We putting all variables and method in a class which are necessary.
Eg: Employee and Patient.
Company interested to fill about the Employee details like Name, Address, Qualification, DOB, Age, Mobile, Marks, Experience etc
Hospital interested to fill about the patient details like Name, DOB, Height, Weight, Age, Address, Mobile, Blood Group etc.
Both Company and hospital interested to fill some common fields like Name, Age, DOB, Address, Mobile etc. So we can create a class which consist of common thing that is called abstract class. This class wont be complete but can inherit by other class.
Abstract vs Interface
You cannot create an object of abstract class , but can make derivations of this.
An abstract class can contain either abstract methods or non abstract methods. Abstract members do not have any implementation in the abstract class, but the same has to be provided in its derived class.
An abstract class can have abstract members as well non abstract members. But in an interface all the members are implicitly abstract and all the members of the interface must override to its derived class.
Defining an abstract class with all the abstract members is similar to defining an interface. i.e we can say an interface is an abstract class with all the abstract members
Classes may inherit from only one base class, so if you want to use abstract classes to provide polymorphism to a group of classes, they must all inherit from that class.
Abstract classes may also provide members that have already been implemented. Therefore, you can ensure a certain amount of identical functionality with an abstract class, but cannot with an interface.
Here are some recommendations to help you to decide whether to use an interface or an abstract class to provide polymorphism for your components.
1). If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface.
2). If the functionality you are creating will be useful across a wide range of disparate objects, use an interface. Abstract classes should be used primarily for objects that are closely related, whereas interfaces are best suited for providing common functionality to unrelated classes.
3). If you are designing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class.
4). If you want to provide common, implemented functionality among all implementations of your component, use an abstract class. Abstract classes allow you to partially implement your class, whereas interfaces contain no implementation for any members.