Software Design Patterns

Software Design Patterns are commonly used on object-oriented software development, they are previously defined methods to design and code programs, used commonly by experts and corporations that benefit from structured and unified ways to develop and execute. They serve as a common framework for developers and promote good coding practices.

Source


They were not developed intentionally, they were instead created by trial and error and the prevalent ones are the ones that, by natural selection, were proven to be the best ones.
The Gang of Four, are the ones that wrote a book and set the SDP principles down, the book is called "Design Patterns - Elements of Reusable Object-Oriented Software". The two main principles are:

  • Program to an interface, not an implementation: Basically programming the classes in order for them to be implementable by other software, resuable and act as pieces of a bigger puzzle.
  • Favor composition over inheritance: Classes should implement other classes to complete their functionality, rather than inheriting from them.
There are a lot of desing patterns and not one is always the "correct" one, nonetheless, four main pattern types are defined:
  • Creational: Create objects on the go as they are being used.
  • Structural: The composition of objects is of most importance, mix and match to obtain new functionality.
  • Behavioral: Communication between objects is prioritized.
  • J2EE: Presentation layer.

Source: https://www.tutorialspoint.com/design_pattern/design_pattern_overview.htm

Software Design Patterns

Software Design Patterns are commonly used on object-oriented software development, they are previously defined methods to design and code programs, used commonly by experts and corporations that benefit from structured and unified ways to develop and execute. They serve as a common framework for developers and promote good coding practices.

Source


They were not developed intentionally, they were instead created by trial and error and the prevalent ones are the ones that, by natural selection, were proven to be the best ones.
The Gang of Four, are the ones that wrote a book and set the SDP principles down, the book is called "Design Patterns - Elements of Reusable Object-Oriented Software". The two main principles are:

  • Program to an interface, not an implementation: Basically programming the classes in order for them to be implementable by other software, resuable and act as pieces of a bigger puzzle.
  • Favor composition over inheritance: Classes should implement other classes to complete their functionality, rather than inheriting from them.
There are a lot of desing patterns and not one is always the "correct" one, nonetheless, four main pattern types are defined:
  • Creational: Create objects on the go as they are being used.
  • Structural: The composition of objects is of most importance, mix and match to obtain new functionality.
  • Behavioral: Communication between objects is prioritized.
  • J2EE: Presentation layer.

Source: https://www.tutorialspoint.com/design_pattern/design_pattern_overview.htm

Software Design & Software Architecture

These two parts are essential to software-making, they are sequential steps that ensure a program meets the specifications needed and solves a particular problem, let's start with Architecture.


Source

Software architecture deals with the abstraction part of design, it analyzes the problem and sets a methodolgy to solve it, commonly using blocks. The software architect must be very acquainted with the challenge that he is facing, along with the technologies that can be used to solve it. Nonetheless, the SA doesn't do coding, he gives the product owner a thorough analysis and the underlying structure of the program that must be made, including a design blueprint and the attributes and connections of each part that has to be implemented later.

Software Architecture is, in essence, delivering a structured solution to a problem.

Software Design, on the other hand, deals with the technical details of the implementation of the system. They take into account the environment, adapting the development process to it, incluiding software and hardware constraints. They design and guide the coding process, including testing and debugging, in order for the process to be orderly and ensure success.

Software Design creates the functional part of the archutecture plan.

Software Design & Software Architecture

These two parts are essential to software-making, they are sequential steps that ensure a program meets the specifications needed and solves a particular problem, let's start with Architecture.


Source

Software architecture deals with the abstraction part of design, it analyzes the problem and sets a methodolgy to solve it, commonly using blocks. The software architect must be very acquainted with the challenge that he is facing, along with the technologies that can be used to solve it. Nonetheless, the SA doesn't do coding, he gives the product owner a thorough analysis and the underlying structure of the program that must be made, including a design blueprint and the attributes and connections of each part that has to be implemented later.

Software Architecture is, in essence, delivering a structured solution to a problem.

Software Design, on the other hand, deals with the technical details of the implementation of the system. They take into account the environment, adapting the development process to it, incluiding software and hardware constraints. They design and guide the coding process, including testing and debugging, in order for the process to be orderly and ensure success.

Software Design creates the functional part of the archutecture plan.

Software verification and validation

Imagine that you finished a big, big, BIG project. You’re delivering it. The client sings the final check and shakes your hand, thankful. Two weeks later, you receive a call. It’s your lawyer. Your client wants to sue you because what you did is not what he asked for (at all). So… you have three choices: a) you rot in jail, b) you deliver a new product (that means, you work extremely in order to make it fast and good) or c) you travel back in time and check that what you’re developing is actually what the client needs. I have great news! Although option C is physically imposible, you can do something similar: do it before every project you build.

Verification and validation may seem the same concept. To identify the difference, ask yourself: am I building the product right? This is verification. In the other hand, am I building the right product? This is validation. Both are equally important.

There are three other concepts that are important. One might think they’re all the same, but they’re not. Here are the concepts about errors:

  • Fault: when your code is wrong, when you forgot a parenthesis, when you named the file with a wrong extension. Simple bugs, generally debugged by the IDE or compiler iteslf.
  • Failure: runtime error. It happens during execution of the program. These must be debugged manually.
  • Malfunction: this is a deeper error. It involves the structure and architecture of the program. Usually, this are the worst bugs. These take days to be solved. Sometimes one must restructure from zero.

This process is directly related to software testing and requirements elicitation.

