The standard way of creating an object is to instantiate a concrete class directly with the new operator:

SomeClass sc = new SomeClass();

One of the drawbacks of using the new operator to create an object is the need to specify the type of object to create. Specifically, it creates a dependency between your code and the class or type of object created. Sometimes a more general solution is needed, one that allows control over when an instance of an object is created but leaves open or delegates to another class the specific type of object to create.

Decoupling object creation from object use results in code that is more flexible and extendable.

Also, the advice “program to an interface, not an implementation” also applies to object creation. You could create an object with the new operator.

class ClientCodeC{

public clientCodeC(){

SupportingClass sc = new SupportingClass();

}

}

However, the reference to concrete class SupportingClass at line 3 is an example of programming to an implementation. If there is nothing about clientCodeC that requires an instance of SupportingClass, it is usually better to program to an abstract interface that will result in the creation of an instance of SupportingClass or another type that is compatible with the client code.

But how do we do that? That is precisely the problem solved by the Factory Method design pattern.

The Factory design pattern has four main components. The class Creator declares a factory method createProduct(). createProduct() returns an object of type Product. Subclasses of Creator override the factory method to create and return a concrete instance of Product.

There are many forms. Here’s one.

Here’s another.

Notice how it differs from the structure diagram in the previous example. In the previous example there is a one-to-many relationship between concrete creators and concrete products. With iteration in Java there is a one-to-one relationship between  concrete collection classes and concrete iterators. Both are valid forms of the pattern.

But what happens when we have multiple store franchises. Let’s say that we have two stores, one wants to make NY style pizzas and the other wants to make Chicago style pizzas.

Now we’re in a situation where we are going to need either a much more complex factory or two different factories to make the two different styles of pizza or we’ll have to put all the logic for creating the different pizzas back into the store. All this options make for a more complicated code, and many more places where we’ll have to change code if we add new pizza types or change a topping.

The current implementation, below, also violates the open/closed principle. There is no way to extend the current solution to work with other credit card processing services without modifying the code.

The store needs to use the same order pizza method so that the prepare, bake, cut, box the pizzas in the same way, but have the flexibility of creating different styles of pizza objects, one creating NY style pizzas while the other creates Chicago style pizzas. What we want is to have two different kinds of pizza stores that use the same time testing algorithm to make pizzas but that can make two different kinds of pizzas. But without being dependent on the concrete types of pizzas on any way.

To create our store franchises, we’ll change the design to use the Factory Method Pattern.

The Factory Method Pattern defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Let’s see what that means by looking at the new design for the pizza store.

First we’re going to change the pizza store class so that it is an abstract class. All the pizza stores in the franchise will extend this class. To make sure that all the pizza stores use the same method for preparing pizzas for customers, in other words the same algorithm, the pizza store abstract class will implement the order pizza method. This is the shared code all the stores use for preparing the pizza, no matter what store we’re in and what type of pizza it is.

However, the two pizza stores that extend this class, NY store and Chicago store, will implement their own create pizza methods. That way each store gets to decide what kind of pizzas it will make. The NY store will make NY style pizzas while the Chicago store will make Chicago style pizzas. This is what is meant in the factory method pattern definition, when we say the factory method pattern lets a class defer instantiation to subclasses. Here the abstract class pizza store is deferring instantiation of concrete pizzas to the individual pizza store that extend it.

The pizza class is basically going to be the same, but now we’re going to have many different types of pizzas. A set of pizzas for the NY style pizza store and a set of pizzas for the Chicago style pizza store. The NY pizza store will be responsible for creating the NY style pizza and the Chicago style pizza store will be responsible for creating the Chicago style pizzas.

To create a pizza, we’ll first instantiate the kind of store that we want. Imaging choosing between walking into a NY style pizza store or a Chicago style pizza store. Once we’re in the store, we can order a pizza. Remember this method is implemented by the abstract class pizza store. So, no matter which pizza store we’re in when we make an order, we’re guaranteed to get the same brilliant pizza making algorithm to produce quality pizzas.

The first step in the order pizza algorithm is to create a pizza. The create pizza method is implemented by the individual stores. So, if we’re in a NY style pizza store we’ll get the method implemented by that store. We pass the type of pizza to the create pizza method. This method creates the right type of pizza based on the type and once it is returned to the order pizza method in the store, the order pizza method can prepare the pizza to the customer.

Here’s our main class.

Recall that in the Simple Factory idiom, we first created a factory and then passed the factory to the store. We no longer need the factory because the pizza stores are created the pizzas directly. Remember that the pizza stores order pizza method, implemented in the pizza store abstract class creates the kind of pizzas that we want depending on which store we call the method on.

PizzaStore is implemented as a Factory Method because we want to be able to create a product that varies by region. With the Factory Method, each region gets its own concrete factory that knows how to make pizzas which are appropriate for the area.

Works Cited

Burris, Eddie. “Chapter 8 Factory Method.” Programming in the Large with Design Patterns. Leawood, Kan: Pretty Print, 2012. 110-122. Print.

Freeman, Eric, and Elisabeth Freeman. “Chapter 4. The Factory Method Pattern: Baking with OO Goodness.” Head First Design Patterns. Sebastopol, CA: O’Reilly Media, 2005. N. pag. Print

