Ludwin Barbin

Author
+ Follow
since Jul 29, 2009
- 18 years of Software Development Experience
- Certified Java Programmer
- Certified Web Component Developer
- Certified Java Enterprise Architect
38
Cows and Likes
Cows
Total received
5
In last 30 days
0
Total given
0
Likes
Total received
6
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ludwin Barbin

By the way, regular email address will do because it's eBook

I will send the PDF version to the winners.

And thank you for all your questions and interest on the book. As first time author, I really appreciate the support from JavaRanch community!

Let's all work and help each other towards building quality software...
In my book, I mentioned defensive programming in light of Design by Contract (DbC).

Design by Contract (DbC)

The notion of contract relates to obligations and benefits. An obligation to one party (supplier) is a benefit to another party (client).

In programming, contract is translated to precondition and postcondition.

Precondition > Process > Postcondition

The following can be observed from DbC:
- the stronger the precondition, more work for the client
- the stronger the postcondition, more work for the supplier

The following assumptions can be made when error occurs,
- Error in runtime is an indication of a bug
- A precondition error is a bug in the client
- A postcondition error is a bug in the supplier

The benefits of DbC is that there is less programming involved – you get more, you check less. There is less redundancy and there is clear separation of responsibility. Both client and supplier knows exactly their boundaries. DbC also contributes to software reliability and testability. It also results to clear documentation and easy debugging.

As opposed to defensive programming, you always check for precondition, you always validate inputs anywhere they appear. You’re checking things blindly just in case. This style leads to a lot of redundancy and code bloat. Everyone is responsible yet no one accepts responsibility.

Yes, you're right, the principles are abstract in nature.

That's why I've lots of real-world analogies, examples, and visuals to help in learning and applying the concepts.

I did not refer to any particular language or pseudo-code as that level of details may not be appropriate for the topic. I admit I was tempted to include code snippets, but then again it's way too low-level for the high-level abstractions that the principles are referring to.

I believe the blogs and forums can supplement these additional details if the reader needs to go deeper.

K. Tsang wrote:

Ludwin Barbin wrote:
The design principles are explained in a concise manner with visuals, analogies, real-world examples to help strengthen the concept.



About the visuals, is there a separate PDF or file similar to SOA principles/patterns here



There is no separate PDF file for the visuals, the visuals may be difficult to comprehend outside the context of the text descriptions, the text and images go together for better understanding.

For a quick lookup/reference, simply go to Table of Contents and click on the chapter link.

K. Tsang wrote:Thanks Ludwin.

About the e-book it's 50 pages yet on Amazon it says estimated 72 pages. Not sure if it's refer to the Kindle edition.



Amazon has their own tool that approximates the no. of pages when viewed on their Kindle device using their default font settings. But based on the normal page size (a paper) will have a total of 50 pages.

Thanks for your interest.
Yes, it's only on the e-Book medium. This medium allows you to access it easily and handily from any of your mobile devices or from the web.

It's a 50-page eBook, if you want to print it, you can download a pdf version in Smashwords and simply feed it to your printer.

K. Tsang wrote:Welcome to the Ranch Ludwin.

Your book looks like a great reference for any architect and developer. I want to know if the book mentions examples when to use (or more importantly not to use) each design principle.

Also will applying one principle affect or break the outcome of another principle? Such interrelationship or dependency should be invaluable.

Thanks.



That's exactly what you're going to get

In fact, there is a whole section called "Synthesis" which takes all these design principles in one diagram and show you which ones are complementary and contradictory.

The design principles are explained in a concise manner with visuals, analogies, real-world examples to help strengthen the concept.

And I'm pretty confident you can finish the book in 2-3 days, it's definitely not a waste of your time...
Hi Bernhard,

To answer your question, my consulting experience started (and continued) in different periods of my career.

After spending 5-7 years in programming, I've worked for a consulting company where I was an Analyst/Developer making OO designs using UML (no Agile yet).

When web services and Agile came, I went hands-on again. At the same time, I focused on architecture and went on to certify for Java Enterprise Architect.

For the last 2-3 years, I've been doing architecting/consulting/coding. I never left coding -- it's my way of keeping my feet on the ground

Thanks for your question.

E Armitage wrote:Design principles are the desirable goals that one aims to achieve. Design patterns are tools one can use to realize those goals.
It's therefore better to learn design principles first because then you can easily understand what (and why) a pattern is trying to achieve.



You're spot on!

Design Patterns are very popular and have complete catalogues and the resources/references for them can easily be found.

But Design Principles have been scattered and disorganized, and became confusing for many. My book "Software Design Principles" is a compilation of these principles and untangle all the confusions.

Campbell Ritchie wrote:Would the book be suitable for an introduction, for experienced students, etc?



Based on other peoples' feedback, the book is for mid to senior IT professionals. And my main target audience are software architects and senior developers.

But even students and newbies can benefit from the book because the topics serve as foundational basis in software development. I've put in lots of visuals, real-world analogies, and real-world examples.

Campbell Ritchie wrote:By lower‑level, do you mean that design patterns have a finer granularity than principles?



Exactly!
Yes, it's all there and more!

Checkout the Agile phrases - IKIWISI (pronounced “icky-wissy”), WGLL (pronounced “wiggle”), WDLL (pronounced “widdle”), WILIWIK (pronounced “willy-wick”)

Many of us are familiar with GOF patterns, JEE Core patterns, etc...

What about Design Principles such as SOLID, GRASP, OO Principles ?

Is there any difference between the two concepts? Or how are they related?
The following core principles serve as foundation for many of the design patterns:

1. Separation of Concerns (SoC)
2. Coupling
3. Cohesion
4. Information Hiding

Just following the above will help you write high quality software.

Learn more in my book "Software Design Principles"
If these concepts are confusing to you, let the book "Software Design Principles" help you sort it out.