It seems that design by contract has limit to express specification. For example, i tried to express Stack FILO property with contract, but didn't get an idea. Anybody can help?
I think the root cause is that precondition/postcondition/invariant are assertations without side effects. It leads to the checking of FILO property which is a kind of side effects not easy even possible.
That's true, design by contract has limited functionality. They are not panacea. Because if they were then the IT industry would throw out unit-testing, code reviews etc.
I suggest you to write simple unit-test for this case rather than crack your head by implementing a contract (which even may be unimplementable).
Related
I'm writing a client for a REST API for an ERP system(large complicated piece of software). I want to get the design architecture correct now, so I save myself time down the road, hoping you can help. If helpful server side urls are of the format /myServer/v1/someService/someMethod?someParam=x
I started off with a restClient class with public function for all the ERP actions(e.g. restClient->someServiceSomeMethod(someParam)). The restClient knows about authentication, and has private get, post, etc methods. I started with this approach as it's the simplest architecture, although I'm wondering if I should be using inheritance or some other approach(I don't want to overcomplicate but I'm starting to feel like I'm going down the wrong path). For the past 10 years are so I've written mostly procedural code, so I'm a bit rusty on OOP design... Would it be "better" to have classes for each service that inherits the restClient class? The the end code would then instantiate the service object they need then calls the method(someService->someMethod(someParam)? This "feels" like the right way to go, but I'm fuzzy on how I'd authenticate and it's been a long time since I did OOP so would hate to overcomplicate things and get no value out of it.
A good rule of thumb for me is that simpler is usually better.
Inheritance, in my opinion, feels a bit restrictive for this - and you introduce coupling that might cause you pain later. If you build 100 different services and they all share a common super class, but it turns out that 5 of them need to be behave in a slightly different fashion, everything else will also be affected. That could get messy.
Although I don't have sufficient detail to understand all the aspects of your particular scenario, I would strongly consider composition over inheritance - build a RestClient class that can deal with some of the common scenarios (auth, GET, POST, etc.), but instead of extending it, just provide a reference to it to anything else that might require that functionality.
In addition, if there are various 'groups' of common operations (e.g CRUD), why not model those with an interface? Your classes could then implement the interface instead of extending a common super class, giving you the benefit of consistency but without the drawbacks of inheritance.
I have a question regarding the "Use Case Output Port" in Uncle Bob´s Clean Architecture.
In the image, Uncle Bob describes the port as an interface. I am wondering if it has to be that way or if the invoked Use Case Interactor could also return a "simple" value. In either case the Application and Business Rules Layer would define its interface that the Interface Adapters Layer has to use. So I think for simple invocations just returning a value would not violate the architectural idea.
Is that true?
Additionally, I think this Output Port Interface implemented by the presenter should work like the Observer pattern. The presenter simply observes the interactor for relevant "events". In the case of .NET where events are first-class citizens, I think using one of these is the same idea.
Are these thoughts compatible with the ideas behind Clean Architecture?
Howzit OP. I see your question is still unanswered after all these years and I hope we can reason about this and provide some clarity. I also hope I am understanding your question correctly. So with that in mind, here is how I see the solution:
The short answer is, a use case interactor should be able to return a simple value (by which I assume string, int, bool etc) without breaking any architectural rules.
If we go over the onion architecture, which is very similar to the clean architecture, the idea is to encapsulate the core business logic in the center of the architecture, the domain. The corresponding concept in the clean architecture is the entities and the use cases on top of it. We do this because we want to dictate our understanding of the business in a consistent way when we write our business rules.
The interface adapters allow us to convert the outside world to our understanding. What we want is a contract in our domain (use cases or entities) that ensures we will get what we need from the outside world, without knowing any implementation details. We also don't care what the outside world calls it, we convert their understanding to ours.
A common way to do this, is to define the interface in the domain to establish a contract that says, we expect to give "x", and you must then tell us what "y" is. The implementation can then sit outside the domain.
Now to get to the core of your question. Let's assume that the core of our application is to track some complicated process with various stages. During one of these stages, we need to send data to a couple of external parties and we want to keep a reference of some sort for auditing purposes. In such a case our interface may sit in the domain and state we send our complicated object to some party, and we expect a string reference back. We can then use this string reference and fire some domain event etc. The implementation can sit completely outside of the domain and call external APIs and do it's thing, but our core domain is unaffected. Hence returning a simple value has no impact on the architecture. The reverse of the above scenario may also hold true. We can say that we have a reference id of some sort, and the outside world needs to return us our understanding of some object.
For the second part of your question. I would imagine it depends on the use case itself. If you present some idea out there and need to constantly react to it, domain events will get involved and you will have a structure very similar to the observer pattern. .NET encapsulates events very nicely and fits very well with clean architecture and Domain driven design.
Please let me know if the above makes sense or if I can clarify it in any way.
I know that WCF or any web service platform does not prevent the developers from mixing fetch and update in same operation. What I mean is mentioned below
List UpdateDate( SomeType Datacontract)
Syntactically this is correct format an is supported in WCF. But is it ok to do this in service oriented world, also is industry wide standard to support this.
One problem I see right away is we violate the very first law of SOA which is atomicity but are there any other issues associated?
It's wider than just WCF: any method that appears to be a Get/Fetch (i.e. by its name) should ideally not perform updates.
The classic Bad example is a Property Getter than alters the state of objects, thus introducing the possibility of unwanted side effects.
Our architect has spoken about using SOA techniques throughout our codebase, even on interfaces that are not actually hosted as a service. One of his requests is that we design our interface methods so that we make no assumptions about the actual implementation. So if we have a method that takes in an object and needs to update a property on that object, we explictly need to return the object from the method. Otherwise we would be relying on the fact that Something is a reference type and c# allows us to update properties on a reference type by default.
So:
public void SaveSomething(Something something)
{
//save to database
something.SomethingID = 42;
}
becomes:
public Something SaveSomething(Something something)
{
//save to database
return new Something
{
//all properties here including new primary key from db
};
}
I can't really get my head around the benefits of this approach and was wondering if anyone could help?
Is this a common approach?
I think your architect is trying to get your code to have fewer side effects. In your specific example, there isn't a benefit. In many, many cases, your architect would be right, and you can design large parts of your application without side effects, but one place this cannot happen is during operations against a database.
What you need to do is get familiar with functional programming, and prepare for your conversations about cases like these with your architect. Remember his/her intentions are most likely good, but specific cases are YOUR domain. In this case, the side effect is the point, and you would most likely want a return type of bool to indicate success, but returning a new type doesn't make sense.
Show your architect that you understand limiting side effects, but certain side effects must be allowed (database, UI, network access, et cetera), and you will likely find that he or she agrees with you. Find a way to isolate the desired side effects and make them clear to him or her, and it will help your case. Your architect will probably appreciate it if you do this in the spirit of collaboration (not trying to shoot holes in his or her plan).
A couple resources for FP:
A great tutorial on Functional
Programming
Wikipedia's entry on Functional programming
Good luck, I hope this helps.
Currently I am creating a WCF service which has to connect to a DAL which, just connects to a database using ADO.net and stored procedures.
The DAl writes its responses from the database to a datacontract which is passed over the wire to the client via the service.
I was reading that this may possibly be the anti pattern 'CRudy Interface', but I wasn't sure as I am sharing the datacontract.
If I am using an anti pattern, can anyone suggest a better pattern to use for the behavior I require?
Well, there seems to be some controversy about the CRUDy pattern and it's pros and cons. At a minimum, I would call a service interface that makes you write this kind of code to use it an anti-pattern (as commented here):
service.CreateCustomer(c);
foreach(Group group in c.Groups)
service.AddCustomerToGroup(c.CustomerId, group.GroupId);
foreach(Person person in c.Contacts)
service.AddCustomerContact(c.CustomerId, person);
Is exposing CRUDy interfaces bad in itself? I wouldn't say so. What's important is to provide an interface which will
encapsulate knowledge about the underlying processes
not be very chatty
It does seem like the CRUD interface anti-pattern, but it would be good to see some interface examples to confirm.
This paper has a really good discussion on designing better service interfaces.
It includes a critique on, and alternative to, the CRUD anti-pattern.
If you have a cruddy use case to implement you will get a cruddy interface, don't sweat it. The anti-pattern is when you implement non-cruddy things in a cruddy way.