From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.

The goal of the simple factory idiom is to separate the process of creating concrete objects to reduce the dependency of the client from the concrete implementations.

To implement the simple factory we need three things:

1. A factory, the pizza factory.
2. The products the factory makes which are the pizza objects.
3. The client that uses the factory, which is the pizza store.

So, let’s take our pizza creation code, encapsulate it, separate it. And we’ll encapsulate it in a class called Factory.

Why a Factory? Because this is a class whose sole responsibility is creating pizzas — it’s a pizza factory.

To do that we’re going to take this conditional code for creating pizzas and put it into a separate class, in a method name createPizza. Each time we want a pizza, we’ll call the method, pass it a type, and the method will make a pizza for us and return an object that implements the pizza interface.

Now all this creation will be in a separate class, nicely separated form the restaurant code. So, let’s integrate this with our client code or restaurant code. Let’s assume that we’ve created a factory object already. And call it to create the pizza, passing it the type variable.

Our order pizza method no longer has to worry about the concrete type of the pizza. It could be a veggie pizza, a cheese pizza, or a pizza we haven’t even heard of yet. We know whatever type gets returned by the factory, it implements the pizza interface. And that’s all we care about.

So we call this object design the simple factory idiom.

We start we the client of the restaurant, the pizza store. And then we have our factory. The factory is the only place the concrete types of pizzas are known.  And then we have the products, what the factory makes or pizzas, and there could be many concrete types of those.

To generalize this a bit, we could look at the same diagram without pizzas.

And here we have the client, a factory, and a set of products that implement a common interface.

Now, one thing to note. This is not a full fledged official pattern. It is more of an idiom that’s commonly used. That said it is the first step to understanding some of the more common design patterns.

And now we’ll put everything together in a main class called the pizza test drive  which will create a pizza store and use it to create pizzas.

From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.

Context: Engineers look for routine solutions before resorting to original problem solving. Design is probably the most challenging activity in the software development life cycle. There is no algorithm for deriving abstract solution models from requirements. The best the discipline of software engineering can offer are methods, techniques, heuristics, and design patterns.

Solution: A design pattern is problem-solution pair. Design patterns are discovered rather than invented. Design patterns are paragons of good design. A design pattern, and more generally a design, is an abstraction of an implementation. What is being reused is the structure or organization of the code. The solution provided is the design and not the code. A design pattern is not a concrete design or implementation, such as an algorithm that can be used as-is, but rather a generic solution that must be adapted to the specific needs of the problem at hand. The purpose of the design process is to determine how the eventual code will be structured or organized into modules. The output of the design process is an abstract solution model typically expressed with a symbolic modeling language such as UML.

Pros:

• Studying design patterns helps to develop the intellectual concepts and principles needed to solve unique design problems from first principles. Design patterns define a shared vocabulary for discussing design and architecture. Catalogs of design patterns define a shared vocabulary at the right level of abstraction for efficient communication of design ideas.
• Knowing popular design patterns make it easier to learn class libraries that use design patterns. For example, the classes and interfaces that make up the Java IO package are confusing to many new Java programmers simply because they aren’t familiar with the decorator design pattern.
• Knowledge of design patterns simplifies software design by reducing the number of design problems that must be solved from first principles. Design problems that match documented design patterns have ready-made solutions. The remaining problems that don’t match documented design patterns must be solved from first principles.

Cons (not really! lol):

• Applying design patterns is easier than solving design problems from first principles but their application still requires thoughtful decision making. You must be familiar enough with existing patterns to recognize the problem is one for which a design pattern exists.

Here’s the important things to remember:

• First, design (and more generally engineering) is about balancing conflicting forces or constraints.
• Second, design patterns provide general solutions at a medium level of abstraction. They don’t give exact answers, and at the same time, they are more concrete and practical than abstract principles or strategies.
• Finally, patterns aren’t dogma.

Here’s where Kids get Confused:

Intent Matters!!!!!

Design patterns are NOT distinguished by their static structure alone.

Can you tell me which represents state pattern and which represents strategy pattern?

It is of course impossible. What makes a design pattern unique is its intent? The intent of a pattern is the problem solved or reason for using it. The intent of State pattern is to allow an object to alter its behavior when its internal state changes. The intent of the Strategy pattern is to encapsulate different algorithms or behaviors and make them interchangeable from the client’s perspective. The structure is the same for both solutions.

Works Cited:

Burris, Eddie. “Introduction to Design Patterns.” Programming in the Large with Design Patterns. Leawood, Kan: Pretty Print, 2012. 11-33. Print.

From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.

Nowadays top tech-companies are willing to pay huge amounts in recruiting capable architects, developers and designer who can deliver software that is elegant. Elegant software is software that is easily testable, easily extensible, and are free of defects. In today’s day and age, good design of software is critical to the long-term sustainment of the software in the market.

