Many times, people go into projects without much planning
before-hand which can cause many problems to arise. UML class diagrams can come
to be your saving grace. With these diagrams you are able to plan out how the code
will be set up down in a neat organized diagram. In these diagrams, the top section
depicts the name of the class, the middle section depicts the attributes and
the bottom portion is what lists the methods of the class. The top section will
be bolded to indicate that it is the class name. This top section however can
say whether or not the class is abstract, concrete or an interface. If the name
is simply just bolded, the class is concrete. If the title is italicized, then
the class is abstract. If the class is an interface, the top section will have
the class name bolded and <<Interface>> listed above the name.  In these middle sections you are able to
specify a lot about the attributes of the class. Any variable will be listed
with a minus sign beforehand and the data type following. If any of these
variables are static, then they must be underlined. This allows for someone to
seamlessly set-up the class without having to worry about including the correct
variables and data types. As stated before, the bottom section will contain the
methods of this class. These methods will contain the name of the parameter (if
applicable) and the data type of that method. If the method returns a data
type, this will be listed after the parameters. UML diagrams don’t stop there
though. What I was describing was one box/class, while UML diagrams can contain
many, with indicators to show the relationships between them. Arrows are used
to show relations between classes. An arrow going from one class to another
with a hollow white tip stands for inheritance. When an arrow is going from one
class to another with a dotted line, that represents implementation. A solid
black arrow means there is a reference from one of those classes to another. By
using UML diagrams, you are able to set up one’s entire program before writing
any actual code. This allows for anyone else to be able to read and understand
the code by simply going through the diagram. UML diagrams gives the coder the
ability to write clean flowing code. Below is an article which goes in depth
more with UML diagrams and also gives examples.

http://agilemodeling.com/artifacts/classDiagram.htm

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.

At the core of software design must be basic principles. Following basic principles allows us to make sure we are on track with a standard. It creates consistency and makes it easier to maintain our code in the future, because we will know what to expect.

Following a single principle might be easy, but there are many object-oriented design principles. Sometimes, it is quicker to hack a solution together than to think up an elegant solution. These solutions may then be built upon, and the project will slowly stray from its original intent. Gaining the intuition of when and how to apply these principles is necessary to ensure that a project doesn’t become a mess of spaghetti as these quick-fix solutions add up.

“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”

– Steve Jobs

Coding Blocks Episode 7 discusses these topics in the context of five of the most important design principles, known as SOLID. This podcast is great and I highly recommend it: it is hosted by professional programmers who discuss and debate the topics of each episode.

Each of these principles likely warrants its own podcast, and one or more blog posts to describe them in detail. Below is a short description of each one.

S: Single Responsibility Principle

• An object should only do one thing.

O: Open Closed Principle

• Code should have the ability to be extended, but it shouldn’t have to be modified.

L: Liskov Substitution Principle

• Replacing an object with one of its subtypes should not break the code.

I: Interface Segregation Principle

• Smaller, more specific interfaces are better. If an interface is too broad, an object may need to implement many methods it doesn’t need.

D: Dependency Inversion Principle

• Within a class, you don’t want to depend on an implementation. Instead, a higher-level class should depend on interfaces, which are implemented by lower-level classes. Don’t have an abstraction relying on an implementation. Have the implementation relying on an abstraction (interfaces).

Conclusion

The biggest takeaway from this podcast episode was that even professional programmers do not follow all of these principles all the time. Some of the concepts are confusing and contradict other principles. Some of them should only be applied when refactoring code after it is working, with the goal of improving your code.

However, when learning these principles, projects should be created with the sole goal of implementing these principles. Mentally solidifying these concepts by focusing on each one and converting it into code will help a developer to predict issues that may come up in the future when implementing production code. Knowing the context of the system, code can be written that mostly follows these principles right off the bat, and improvements can be made later as code is added and the patterns emerge. Most importantly: the foundation will be SOLID.

From the blog CS@Worcester – Inquiries and Queries by ausausdauer and used with permission of the author. All other rights reserved by the author.