Using the Simple Factory design pattern is a lot like making cheesecake

Software developer Sihui Huang, writing for the blog freeCodeCamp, explains the simple factory design pattern in terms that most people can appreciate – cheesecake.

Huang walks us through the basic steps in a simple factory for creating cheesecake. Starting with a number of his favorite types, he creates a makeCheeseCake() method which calls cheesecake.makeCrust, cheesecake.AddLayers, etc. The makeCheeseCake() method uses the type of cheesecake as a parameter, and calls the the steps to creating a cheesecake that all different types have in common. No matter what kind of cheesecake you are making, you still need to make the crust. So the makeCheeseCake() method is only concerned about the steps required in making any kind of cheesecake, it doesn’t care about what flavor the particular instance is. Huang describes this concept, as we have in class, as encapsulating what varies.

So Huang goes on to create a cheesecake factory class that handles all the different classes of cheesecake we can possibly create, and returns the appropriate cheesecake type by a createCheeseCake() method inside the factory class. The trick is that when you call the makeCheeseCake(), a new cheeseCakeFactory object is created, and uses the createCheeseCake method to determine what type the cheesecake is. So now the MakeCheeseCake() method does not need to know at all about what kind of cheesecake it is creating.

By separating the parts of a program that stay the same from those that vary, we can simplify adding and modifying different types of an object (in this case cheesecake) by adding a new class and adding to the cheeseCakeFactory class. No code has to be rewritten to accommodate for changes and removals of types of cheesecake.

Personally I enjoy Huang’s analogy to elaborate on the simple factory design pattern. Being able to separate varying parts of a program from parts that never change makes our code more understandable, coherent, and easy to modify. And the idea that a “factory” can handle the details of initializing different types of objects instead of having separate implementations for every object type is good design, and I think the cheesecake factory example is a good metaphor for encapsulation

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

For this week’s blog post, I chose this blog by Lucie Saunois. It talks about the differences between Black box, Grey box, and White box testing for software or applications.

Black Box Testing

Black box testing reviews only the functionalities of an application. Testers do not really know the internal structure of the application. Testers typically have a “user” profile. This method aims at checking if the final stage of the application works like its supposed to. Common things the tester would look for in a Black box testing are missing or incorrect functions, interface, performance, program initialization, and external database access errors. To do this test, each different user has their own scenario to test, and all functionalities must be tested.

White Box Testing

White box testing reviews the functionalities of an application as well as its internal structure.  All of the internal components of the application are tested through the source code. Testers have a “developer” profile and not a “user” profile unlike in Black box testing. White box testers need to have competence in programming since they need to understand the source code. It is mostly done in the developing stage of the application. Therefore, it allows them to test the data flow and the handling of exceptions and errors. Scenarios for this test are created by the testers based on the source code. Testers only check if the code produces the expected results.

Gray Box Testing

Gray box testing is a compilation of both Black and White box testing. Gray box testing tests both the functionalities and the function of an application. In this test, the testers know the functionalities and also the internal structure of the application, however, they do not have access to the source code.

This blog explaining the differences between each kind of testing is really easy to follow. The way they were describe was easy to understand. She also wrote about their benefits and drawbacks of each method of testing. I really find her examples interesting towards the end of the blog where she uses an analogy by comparing it to testing a car system. I think finding blogs like these would help anyone understand the different testing methods out there, it is simple but very informative.

From the blog CS@Worcester – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

Ever since I picked up my first Java book and read through it, one thing always stuck in my mind when it came to writing any program and that is to not repeat yourself when you don’t have to. Leonardo Brito wrote an interesting piece, “Don’t obsess over code DRYness”, and he gave a few good points on why we shouldn’t try to make our code as complex as we can. He starts off by saying that we, as humans, are good at pattern recognition but sometimes we over-do it. He uses the example codes below:
____________________________________________________________________________
# Example 1
class Car
include Checkups

def maintenance_10k
check_break_fluid
check_battery_terminals
check_engine_oil
end