Thus, a software developer must be skilled at the respective areas to be able to develop elegant software. And the only way to acquire these skills is by experience, a lot of it, around 10-15 years of working as a designer or architect would be ideal. But nowadays businesses can’t afford to wait that long to get a developer of that caliber. They want schools to produce these engineers right of their ‘assembly line.’ As such an alternative route is needed. Another way to become a skilled developer is to study design patterns. Design patterns are knowledge in the form of a template that could be used to solve general repeatable solution to a commonly occurring problem. But it is important to note that a design pattern is not the finished product that can be directly translated to code.

But design patterns have its fair share of criticism as well. Very often using design patterns leads to inefficient solutions due to duplication of code. Thus, care should be taken in this regard.

Works Cited

https://sourcemaking.com/design_patterns

Burris, Eddie. Programming in the Large with Design Patterns.

From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.

In 1970, Dr. Winston Royce a Computer Scientist from Austin, Texas, published a paper titled “Managing the Development of Large Software Systems.” Dr. Royce criticized the software development methodology of the time, the Waterfall method, which utilizes a sequential approach to software development. He asserted that software should not to be developed like an “automobile on an assembly line,” where every phase of the project must be completed thoroughly before the next phase can begin, where the process must be well thought-of and planned beforehand. This used to be traditional method – the waterfall method. But this had some serious setbacks. Firstly, conflicts arose sometimes between adjacent departments due to their inability to communicate effectively amongst the various departments. Royce argued that this lack of communication might hinder the robustness and functionality of the product being assembled. Secondly, the methodology of the traditional method means the architect[s] must outline every requirement and specification before the product can go through any of the phases – such as the coding phase, the design phase, the testing phase. And lastly, teams have only one chance – in most cases – to get things right. There is no going back to a phase if the product is found to deviate from its intended functionality.

These pitfalls gave rise to a new methodology, the Agile methodology. In agile, every aspect of the project and every phase of the project is revisited multiple times throughout its lifecycle. And each phase has many repetitions, professionally called iterations, and each of these iterations lasts for only about a couple weeks. This gives developers more opportunities to revisit something that was missed or something that was not well-thought-of/planned.

Instead of committing to market a piece of software that is guaranteed to be released at a specified data regardless of its robustness or functionality, agile empowers teams to continuously re-plan their release to increase its value in the marketplace when and where it is released.

This is how software ought to be developed, but, unlike what organizations may claim, they aren’t doing anything close to Agile’s actual definition. Because the human-being is a fickle-minded creature, often deviating from its given job due to irresolution and instability.

As such, the traditional method works fine for starters.

From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.

Decision tables are one of the more powerful functional testing methods, partly due to their logical decision-making structure. Here is how they work:

• Conditions are identified as inputs; actions are identified as outputs.
• In certain cases, the conditions are equivalence classes.
• For every possible combination of inputs, the output is identified and marked.

The size of a decision table is greatly impacted by the choice of conditions. Thus, the conditions have to be identified wisely.

Pretty straight-forward thus far. Decision tables involving equivalence classes have a characteristic appearance.

But people often make mistakes when the conditions refer to equivalence classes. Particularly when the equivalence classes are mutually exclusive, and are disjoint sets. As such, it is not possible to have a rule where two entries are true. For a particular rule if one equivalence class is marked true, it doesn’t matter what the other classes are marked – don’t care entries. Thus, the number of rule count increases.

This creates a problem.

Let’s say we have a decision table as shown below, where c1, c2, c3 refer to conditions and a1, a2, a3 refer to the actions. And we have Rule 1-4 identical to that of rule 9. Let’s say we have two versions of this table. Although version 1 is redundant, it does not have a problem. In the second table there is a problem. Because, in addition to being redundant, the two redundant rules (1-4) and 9 are not identical – their action portion differs.

   Frist Version.                                                   Second Version

This problem of redundancy and inconsistency creates tremendous strain on the part of a developer. In cases such as that of version two, two observations can be made:

1. Rules 1-4 are inconsistent with that of rule 9.
2. The decision table is nondeterministic.

Here is the bottom line: Care Should Be Taken When Do-Not-Care-Entries Are Used in A Decision Table.

This is the drawback of decision-table based testing, because of the dependencies in input domain. On the other hand, the benefits of decision-based testing are that indiscriminate selection of input values from equivalence classes as done in other testing methods such as boundary-value testing (this is done when the variables are assumed to be independent) are not made here. In a decision table, impossible rules are emphasized with the use of don’t-care-entries and the use of impossible-actions.

In summation, decision-table based testing should be used for applications that indicate these characteristics:

1. Prominent if-then-else logic.
2. Logical relationship among input variables.
3. Calculations involving subsets of the input variables.
4. Cause-and-effect relationships between inputs and outputs.

Works Cited

Jorgensen, Paul C. “Decision Table Based Testing.” Software Testing: A Craftsmen’s Approach, 4^Th Edition. New York: Auerbach Publications, 2013. Safari Books Online. Web. 7 Mar. 2016.

From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.

Hello visitor,

This is my first post! I am a computer science junkie and I’ll be posting the fascinating things I learn related to my field.

I love hearing your opinions and thoughts on my posts. So please leave a comment below!

Buvaneshwaran T

From the blog CS@Worcester – thewisedevloper by thewisedeveloper and used with permission of the author. All other rights reserved by the author.