Skip to main content

Java Keywords (Part XXIV): native

Java keyword list abstract continue for new switch assert default goto * package synchronized boolean do if private this break double implements protected throw byte else import public throws case enum instanceof return transient catch extends int short try char final interface static void class finally long strictfp volatile const * float native super while Keyword marked with an asterisk (*) are keywords that, although valid, are not used by programmers. This is the last chapter of the Java Keyword series. This is probably the keyword I have used the least. In my 20 year career as a software developer, I have used this keyword once, and that was to make some addition to legacy code. The keyword native is a method modifier . Basically, it is a keyword that can only be applied to methods. According to the Java Language Specification (JLS), A method that is native is implemented i...
Post a Comment

Applying the State Design Pattern to Real-World Scenarios

In my previous article, I wrote about the Singleton Design Pattern and a possible real-world application for it. In this article, I will do the same for the State Pattern. In addition, I will use the example from my previous post to implement the states in my state machine. But I cannot start showing examples unless I help you understand first the basic concept of this topic.

The first question I must answer is what is the State Design Pattern.

What is the State Design Pattern?

The State Design Pattern is one of the original Design Patterns proposed by the Gang of Four (GoF). The pattern falls under the Behavioral classification or category. This means that the purpose of this design is to come up with a scheme to control the behavior of objects. Specifically, it is used to model behavior of objects that must behave like a state machine. A state machine is a device that can be in one of a set number of stable conditions depending on its previous condition and on the values of its inputs, or stimuli.

When to use State Pattern

To understand this definition, consider a turnstile. A typical (simple) turnstile is a machine that can be in one of three states at any given time: locked, unlocked, and rotating. The transition from one state to another is predefined and can only occur if a proper stimulus or input is applied. For example, to transition from locked to unlocked, the turnstile must receive a coin. Assuming that the turnstile doesn't have some sort of time out feature, it will remain on that state until a proper stimulus or input is received. From this state, a push is the expected input to transition from unlocked to rotating. The turnstile will remain in the rotating state until one revolution is achieved and then will return to the locked state; where it will remain until a valid input (coin) is received and so on...

From the example above, you can see that a state machine has:

  1. A predefined (finite) number of states
  2. Predefined condition(s) to trigger a transition
  3. Specific path(s) to the next state - and maybe to a previous state
State machines are definitely procedural. That said, your code doesn't have to be. But you can use object-oriented constructs to achieve that same behavior and that is what the State Design Pattern does. I have used the state pattern many times in my career. From all of the real-world applications I have developed in the past using this pattern, the one that makes the most sense is using it to control the behavior of a wizard.

Part III of this blog will be the conclusion. In that blog, I will show some UML diagrams as well as some code examples on how to create a simple wizard using Singleton and State Design Patterns.

Stay tuned!

Labels:

Comments

Post a Comment

Popular posts from this blog

Implementing Interfaces with Java Records

If you have not read my article on Java records and do not know about this topic, please read my blog titled " Customizing Java Records " first and then come back to this one. Now that you know how to customize Java records, implementing an interface using Java records should be very easy to understand. If you don't know about interfaces in Java, you can read more on my article about interfaces. The recipe for implementing an interface is simply an expansion of what you learned in my previous blog on how to customize a Java record. Following our Rectangle example, let's create an interface with the same two methods we used before. public interface Shape { double area(); double perimeter(); } Now, let's further customize the previous example by doing two things: Add implements Shape at the end of the record declaration (after the record constructor), and Add @Override to the existing methods to ensure these methods com...
Post a Comment
Read more

Customizing Java Records

If you have not read my article on Java records and do not know about this topic, please read my blog titled " Java Keywords Addendum: The Java Record " first and then come back to this one. What is a customization of a record? A customization of a record is simply the addition of code inside the body of the class. Before proceeding further, let's recap important aspects of a Java Record: Java records are immutable Because of item 1 above, you cannot add new fields unless defined in the record constructor Java records already override: Object#equals(Object) and Object#hashCode() , and then override Object#toString() You could redefine overridden methods as part of your customization if you would like. For example, if you want a fancier implementation of the Object#toString() method, you could do so. Let's look at our first customization example. Using the example from my previous blog, public record Student(...
Post a Comment
Read more

Object-Oriented Programming Basics: What is in a Class?

EDITORIAL NOTE : This article was published briefly back in 2016 and quickly set back to draft because I wasn't happy with its contents. It is a shame that it was taking me three years to revisit this topic and work on a new and improved version. At least, I'm hoping it will be to the liking you the reader. Keep in mind that the opening paragraph will still read as if I just wrote it for my (former) students at Texas Wesleyan. I started working on lecture on the topic of Object-Oriented (OO) Programming by gathering some material, old and new, when I realized this might be good and simple post for my second attempt at blogging. To be completely honest, in the 8 hours I spent collecting information and preparing material for this week's lecture, I realized I still made some of the mistakes I am about to blog about. I am actually hoping I can write a series of postings regarding Object-Oriented Programming (OOP). But to do so, I must start from the very beginning. ...
2 comments
Read more