def maintenance_30k
check_break_fluid
check_battery_terminals
check_engine_oil
check_spare_wheel
end

def maintenance_50k
check_break_fluid
check_battery_terminals
check_engine_oil
check_spare_wheel
check_gearbox
end
end
____________________________________________________________________________
# Example 2
class Car
include Checkups

def maintenance_10k
basic_maintenance
end

def maintenance_30k
basic_maintenance
check_spare_wheel
end

def maintenance_50k
basic_maintenance
check_spare_wheel
check_gearbox
end

private

def basic_maintenance
check_break_fluid
check_battery_terminals
check_engine_oil
end
end
____________________________________________________________________________
After DRYing the code we see that it produces a new method called basic_maintenance while the original maintenance method conveys exactly what the method is expected to do. He then added a change such that we no longer need to check the break fluid on the 10 thousand miles checkup, so now we must remove the method check_break_fluid from basic maintenance and only add it to the upper maintenance methods. What he was trying to illustrate is that although one set of code was easier to read and follow, a simple change could have us altering out code in more ways than we’d like.

Brito talks about the trade off between some duplication over the wrong abstraction because overly DRYing your code could result in more confusion than simply repeating SOME code which is where he introduced another concept: DAMP – descriptive and meaningful phrases. The purpose of these two terminologies is to guide is to write better code and not going to any extremes.

I found that the concept of over DRYing your code interesting because I never thought about it that way and that there was a such thing. I’ve heard of DRY but never DAMP so I found that amusing how they’re opposite from each other. Looking back at my projects I feel as though I stand somewhere in between both concepts. I try to not over-do simplifying yet at the same time I make sure I apply DRY when necessary. I agree with what the author said about repeating sometimes to make it easier on yourself in the end.

Thank you for the read!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

For every person, there are things they like and things they don’t. One such thing for me is testing my code. Is it laziness? Is it the fact that I’m awful at it? I’m not particularly sure why but in “5 Reasons why you should test your code” by Frank van Wijk, he talks about five important reasons on why we should always test our code.

Reason number one: Regression testing. The example he gives is that your code is fully functional and working but then one feature breaks in your code and now you’re left staring blankly at your code. Given that if you have 100% code coverage, you know there is a fully functional test suite. For example, you run the test suite, then you modify some parts of your code and then you run the test suite again. Now if tests are failing after the modification, there is an assertion done for this case. This is good because after every modification or as your program becomes more dense you could repeat this process each time to get rid of newly formed bugs.

Reason number two: Improve the implementation via new insights. After you finish your writing your program the first thing you might want to do is walk away grab a beer and reward yourself but before doing so you should write start writing tests for your methods. If you find that it is difficult to write tests for your methods then in may be an indication that there is room for improvement in the way you wrote your methods.

Reason number three: It saves you time. Although it takes up a huge chunk of your day writing tests for your code, in the long run it would actually save you time. The reason being, if you refactored your code, your tests should catch most of the bugs and allow you to fix it without having to sift through the entire program searching for what went wrong.

Reason number four: Self-updating documentation. There are many ways to understand code; read comments, read the implementation, or by reading the tests. It serves as a type of documentation that allows the reader to know what is suppose to happen.

And the final reason Wijk gives is because it is fun.

For the most part I found this blog quite fun to read because the author made a few valid points. Writing tests may be a pain but in the end it does make you a better programmer and ensures that there is less room for errors. I know my biggest weakness is testing my code because I never have in the past and moving forward I will start to.

Thank you for the read!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

I’m a Computer Science major, about to graduate this year, without a real understanding of where to go after my degree. Since my future is fairly open, I was curious to research the professional QA field and how some testers got their start in the industry. After a quick google search, I followed the link below and found some helpful insight from current professionals on the topic.

https://techbeacon.com/6-new-careers-paths-ideas-software-qa-testers-professionals

