Posts

Showing posts with the label Object-Oriented Design

Java Keywords (Part VII): Loops

The Java keyword list has 21 keywords grayed out. That puts us at 42% of keywords covered by these series of articles. Amazingly, that's almost enough knowledge to built simple applications. I suggest that if you have not read any of the articles in Java Keyword series, go back read them before proceeding further. Also, go back and read the one about Data Types. All of these articles are from September 2018. That should help you find them quickly. You can also use the "search" option at the top of this page. This article will cover the keywords used for looping: for , do , and while , as well as the keywords used to change the flow of loops: break and continue . 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

Java Keywords (Part VI): If/Else Flow-Control Statements

The Java keyword list has 19 keywords grayed out. That puts us at 38% of keywords covered by these series of articles. Amazingly, that's almost sufficient to built simple applications. I suggest that if have not read any of the articles in Java Keyword series, you read them before proceeding further. Also, go back and read the one about Data Types. All of these articles are from September 2018. That should help you find them quickly. This article will only cover the if and else keywords. 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

Java Keywords (Part V): Classes vs Interfaces

This is not a break in my Java Keyword series. This is a continuation of the series that focuses in two things. The primary goal is to explain what an interface is (which differentiates them from classes) and go over a few examples that illustrate why interfaces are not just needed, but essential for robust and reusable software solutions. Because of new improvements introduced with Java 8, I will also introduced the concept of default methods; although will do so in a separate article... A second part to this one. I feel doing that is necessary for keeping the scope of this article as narrow as possible for the sake of simplicity and clarity. Interestingly enough, how to use interfaces will also be covered in a separate article where I will be discussing the Object-Oriented concept of inheritance. In the new article, I will be emphasizing in the keywords extends , implements , and super . The Java keyword list has 18 keywords grayed out. This article will only cover th

Java Keywords (Part IV): Classes and Objects

This is not a break in my Java Keyword series. This is a continuation of the series that focuses in two things. The first part will focus on the anatomy of a class, which I have covered (somewhat) already. The second part focuses in the concept of a class constructor. Lastly, and as a related topic to that second part is how to invoke class constructors and explains what happens when this occurs (which I have somewhat covered already). View this article as a way to tie loose ends before moving on to other topics. In the end, I will wrap up the keywords class and the new operator. 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

The REAL Builder Pattern

Image
I have been reading about Design Pattern lately, and I ran across some articles about the Builder Pattern that are not accurate at all. Because of that, I decided to write a short article about what this pattern is and how to properly implement it. I will start by providing a short description of what this pattern is. I will follow that with some context by providing hypothetical usages for this pattern, and conclude with a (hopefully good) code example. What is the Builder Pattern? Even these bad articles got one thing right: The Builder Pattern is a Creational Pattern . This means that the pattern's main goal is to provide a reusable solution for creating objects. You may ask, why are there more than one creational pattern? Isn't invoking a class constructor enough? Well... yes and no. Why use Builder Pattern? Experts (people who know more than me) have determined that using one of these creational patterns is preferred over invoking the constructor of a c

Using a State-Machine to Control a Wizard

On previous articles, I wrote about real-world usages for the State and Singleton design patterns. I also wrote about using these two patterns together to create a state-machine. Now, I am going use that state-machine to control a Wizard. I am going to use Java Swing to create the User Interface classes. To create my interface using Java Swing, I am going to create three panels for contents, one panel to provide the navigation controls, and a frame to hold it all together. It will be a simple example, but one you could easily expand should you have the need to create your own wizard. The Frame The frame is the application window. I will not go to much into details about the Java JFrame class, as I assume you have some basic knowledge of Java and Java Swing. If you don't much about Java Swing, I suggest you visit this Oracle tutorial on how to create frames . Main.java public class Main extends JFrame { private CardsPanel cards = new CardsPanel(); private Navi

Combining State and Singleton Patterns to Create a State-Machine

Image
In my previous two posts, I discussed real-world applications for the Singleton and State design patterns. In this article, I am going to illustrate how to combine both of these patterns to create a simple wizard. Simple State Design Pattern Implementation In a typical implementation of the design pattern, State is either an interface or abstract class, with each state of the state machine being Singleton classes. My example is going to be slightly different. I will implement the state machine using a state interface and Java enums to implement the Singleton. Using an enum is the recommended way to implement a Singleton in Java. First, let's come up with a simple state interface State.java public interface State { void goNext(Context input); void goPrevious(Context input); } Now that we have an interface defined, we can derive as many states as we need. For this example, three states should be sufficient to demonstrate the wizard's functionality. Jav

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

Applying the Singleton Design Pattern to Real-World Scenarios

There are many who believe that the Singleton pattern is an anti-pattern. By the title you probably assumed I am not one of those people, and you will be right. I believe the term "anti-pattern" is being used for cases where a pattern is not being used for what it was originally designed for or just implemented incorrectly. I am going to try to keep this short. But I need to explain what the Singleton pattern is before I provide a real-life example of its applicability. The Singleton pattern is one of the original Gang of Four Design Patterns . The Singleton pattern falls under the Creational Pattern category. This means that the purpose of the Singleton pattern is to create objects. The creational purpose of the pattern is to ensure that one and only one object is instantiated in the life of the application. By definition, an anti-pattern is a pattern that is usually ineffective and highly counterproductive. So, why do classify Singleton as an anti-pattern? I fou