I am designing an order system and the state design pattern seems appropriate because the order can change its state and thereby the allowed functionalities for the order. Below is my basic class diagram:
I do not like this approach because clients cannot see if a method is supported and violates Liskov principle. I created an alternative below:
I like this better but still the client has to check if a method is supported. But they can still call the unsupported method and get an exception. Does this still violates the Liskov principle?
Is there a better design that is in compliance with Liskov and keeps the user from calling invalid methods for a specific state?
What you are showing is not State pattern. State pattern alters object behavior when its internal state changes. For example, a light switch can turn on or turn off the light when you toggle it, depending on its state (different behavior on the same method).
With this Order interface (4 diff methods) I don't see any benefits of introducing State pattern. It will only complicate things for no reason. But I don't know all the details so it is up to you what to do next.
Check this link to see examples of State patten implementation https://sourcemaking.com/design_patterns/state
Related
I'm going to ask your Point of view about a design matter.
The question is basically the following: a public method of an object should always check preconditions in its input parameters or is it better to love responsibility to the caller and "trust the flow" ?
I'm not talking about obvious preconditions such as checking for null to avoid null reference exceptions, but I'm referring to business preconditions in method parameters. This typical happens in DDD Services that perform some kind of validation on input parameters and return an object containing a feedback about that validation.
As an example consider a class CheckPerson having a public method PerformCheck with a single parameter of type Person. Imagine there is a business rule saying that this check doesn't make sense for blonde persons.
In my opinion this check is important and method name should reflect this rule (something like PerformCheckForNonBlondePerson).
Should I add these checks, or should I trust the caller?
Yes you should!
You need to differentiate between input validation and preconditions. Business rules, as you describe them, can be applied in both.
Input validation happens at the system boundary. You expect input validation to fail in some cases. When that happens, you should indicate the error to the client with a useful description of the error.
Preconditions, on the other hand, are part of the contract of a method (or a whole component) somewhere within your system. You always want to be sure this contract is adhered to, because your implementation will probably behave incorrectly otherwise. Here, we use guards to enforce the preconditions. A guard should always pass. If it does not, it is always a programmer error (as opposed to a user error).
#theDmi thanks for sharing your point of view.
I totally agree with your position.
The context when I'm currently working is a team of three people, implementing a large application with a good deal of business logic and domain rules to be taken into account.
The main reason I don't agree with the "trust the flow and delegate responsibility to the caller" philosophy is that this force every developer which is going to make a call to a domain service to explicitly read the code of such a service and to have a good knowledge about the business requirement behind that code.
In my opinion, this is not realistic and furthermore this is an error-prone process.
Domain layer in large application is called by every piece of application logic we are going to write and leaving all the responsibility to the caller is simply too dangerous in my opinion. We don't currently use any kind of library to enforce preconditions check, but I know there are several options out there :)
Looking at the GoF patterns I find the similarities between State and Stategy pattern rather striking.
Both swap out polymorphic classes to modify behavior. Anyone else found the same?
What are the exact differences?
The state and strategy patterns are similar in the sense that both of them encapsulate behavior in separate objects and use composition to delegate to the composed object to implement the behavior and both of them provide the flexibility to change the behavior dynamically by changing the composed object at run-time. But there are some key differences :
In the state pattern, the client knows nothing about the state objects. State changes happen transparently to the client. The client just calls methods on the context, the context oversees its own state. Because the client is not aware of the state changes, it appears to the client as though the context is instantiated from a different class each time there is a change in behavior due to a state change. The object will appear to change its class as the official definition of the pattern states. The pattern is built around a well-defined series of state transitions. Changing state is key to the pattern's existence.
Even though the strategy pattern provides the flexibility to change behavior by changing the composed strategy object dynamically, mostly there is an appropriate strategy object already set for each context. ie even though the pattern provides a way to change the composed strategy object dynamically, there won't be much of a need for it. Even if it has to be done, it is the client that does the change. The client will call the setter method on the context and pass the new strategy object. Thus behavior changes are NOT transparent to the client and are initiated and controlled by the client. The pattern does not encourage a series of well-defined behavior changes like the state pattern. The client knows about the strategy objects and will usually set the appropriate strategy object in the context while creating it. The client controls what strategy object the context uses, but in the state pattern, the client knows nothing about the state object(s) that the context uses
For additional information pls refer the below link http://myrandomsparks.blogspot.in/2012/05/strategy-vs-state-pattern.html
The strategy pattern decides on 'how' to perform some action and state pattern decides on 'when' to perform them.
By using the State pattern the state-holding (context) class is relieved from knowledge of what state or type it is and what states or types that are available. This means that the class adheres to the open-closed design principle (OCP): the class is closed for changes in what states/types there are, but the states/types are open to extensions.
By using the Strategy pattern the algorithm-using (context) class is relieved from knowledge of how to perform a certain task (-- the "algorithm"). This case also creates an adherence to the OCP; the class is closed for changes regarding how to perform this task, but the design is very open to additions of other algorithms for solving this task
What is the best UML diagram type to use when trying to show how a class' behavior flows from one method to another?
I am trying to diagram existing code and the behavior I am looking at primarily involves private method calls, with a few calls to static objects outside the class. I don't feel that a sequence diagram would give the best detail in this case since the class in question doesn't interact with any other classes except for the very few static calls mentioned earlier.
What would fit best in this situation?
According to the UML Superstructure (http://www.omg.org/spec/UML), in the UML two kind of behaviors exist: emergent behaviors and executing behaviors.
An executing behavior is performed by an object (its host) and is the description of the behavior of this object.
An executing behavior is directly caused by the invocation of a behavioral feature of that object or by its creation. In either case, it is a consequence of the execution of an action by some related object. A behavior has access to the structural features of its host object. Objects that may host behaviors are specified by the concrete subtypes of the BehavioredClassifier metaclass.
Emergent behavior results from the interaction of one or more participant objects. If the participating objects are parts of a larger composite object, an emerging behavior can be seen as indirectly describing the behavior of the container object also. Nevertheless, an emergent behavior can result from the executing behaviors of the participant objects.
You can model behaviors by means of Activities or Interactions (actually you may also use state machines and use cases). Activities are more adapt to model executing behaviors while Interactions to model emergent behaviors.
Now if your class has many parts and its behavior you want to model consists in a "complex" interaction of its parts then probably an interaction diagram (sequence) may be the right choice. Otherwise, if the behavior you need to model, consists of a sequence of atomic actions an activity may be better. Consider in UML there is a specific actions to represent the invokation of a method (CallOperationAction) which takes as input pin the object reference you can retrieve by means of a dedicated action (ReadSelfAction). There is also an action to read an object attribute (ReadStructuralFeatureAction).
Also check the Foundational for Executable UML Models (FUML) http://www.omg.org/spec/FUML
While all of the previous answers are correct, I would like to add the option of using a State-Machine to define the behavior of the class. State machines allow you to show what is the current state of the class and how the state of the class changes as methods are called or events are received. Since you state that you are mostly modeling one class, I think the most important thing to show is what can be done (what method calls can be called) depending on the current state and how these method calls affect the state of the class. One think I really like about state machines is that they have relatively well defined semantics and also have ways to show information at different levels using composite and orthogonal states.
Broadly you have 2 choices (per #Silli's answer): sequence or activity diagram. I would probably have suggested sequence diag as first choice, however you say you don't think that's appropriate. Could you elaborate why?
Perhaps it's conditional logic? If so an activity diagram may be the better choice. It has more intuitive syntax for showing control flow than a sequence diagram. You could also show the static objects in separate swimlanes - so clearly differentiating calls to external objects. You can also illustrate parallel behaviour if that's relevant to you. Some good examples here if it helps.
hth.
I would recommend collaboration diagram (UML 1.x) renamed to Communication diagram (UML 2.x).
This may be better than sequence diagram, better because it may be more readable in your case.
A Communication diagram models the interactions between objects or parts in terms of sequenced messages. Communication diagrams represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system.
http://en.wikipedia.org/wiki/Communication_diagram
I'm having trouble wrapping my head around state-based functionality for an invoicing system we are currently building. The system will support calculation, manual approval, printing, and archiving of invoices.
At first I thought we should use the State Pattern to model this. An invoice would be the context, which delegates printing, archiving, etc. to its currently assigned state.
But this is obviously a bad idea, because the different states (created, approved, printed, archived) should not support the same operations. E.g., you shouldn't be able to print an invoice, which hasn't been approved before. Throwing exceptions for unsupported operations would be a violation of LSP. I found a general description of this problem here.
Does anybody have an idea, how to implement this appropriately?
PS: I'm aware that this might sound like some lame-ass homework assignment, but it's not; I need this for a real world system.
You're basically creating a workflow of application states, where at each state the available operations on an invoice change. The state pattern doesn't seem appropriate, but you can still use it if you also create some operations like boolean canPrint() that would have to be used before calling print(). print() would have a contract that allows throwing exceptions if canPrint() returns false. This way, subclasses wouldn't break that contract. Another option is to have a boolean tryPrint(), that will only print if it can, and return whether it printed.
But, if the states support mostly non-overlapping operations, then maybe the state pattern is not the solution. Take a step back and look for better ways, without trying to fit a specific pattern to your problem. One way is to create a separate class with the necessary operations for each "state": like CreatedInvoice, ApprovedInvoice, etc. These classes would only have the operations they support.
Chain of Responsibility Pattern might help you here.
Adding the how part and fixing the link.
There can be Calculator, Approver, Printer and Archiver classes which are handler classes. These can have processRequest() overridden from a parent abstract class. Invoice can be a class which is passed to each handler's processRequest() method. The advantage with using the pattern here is newer handlers can be added dynamically and chain links with sequence of handlers can be changed easily.
Whether the State Pattern is really appropriate to your situation is not certain, but if it's not, Liskov is not the reason. Throwing some sort of "invalid operation in current state" exception can be defined as possible and valid in the state interface, and then subclasses doing this do not violate LSP.
The classic example used for the State Pattern in the GoF Design Patterns book is a TCPConnection, which definitely has operations not supported or sensible in all states. You can't transmit on a closed connection, for example.
It's quoted from a report by Bjarne:
Encapsulation – the ability to provide
guarantees that an abstraction is used
only according to its specification –
is crucial to defend abstractions
against corruption.
Can someone explain this?
Thanks
Let's say you have a class with public methods that you must use to perform some action. The specification of the class say that, in order to do this action, you must configure the class in a specific way (call this method, set this property, etc).
The problem with situations like this is that it might not be clear what needs to happen or in what order. So the API for the class is hard to use and confusing for the majority of developers.
With encapsulation, you can "encapsulate" not just the class but the algorithms to use it within a second class. This second class sets up the original one, configures it, and manages its lifetime. It allows you to access the API without needing to know how to use it correctly, as the encapsulating class takes care of that. This is sometimes called the Facade pattern.
Your quote also says "is crucial to defend abstractions against corruption." What this means is that when you abstract some process into a class, different implementations of that process should not require the abstraction to be handled differently.
For example, you might have two implementations of a report writer class. You should be able to treat each of them exactly the same without ever knowing how they are implemented (the meaning of abstraction). However, if one cannot be run in a multithreaded apartment state (MTA), you have to "know", before you use it, that it is time to transition to an STA thread. This magical "knowing" is required by the implementation of the class. This is a "leaky abstraction."
With encapsulation, you could prevent this "leak" by, within the encapsulating class, making the transition to an STA thread within the encapsulation, preventing the abstraction from leaking details of its implementation.
It means that the object grant premission only to certain things it needs to expose, and deny you from using data it doen't want you to use.
The most classic example is properties:
Yout fields will be private (or protected).
If you would like to expose them for read or write, you'll add a getter\setter, accordingly.