Firstly, it surprised me to find out that many QA testers ended up in their positions without a lot of intention. To quote QA professional Shelley Rueger, “I don’t know that there is a standard way to start in QA.” Originally, Rueger went to MIT to become a research physicist, quite a long step away from her current career of 15 years so far. Its surprising to me how somebody could invest so much into their future but mysteriously end up in a different field entirely, a trend common across all majors. I suppose the future is just that unpredictable, which actually offers me relief since I’m so unsure of where I’ll end up.

All that being said, going into QA is certainly worth planning out long term if anybody is considering it professionally, since the first few years are typically rough. Jeremy Hymel, the QA manager at QAlytics, shares his experience; “The early years in a tester’s career are rough, the pay is not great, and they are not treated as well as developers.” Once the hardships are over however, this article lists multiple points to jump off of as a QA tester. I will summarize the following paths: Product Management, DevOps, and Customer Experience.

Product management is a common fit for advancing QA testers, since they have extensive experience ensuring the best software possible. This quality is essential to the success of software reliant companies and they will often recognize a good QA tester to take the role of feature development.

Testers are more suited than software developers in the advancing role of DevOps. QA testers can easily practice the skills needed for a career in release management, product stability, or automation engineering.

It also makes a lot of sense that a QA tester could pursue a Customer Experience role. The tester assumes the role of the customer with every software test, therefore they have plenty of experience seeing the point of view of the user.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

In this portion of the Individual Apprenticeship Patterns, it gives an overview about how the new coming of an apprentice can impact a development team that is filled with well-experienced craftsmen or developers. Apprentices by their nature are new, and inexperienced first hand, and therefore they are open to learn ideas and techniques used by the craftsmen around them. Assuming that most of the experienced craftsmen have 10-20 years experience, they are unable to further their skills because their only primary concern is to just get the job done or delivering the next project.  In order for a development team to improve its dynamics with new ideas and techniques, the apprentice can be one of the main components to improve or repair the team’s passion and enthusiasm.

“Most teams are not hyper-passionate or overly enthusiastic about technology. Predictably, they are focused on delivering the next project or improving on the aspects of the development life cycle that are causing them pain. Therefore, enthusiastic apprentices can often succumb to the urge to fly under the radar.”

The quote struck out to me because it shows the apprentices can give in or succumb to the ways of the experienced developers. As an individual, I want to be the type of person to bring enthusiasm to the team and to allow a flow of passion and excitement into the team. To me, maintaining a positive vibe and atmosphere allows everyone in the team to communicate effectively and consistently.

“On a team that is open to the excitement and contributions of an apprentice, you will provide some unique qualities that more experienced developers rely upon, such as unfettered imagination and enthusiasm. This is the time in your career when it makes the most sense to take risks and speak your mind. You have very little to lose. Your ideas and passions will add intelligence and diversity to your team.”

I found this quote extremely useful because it supports my idea that as a team member, having a passion about the work environment or project can bring positive outcomes for the team, and good things will happen. I fully agree with this Apprenticeship pattern because it promotes an amusing and enjoyable atmosphere for every team member, which can be traced back through the conscious or subconscious actions of the apprentice.

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

The “Confront Your Ignorance” pattern offers the next steps after you’ve followed the “Expose Your Ignorance” pattern. It’s not enough to admit that there are gaps in your knowledge; an apprentice software developer needs to be willing to do the work to fill in those gaps. The book suggests several ways to go about this. You might read introductory articles about the subject, start making a breakable toy, ask experts and peers if they’re willing to share their knowledge, or learn alongside someone else. Personally, I think learning with breakable toys would be the most effective strategy for me. I understand what’s going a lot quicker if I can try something myself and see it in action. I’ll also keep in mind asking peers and mentors. A lot of the time, I won’t be able to figure out something that’s obvious to someone who already has knowledge in a certain area on my own.

The writers emphasize that this pattern needs to be used with “Expose Your Ignorance.” Confronting your ignorance without exposing it means fostering a culture where failure and being seen learning are shameful and must occur in secret. It will also probably be more difficult and time-consuming if you don’t ask for guidance when you’re stuck. Exposing your ignorance without confronting it means you won’t be able to solve any problems outside of your particular niche, and others won’t appreciate it when the gaps in your knowledge prevent you from fulfilling your responsibilities.

