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.

Chapter 4 of The Clean Coder starts to explain some practices when it comes to coding.  Many do’s and don’t’s, some myths busted, and general good practices are told.  It tries to explain that coding is hard and that it shouldn’t be done when one is tired.  Not only that but it shouldn’t be done when you can’t focus at all.  Not being able to focus on your coding is a route to disaster and prone for mistakes.  It even claims that when you are in “the Zone”, a time where you are coding quickly and nothing is stopping you, it’s a mistake waiting to happen.  Although coding quickly can yield some results, it’s never perfect.  I’ve experienced this myself even.  When coding quickly to try and make a due date for assignments, there are usually always errors whereas work that is done over time and at reasonable times, it’s almost always better.  The book then goes on to explain about how music and other distractions can also causes errors as well.  Although music might help some, the book claims is puts coders into “the Zone” which is where you don’t want to be.  You want to be in complete and total control over your coding, not someone else in your head.

Chapter 5 on the other hand talks about something I’ve been told many many times before, and it’s still something I have yet to fully experience or see the point to, and that’s Test Driven Development.  I understand the concepts behind it and how it can help, but I just don’t understand why you want to write the tests before you have actual code to test.  I want to start with a plan of what I want to write first, figure out what I want to code, and then attempt to start it and THEN test it.  Once I have something worthy of testing, I test it.  Why would I want to write a test on something that I haven’t even created yet? When creating the program for the test I created, I might even change how it works, which means I have to change how the test works anyways!   It just seems silly to me, but to each their own I suppose.

The only thing that I agree with with TDD is that you want to write your tests alongside your code.  You wrote something that needs a test? Write a test for it now.  That makes perfect and reasonable sense to me.  Don’t save writing all the tests for last.  By writing your tests as you go, and even testing them, you can see any problems on what small problems you are currently working on, and can fix it now before it can lead to greater errors later on.

Anyway, in regards to what was actually in the book, it just lists some practices on how to conduct TDD.  It explains the three laws and how the three laws can lead someone to better structured code rather than a mess of code.  However, one needs to practice at it because following the three laws won’t yield perfect results.

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

The next couple of chapters in Clean Coder deal with communication in terms of saying yes and no.  Obviously in a work environment, one is prone to say yes to their boss all the time; but that is not what a professional does.  A professional needs to learn how to communicate effectively with their boss and peers and explain how long something will take.  Saying that you’ll try is not good enough, your boss might expect a 100% working product and you might only give a 50% working product, resulting in disappointment and anger.

However this doesn’t mean that you should say no to everything, you have to do something while at work, it’s your job! And this is what chapter 3 goes more in depth about, saying yes.  When you say yes you need to be definitive about what you are saying yes you.  Say yes to something that you know for a fact that you’ll get done, something that you know will be 100% working by the date you defined.  There should be no lack of commitment when saying yes.  Saying yes as a professional means that you are taking full responsibility of the task and making sure that it is functioning to the standards that it needs to be at, and possible even higher.

Overall, when it comes to taking on tasks in a work environment, you shouldn’t take on every single task that is asked of you, you will be overbooked, and I agree with this.  If I kept saying yes I would more likely than not know what is the most important task that needs to get done.  But not only that, I probably would’t get some of the tasks done at the right time.  However I do need to do work.  When choosing tasks to do, I should be confident in what I’m working on and know roughly when it will be done.  I could let my team members know how long it would take to get something done and when I would have a complete product working.  As in the previous chapters, being professional is about taking responsibility in your work.

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