flickr photo by West Point - The U.S. Military Academy https://flickr.com/photos/west_point/6005746185 shared under a Creative Commons (BY-NC-ND) license
flickr photo by West Point – The U.S. Military Academy https://flickr.com/photos/west_point/6005746185 shared under a Creative Commons (BY-NC-ND) license

User Interface design

I would classify software in three categories. All of them are equally important, and even though each of them works as one piece, a real big project requires the three of them. The first is the core software: in a simple word, algorithms. By itself, it is one of the most important things. But, without the other three components, it’s good stuff only for other developers. Second: database. How is the information stored. Again, if not used as a whole with the other components, it’s only good for developers. And third: UI. UI is, at least for users, the most important aspect on every program. You have an ugly UI, your program is “not as good as X program, which is pretty”. You have a great UI although your core is not that good, (most) users don’t care, the UI is great and simple, they can use it without problem.

User Interface is the layer of software with which users interact. It seems the most simple layer (technically speaking), but it is one of the most complex to develop. Why? They say a UI is like a joke: if you need to explain it, it’s probably not good.

UI is categorized in three forms, from more advanced to more natural:

  • CLI: Command Line Interface. Basically, a terminal in which one types text-only commands.
  • GUI: Graphic User Interface. This time is visual, but it’s fully digital.
  • NUI: Natural User Interface. The most natural form of UI. It includes sensors, buttons and other devices that can be physically manipulated by the user.
flickr photo by baldiri https://flickr.com/photos/baldiri/5734993652 shared under a Creative Commons (BY) license
flickr photo by baldiri https://flickr.com/photos/baldiri/5734993652 shared under a Creative Commons (BY) license

Code reusability: don’t reinvent the wheel

As the title says, it is completely unnecessary to rewrite code that it has already been written, it is, most of the time, a waste of your time and effort. With all the open source code available nowadays, it is really probable that you find whatever you are looking for on sites like github, gitlab, bitbucket or any other site, and if you don’t find it, well, then now you know what’s going to be your next open source contribution. You should really focus on writing building on top of what others have already done, also, it is worth to notice that you should be writing reusable code as well.

Some tips on writing reusable code:

  1. Don’t repeat yourself: if you find yourself writing the same code several times, probably you should move that piece of god to a module or something alike.
  2. Make a class/method do just one thing: remember the Unix philosophy? write programs that do one thing and do it well, also, write these programs to work together, the secret is in writing generic code to accomplish one simple thing, then use the output of that as input of another program to accomplish a more complex task, don’t make code too generic tough, or it will be difficult to find a purpose to it.
  3. Write unit tests for your classes and make it easy to test classes.
  4. Remove the business logic or main code away from any framework code.
  5. Try yo think more abstractly and use Interfaces and Abstract classes.
  6. Write code that can be easily extended in the future, for code leverage of course.
  7. Don’t write code that isn’t needed, if you doubt if the code is needed, then it is not, just leave it out.
  8. Try to reduce coupling, avoid modules/classes depending on each other.
  9. code-reuse.jpg
    Continue reading "Code reusability: don’t reinvent the wheel"

Design is everything

softwaredesigncomic2
http://www.benhallbenhall.com/2012/07/483/

While I was doing a research abour sofware design, I found a really interesting article by Jack Reeves, who describes a new perspective about this topic.

What do we think about when we hear software design? Well, I think about design patterns and diagrams, which it’s okay. But the article says something different that I like more.

In the software lifecycle we have design, implementation, testing,… And the coding part seems to be in the software implementation, but with extreme programming everything changes, because while you’re implementing you also design, then test, redesign, and so on.

The author of the article says that “real software runs on computers[…] it is not a program listing in C++”. That means the program itself represent a software design. Makes sense? So, practically every sept of a software project is part of the design process.

This idea matches the one discussed in my post about software being an engineering or a craft. The important thing is to know that the real purpose is to help people accomplishing a task.

Source:


Maintaining Software

Reasons of doing it? Well, software is a model of reality and reality changes. If software is found to be useful, satisfied users want to extend the functionality of the system. Software is much cheaper to change than hardware. As a result, changes are made in software wherever possible. Successful software survives well beyond the lifetime of the hardware for which it was written. Software need to be modified to run on new hardware and operating system.

There are some types of maintenance based on their characteristics:
  • Corrective Maintenance – This includes modifications and updates done in order to correct or fix problems, which are either discovered by user or concluded by user error reports.
  • Adaptive Maintenance – This includes modifications applied to keep the software product up-to date and tuned to the ever changing world of technology and business environment.
  • Perfective Maintenance – This includes updates done in order to keep the software usable over long period of time. It includes new features, new user requirements for refining the software and improve its reliability and performance.
  • Preventive Maintenance – It aims to attend problems, which are not significant at this moment but may cause serious issues in future.

Here’s a little video about the software maintenance process:


User Interfaaaace

User Interface Design focuses on anticipating what users might need to do and ensuring that the interface has elements that are easy to access, understand, and use to facilitate those actions.

Keep it simple, Simple UI design means that anyone can have access to very sophisticated applications. When applications are well designed, there is no price for access. You may have to pay for the application, but you don’t have to spend time learning how to use it.

top-hero-screens.png

What is the difference of UX and UI? Well UX Design refers to the term User Experience Design, while UI Design stands for User Interface Design. Both elements are crucial to a product and work closely together. But despite their professional relationship, the roles themselves are quite different, referring to very different parts of the process and the design discipline.