This is also the first time the writers have mentioned a situation in which you should prioritize the job over the apprenticeship. It’s possible to be so caught up in your drive to learn more that it gets in the way of delivering the product. You might also be tempted to go about solving problems in a way that helps you learn what you’re trying to learn, but is impractical for others. You should be striving to improve your craft, but not at the expense of your team and your duties. Part of being an apprentice is putting the needs of your community before yourself. These guidelines provide a good balance between the greater goal and what’s more immediate.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

This semester, I am tasked with writing 10 blog posts, each being a reflection of a pattern defined in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye – this is the first of those blog posts.

This week, I will be writing a reflection on the “Breakable Toys” pattern.  The use of this pattern arises in the situation where a developer feels like failure in the workplace is not an option, and desires a safe space in which he or she can make mistakes and not suffer terrible consequences as a result.  Most people believe that failure is one of the best ways, if not the best way, to learn anything and so, if a person feels like they are in a situation where failure is not an option, it becomes harder for them to learn in that situation.  The “Breakable Toys” pattern is the solution for developers in a similar situation to the one I have just described.  A “breakable toy” is a personal project that is similar in toolset, but not in scope, to a system that you would typically see at work.  The idea behind using a “breakable toy” is that it allows you to try your ideas and techniques, safely, even if they lead to a catastrophic failure.  On this scale, the outcome of your attempts will only affect you, giving you the freedom to learn from your efforts without the fear of affecting others in the process.

The reason I chose this pattern to be the first subject of reflection in this series, is because it is a pattern that I already try to utilize in my own life.  I am currently trying to land my first internship as a developer and a couple of the companies I have been in contact with have asked me to complete coding problems (as you would expect).  I am a person who has a slight fear of failure – not enough to prevent me from trying to achieve things, but enough to give me a ton of anxiety in ‘make or break’ situations – so I began creating “breakable toys” to refresh my knowledge of data structures, algorithms, and fundamental programming concepts.  These “breakable toys” were quite useful to me, and they helped me to solve the programming problems, posed by my potential employers, in the interview process.  I also found a lot of enjoyment in creating “breakable toys” and solving coding challenges, so I have started to make more of an effort to make that a regular activity in my life.  I believe I am starting to utilize another pattern covered in the book: “Practice, practice, practice”, which will likely be the subject of next week’s reflection.

Thanks for reading.

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

This week I read the apprenticeship pattern “Be the Worst”. With this pattern essentially says that once you become one of the best on your team, and you aren’t learning as much, you should put yourself in an environment where you are the worst and you know almost nothing. By putting yourself in the situation where you are the “worst”, you are surrounded by engineers who are better than you and are in an environment where there is a lot more to learn.

What I found the most interesting about this pattern is the author’s willingness to leave what most would consider an ideal situation and put yourself in one where the odds are stacked against you. For most people, being the worst on a team isn’t the goal. Most people want to grow and reach that level of expertise where you are nicely paid, do your job comfortably, and are looked to others as a leader, this pattern suggests that this means the end of your growth. After really giving more thought to this pattern I realized that I agreed with the author, this is because applying this pattern makes you a lot more marketable. If you apply this pattern it will ultimately give you more expertise in more different domains making you much more marketable and increasing your job security.

I agree with almost everything about this pattern, but I am not sure if it is the safest way to go about this growth. The author referred to this as a “sink or swim” strategy so while it is true that it might be a very good way to learn and grow, for some the risk might not be worth the reward. It is still possible to grow even if you are the best, nothing is stopping you from learning more and continuing to the be the best where you currently are.

In conclusion, I think that this is a useful pattern but I don’t think it should be followed exactly as it is stated due to the high risk. What I have taken away (and will try to apply) is that I should try to put myself in situations that will promote growth.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.