Agile Software Development

Robert C. Martin

Mentioned 38

Written by a software developer for software developers, this book is a unique collection of the latest software development methods. The author incudes OOD, UML, Design Patterns, Agile and XP methods with a detailed description of a complete software design for reusable programs in C++ and Java. Using a practical, problem-solving approach, it shows how to develop an object-oriented application -- from the early stages of analysis, through the low-level design and into the implementation. Walks readers through the designer's thoughts — showing the errors, blind alleys, and creative insights that occur throughout the software design process. Covers: Statics and Dynamics; Principles of Class Design; Complexity Management; Principles of Package Design; Analysis and Design; Patterns and Paradigm Crossings. Explains the principles of OOD, one by one, and then demonstrates them with numerous examples, completely worked-through designs, and case studies. Covers traps, pitfalls, and work arounds in the application of C++ and OOD and then shows how Agile methods can be used. Discusses the methods for designing and developing big software in detail. Features a three-chapter, in-depth, single case study of a building security system. For Software Engineers, Programmers, and Analysts who want to understand how to design object oriented software with state of the art methods.

More on

Mentioned in questions and answers.

If you could go back in time and tell yourself to read a specific book at the beginning of your career as a developer, which book would it be?

I expect this list to be varied and to cover a wide range of things.

To search: Use the search box in the upper-right corner. To search the answers of the current question, use inquestion:this. For example:

inquestion:this "Code Complete"

Applying UML and Patterns by Craig Larman.

The title of the book is slightly misleading; it does deal with UML and patterns, but it covers so much more. The subtitle of the book tells you a bit more: An Introduction to Object-Oriented Analysis and Design and Iterative Development.

Masters of doom. As far as motivation and love for your profession go: it won't get any better than what's been described in this book, truthfully inspiring story!

Beginning C# 3.0: An Introduction to Object Oriented Programming

This is the book for those who want to understand the whys and hows of OOP using C# 3.0. You don't want to miss it.

alt text

Mastery: The Keys to Success and Long-Term Fulfillment, by George Leonard

It's about about what mindsets are required to reach mastery in any skill, and why. It's just awesome, and an easy read too.

Pro Spring is a superb introduction to the world of Inversion of Control and Dependency Injection. If you're not aware of these practices and their implications - the balance of topics and technical detail in Pro Spring is excellent. It builds a great case and consequent personal foundation.

Another book I'd suggest would be Robert Martin's Agile Software Development (ASD). Code smells, agile techniques, test driven dev, principles ... a well-written balance of many different programming facets.

More traditional classics would include the infamous GoF Design Patterns, Bertrand Meyer's Object Oriented Software Construction, Booch's Object Oriented Analysis and Design, Scott Meyer's "Effective C++'" series and a lesser known book I enjoyed by Gunderloy, Coder to Developer.

And while books are nice ... don't forget radio!

... let me add one more thing. If you haven't already discovered safari - take a look. It is more addictive than stack overflow :-) I've found that with my google type habits - I need the more expensive subscription so I can look at any book at any time - but I'd recommend the trial to anyone even remotely interested.

(ah yes, a little obj-C today, cocoa tomorrow, patterns? soa? what was that example in that cookbook? What did Steve say in the second edition? Should I buy this book? ... a subscription like this is great if you'd like some continuity and context to what you're googling ...)

Database System Concepts is one of the best books you can read on understanding good database design principles.

alt text

Algorithms in C++ was invaluable to me in learning Big O notation and the ins and outs of the various sort algorithms. This was published before Sedgewick decided he could make more money by dividing it into 5 different books.

C++ FAQs is an amazing book that really shows you what you should and shouldn't be doing in C++. The backward compatibility of C++ leaves a lot of landmines about and this book helps one carefully avoid them while at the same time being a good introduction into OO design and intent.

Here are two I haven't seen mentioned:
I wish I had read "Ruminations on C++" by Koenig and Moo much sooner. That was the book that made OO concepts really click for me.
And I recommend Michael Abrash's "Zen of Code Optimization" for anyone else planning on starting a programming career in the mid 90s.

Perfect Software: And Other Illusions about Testing


Perfect Software: And Other Illusions about Testing by Gerald M. Weinberg

ISBN-10: 0932633692

ISBN-13: 978-0932633699

Rapid Development by McConnell

The most influential programming book for me was Enough Rope to Shoot Yourself in the Foot by Allen Holub.

Cover of the book

O, well, how long ago it was.

I have a few good books that strongly influenced me that I've not seen on this list so far:

The Psychology of Everyday Things by Donald Norman. The general principles of design for other people. This may seem to be mostly good for UI but if you think about it, it has applications almost anywhere there is an interface that someone besides the original developer has to work with; e. g. an API and designing the interface in such a way that other developers form the correct mental model and get appropriate feedback from the API itself.

The Art of Software Testing by Glen Myers. A good, general introduction to testing software; good for programmers to read to help them think like a tester i. e. think of what may go wrong and prepare for it.

By the way, I realize the question was the "Single Most Influential Book" but the discussion seems to have changed to listing good books for developers to read so I hope I can be forgiven for listing two good books rather than just one.

alt text

C++ How to Program It is good for beginner.This is excellent book that full complete with 1500 pages.

Effective C++ and More Effective C++ by Scott Myers.

Inside the C++ object model by Stanley Lippman

I bough this when I was a complete newbie and took me from only knowing that Java existed to a reliable team member in a short time

Not a programming book, but still a very important book every programmer should read:

Orbiting the Giant Hairball by Gordon MacKenzie

The Pragmatic programmer was pretty good. However one that really made an impact when I was starting out was :

Windows 95 System Programming Secrets"

I know - it sounds and looks a bit cheesy on the outside and has probably dated a bit - but this was an awesome explanation of the internals of Win95 based on the Authors (Matt Pietrek) investigations using his own own tools - the code for which came with the book. Bear in mind this was before the whole open source thing and Microsoft was still pretty cagey about releasing documentation of internals - let alone source. There was some quote in there like "If you are working through some problem and hit some sticking point then you need to stop and really look deeply into that piece and really understand how it works". I've found this to be pretty good advice - particularly these days when you often have the source for a library and can go take a look. Its also inspired me to enjoy diving into the internals of how systems work, something that has proven invaluable over the course of my career.

Oh and I'd also throw in effective .net - great internals explanation of .Net from Don Box.

I recently read Dreaming in Code and found it to be an interesting read. Perhaps more so since the day I started reading it Chandler 1.0 was released. Reading about the growing pains and mistakes of a project team of talented people trying to "change the world" gives you a lot to learn from. Also Scott brings up a lot of programmer lore and wisdom in between that's just an entertaining read.

Beautiful Code had one or two things that made me think differently, particularly the chapter on top down operator precedence.


@Juan: I know Juan, I know - but there are some things that can only be learned by actually getting down to the task at hand. Speaking in abstract ideals all day simply makes you into an academic. It's in the application of the abstract that we truly grok the reason for their existence. :P

@Keith: Great mention of "The Inmates are Running the Asylum" by Alan Cooper - an eye opener for certain, any developer that has worked with me since I read that book has heard me mention the ideas it espouses. +1

I found the The Algorithm Design Manual to be a very beneficial read. I also highly recommend Programming Pearls.

This one isnt really a book for the beginning programmer, but if you're looking for SOA design books, then SOA in Practice: The Art of Distributed System Design is for you.

For me it was Design Patterns Explained it provided an 'Oh that's how it works' moment for me in regards to design patterns and has been very useful when teaching design patterns to others.

Code Craft by Pete Goodliffe is a good read!

Code Craft

The first book that made a real impact on me was Mastering Turbo Assembler by Tom Swan.

Other books that have had an impact was Just For Fun by Linus Torvalds and David Diamond and of course The Pragmatic Programmer by Andrew Hunt and David Thomas.

In addition to other people's suggestions, I'd recommend either acquiring a copy of SICP, or reading it online. It's one of the few books that I've read that I feel greatly increased my skill in designing software, particularly in creating good abstraction layers.

A book that is not directly related to programming, but is also a good read for programmers (IMO) is Concrete Mathematics. Most, if not all of the topics in it are useful for programmers to know about, and it does a better job of explaining things than any other math book I've read to date.

For me "Memory as a programming concept in C and C++" really opened my eyes to how memory management really works. If you're a C or C++ developer I consider it a must read. You will defiantly learn something or remember things you might have forgotten along the way.

Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.

I used this book as the starting point to understanding Agile development.

Systemantics: How Systems Work and Especially How They Fail. Get it used cheap. But you might not get the humor until you've worked on a few failed projects.

The beauty of the book is the copyright year.

Probably the most profound takeaway "law" presented in the book:

The Fundamental Failure-Mode Theorem (F.F.T.): Complex systems usually operate in failure mode.

The idea being that there are failing parts in any given piece of software that are masked by failures in other parts or by validations in other parts. See a real-world example at the Therac-25 radiation machine, whose software flaws were masked by hardware failsafes. When the hardware failsafes were removed, the software race condition that had gone undetected all those years resulted in the machine killing 3 people.

It seems most people have already touched on the some very good books. One which really helped me out was Effective C#: 50 Ways to Improve your C#. I'd be remiss if I didn't mention The Tao of Pooh. Philosophy books can be good for the soul, and the code.

Discrete Mathematics For Computer Scientists

Discrete Mathematics For Computer Scientists by J.K. Truss.

While this doesn't teach you programming, it teaches you fundamental mathematics that every programmer should know. You may remember this stuff from university, but really, doing predicate logic will improve you programming skills, you need to learn Set Theory if you want to program using collections.

There really is a lot of interesting information in here that can get you thinking about problems in different ways. It's handy to have, just to pick up once in a while to learn something new.

I saw a review of Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools on a blog talking also about XI-Factory, I read it and I must say this book is a must read. Altough not specifically targetted to programmers, it explains very clearly what is happening in the programming world right now with Model-Driven Architecture and so on..

Solid Code Optimizing the Software Development Life Cycle

Although the book is only 300 pages and favors Microsoft technologies it still offers some good language agnostic tidbits.

Managing Gigabytes is an instant classic for thinking about the heavy lifting of information.

My vote is "How to Think Like a Computer Scientist: Learning With Python" It's available both as a book and as a free e-book.

It really helped me to understand the basics of not just Python but programming in general. Although it uses Python to demonstrate concepts, they apply to most, if not all, programming languages. Also: IT'S FREE!

Object-Oriented Programming in Turbo C++. Not super popular, but it was the one that got me started, and was the first book that really helped me grok what an object was. Read this one waaaay back in high school. It sort of brings a tear to my eye...

My high school math teacher lent me a copy of Are Your Lights Figure Problem that I have re-read many times. It has been invaluable, as a developer, and in life generally.

I'm reading now Agile Software Development, Principles, Patterns and Practices. For those interested in XP and Object-Oriented Design, this is a classic reading.

alt text

Kernighan & Plauger's Elements of Programming Style. It illustrates the difference between gimmicky-clever and elegant-clever.

to get advanced in prolog i like these two books:

The Art of Prolog

The Craft of Prolog

really opens the mind for logic programming and recursion schemes.

Here's an excellent book that is not as widely applauded, but is full of deep insight: Agile Software Development: The Cooperative Game, by Alistair Cockburn.

What's so special about it? Well, clearly everyone has heard the term "Agile", and it seems most are believers these days. Whether you believe or not, though, there are some deep principles behind why the Agile movement exists. This book uncovers and articulates these principles in a precise, scientific way. Some of the principles are (btw, these are my words, not Alistair's):

  1. The hardest thing about team software development is getting everyone's brains to have the same understanding. We are building huge, elaborate, complex systems which are invisible in the tangible world. The better you are at getting more peoples' brains to share deeper understanding, the more effective your team will be at software development. This is the underlying reason that pair programming makes sense. Most people dismiss it (and I did too initially), but with this principle in mind I highly recommend that you give it another shot. You wind up with TWO people who deeply understand the subsystem you just built ... there aren't many other ways to get such a deep information transfer so quickly. It is like a Vulcan mind meld.
  2. You don't always need words to communicate deep understanding quickly. And a corollary: too many words, and you exceed the listener/reader's capacity, meaning the understanding transfer you're attempting does not happen. Consider that children learn how to speak language by being "immersed" and "absorbing". Not just language either ... he gives the example of some kids playing with trains on the floor. Along comes another kid who has never even SEEN a train before ... but by watching the other kids, he picks up the gist of the game and plays right along. This happens all the time between humans. This along with the corollary about too many words helps you see how misguided it was in the old "waterfall" days to try to write 700 page detailed requirements specifications.

There is so much more in there too. I'll shut up now, but I HIGHLY recommend this book!

alt text

The Back of the Napkin, by Dan Roam.

The Back of the Napkin

A great book about visual thinking techniques. There is also an expanded edition now. I can't speak to that version, as I do not own it; yet.

Agile Software Development by Alistair Cockburn

Do users ever touch your code? If you're not doing solely back-end work, I recommend About Face: The Essentials of User Interface Design — now in its third edition (linked). I used to think my users were stupid because they didn't "get" my interfaces. I was, of course, wrong. About Face turned me around.

"Writing Solid Code: Microsoft's Techniques for Developing Bug-Free C Programs (Microsoft Programming Series)" by Steve MacGuire.

Interesting what a large proportion the books mentioned here are C/C++ books.

While not strictly a software development book, I would highly recommend that Don't Make me Think! be considered in this list.

As so many people have listed Head First Design Patterns, which I agree is a very good book, I would like to see if so many people aware of a title called Design Patterns Explained: A New Perspective on Object-Oriented Design.

This title deals with design patterns excellently. The first half of the book is very accessible and the remaining chapters require only a firm grasp of the content already covered The reason I feel the second half of the book is less accessible is that it covers patterns that I, as a young developer admittedly lacking in experience, have not used much.

This title also introduces the concept behind design patterns, covering Christopher Alexander's initial work in architecture to the GoF first implementing documenting patterns in SmallTalk.

I think that anyone who enjoyed Head First Design Patterns but still finds the GoF very dry, should look into Design Patterns Explained as a much more readable (although not quite as comprehensive) alternative.

Even though i've never programmed a game this book helped me understand a lot of things in a fun way.

How influential a book is often depends on the reader and where they were in their career when they read the book. I have to give a shout-out to Head First Design Patterns. Great book and the very creative way it's written should be used as an example for other tech book writers. I.e. it's written in order to facilitate learning and internalizing the concepts.

Head First Design Patterns

97 Things Every Programmer Should Know

alt text

This book pools together the collective experiences of some of the world's best programmers. It is a must read.

Extreme Programming Explained: Embrace Change by Kent Beck. While I don't advocate a hardcore XP-or-the-highway take on software development, I wish I had been introduced to the principles in this book much earlier in my career. Unit testing, refactoring, simplicity, continuous integration, cost/time/quality/scope - these changed the way I looked at development. Before Agile, it was all about the debugger and fear of change requests. After Agile, those demons did not loom as large.

One of my personal favorites is Hacker's Delight, because it was as much fun to read as it was educational.

I hope the second edition will be released soon!

You.Next(): Move Your Software Development Career to the Leadership Track ~ Michael C. Finley (Author), Honza Fedák (Author) link text

I've been arounda while, so most books that I have found influential don't necessarily apply today. I do believe it is universally important to understand the platform that you are developing for (both hardware and OS). I also think it's important to learn from other peoples mistakes. So two books I would recommend are:

Computing Calamities and In Search of Stupidity: Over Twenty Years of High Tech Marketing Disasters

Working Effectively with Legacy Code is a really amazing book that goes into great detail about how to properly unit test your code and what the true benefit of it is. It really opened my eyes.

Suppose I have BaseClass with public methods A and B, and I create DerivedClass through inheritance.


public DerivedClass : BaseClass {}

Now I want to develop a method C in DerivedClass that uses A and B. Is there a way I can override methods A and B to be private in DerivedClass so that only method C is exposed to someone who wants to use my DerivedClass?

I would say that if you have a codebase that you are wanting to do this with, it is not the best designed code base. It's typically a sign of a class in one level of the heirarchy needing a certain public signature while another class derived from that class doesn't need it.

An upcoming coding paradigm is called "Composition over Inheritance." This plays directly off of the principles of object-oriented development (especially the Single Responsibility Principle and Open/Closed Principle).

Unfortunately, the way a lot of us developers were taught object-orientation, we have formed a habit of immediately thinking about inheritance instead of composition. We tend to have larger classes that have many different responsibilities simply because they might be contained with the same "Real World" object. This can lead to class hierarchies that are 5+ levels deep.

An unfortunate side-effect that developers don't normally think about when dealing with inheritance is that inheritance forms one of the strongest forms of dependencies that you can ever introduce into your code. Your derived class is now strongly dependant on the class it was inherited from. This can make your code more brittle in the long run and lead to confounding problems where changing a certain behavior in a base class breaks derived classes in obscure ways.

One way to break your code up is through interfaces like mentioned in another answer. This is a smart thing to do anyways as you want a class's external dependencies to bind to abstractions, not concrete/derived types. This allows you to change the implementation without changing the interface, all without effecting a line of code in your dependent class.

I would much rather than maintain a system with hundreds/thousands/even more classes that are all small and loosely-coupled, than deal with a system that makes heavy use of polymorphism/inheritance and has fewer classes that are more tightly coupled.

Perhaps the best resource out there on object-oriented development is Robert C. Martin's book, Agile Software Development, Principles, Patterns, and Practices.

I am trying to learn the Single Responsibility Principle (SRP) but it is being quite difficult as I am having a huge difficult to figure out when and what I should remove from one class and where I should put/organize it.

I was googling around for some materials and code examples, but most materials I found, instead of making it easier to understand, made it hard to understand.

For example if I have a list of Users and from that List I have a class Called Control that does lots of things like Send a greeting and goodbye message when a user comes in/out, verify weather the user should be able to enter or not and kick him, receive user commands and messages, etc.

From the example you don't need much to understand I am already doing too much into one class but yet I am not clear enough on how to split and reorganize it afterwards.

If I understand the SRP, I would have a class for joining the channel, for the greeting and goodbye, a class for user verification, a class for reading the commands, right ?

But where and how would I use the kick for example ?

I have the verification class so I am sure I would have all sort of user verification in there including weather or not a user should be kicked.

So the kick function would be inside the channel join class and be called if the verification fails ?

For example:

public void UserJoin(User user)
    if (verify.CanJoin(user))

Would appreciate if you guys could lend me a hand here with easy to understand C# materials that are online and free or by showing me how I would be splitting the quoted example and if possible some sample codes, advice, etc.

Let’s start with what does Single Responsibility Principle (SRP) actually mean:

A class should have only one reason to change.

This effectively means every object (class) should have a single responsibility, if a class has more than one responsibility these responsibilities become coupled and cannot be executed independently, i.e. changes in one can affect or even break the other in a particular implementation.

A definite must read for this is the source itself (pdf chapter from "Agile Software Development, Principles, Patterns, and Practices"): The Single Responsibility Principle

Having said that, you should design your classes so they ideally only do one thing and do one thing well.

First think about what “entities” you have, in your example I can see User and Channel and the medium between them through which they communicate (“messages"). These entities have certain relationships with each other:

  • A user has a number of channels that he has joined
  • A channel has a number of users

This also leads naturally do the following list of functionalities:

  • A user can request to join a channel.
  • A user can send a message to a channel he has joined
  • A user can leave a channel
  • A channel can deny or allow a user’s request to join
  • A channel can kick a user
  • A channel can broadcast a message to all users in the channel
  • A channel can send a greeting message to individual users in the channel

SRP is an important concept but should hardly stand by itself – equally important for your design is the Dependency Inversion Principle (DIP). To incorporate that into the design remember that your particular implementations of the User, Message and Channel entities should depend on an abstraction or interface rather than a particular concrete implementation. For this reason we start with designing interfaces not concrete classes:

public interface ICredentials {}

public interface IMessage
    string Text {get;set;}
    DateTime TimeStamp { get; set; }
    IChannel Channel { get; set; }

public interface IChannel
    ReadOnlyCollection<IUser> Users {get;}
    ReadOnlyCollection<IMessage> MessageHistory { get; }

    bool Add(IUser user);
    void Remove(IUser user);
    void BroadcastMessage(IMessage message);
    void UnicastMessage(IMessage message);

public interface IUser
    string Name {get;}
    ICredentials Credentials { get; }
    bool Add(IChannel channel);
    void Remove(IChannel channel);
    void ReceiveMessage(IMessage message);
    void SendMessage(IMessage message);

What this list doesn’t tell us is for what reason these functionalities are executed. We are better off putting the responsibility of “why” (user management and control) in a separate entity – this way the User and Channel entities do not have to change should the “why” change. We can leverage the strategy pattern and DI here and can have any concrete implementation of IChannel depend on a IUserControl entity that gives us the "why".

public interface IUserControl
    bool ShouldUserBeKicked(IUser user, IChannel channel);
    bool MayUserJoin(IUser user, IChannel channel);

public class Channel : IChannel
    private IUserControl _userControl;
    public Channel(IUserControl userControl) 
        _userControl = userControl;

    public bool Add(IUser user)
        if (!_userControl.MayUserJoin(user, this))
            return false;

You see that in the above design SRP is not even close to perfect, i.e. an IChannel is still dependent on the abstractions IUser and IMessage.

In the end one should strive for a flexible, loosely coupled design but there are always tradeoffs to be made and grey areas also depending on where you expect your application to change.

SRP taken to the extreme in my opinion leads to very flexible but also fragmented and complex code that might not be as readily understandable as simpler but somewhat more tightly coupled code.

In fact if two responsibilities are always expected to change at the same time you arguably should not separate them into different classes as this would lead, to quote Martin, to a "smell of Needless Complexity". The same is the case for responsibilities that never change - the behavior is invariant, and there is no need to split it.

The main idea here is that you should make a judgment call where you see responsibilities/behavior possibly change independently in the future, which behavior is co-dependent on each other and will always change at the same time ("tied at the hip") and which behavior will never change in the first place.

Recently I came across this javalobby post on packaging java code by feature.

I like the idea, but i have few questions on this approach. I asked my question but didn't get a satisfactory reply. I hope someone on StackOverflow can clarify my questions.

I like the idea of package by feature which greately reduces the time for moving across the packages while coding and all the related stuff will be at one place(package). But what about interactions between the services in different packages?

Suppose we are building a blog app and we are putting all user related operations(controllers/services/repositories) in com.mycompany.myblog.users package. And all blog post related operations(controllers/services/repositories) in com.mycompany.myblog.posts package.

Now I want to show User Profile along with all the posts that he posted. Should I call myblog.posts.PostsService.getPostsByUser(userId) from myblog.users.UserController.showUserProfile()?

What about coupling between packages?

Also wherever I read about package by feature, everyone says its a good practice. Then why many book authors and even frameworks encourage to group by layers? Just curious to know :-)

There many other aspect other than coupling for package design i would suggest to look at OOAD Priciples, especially package design priciples like

REP The Release Reuse Equivalency Principle The granule of reuse is the granule of release.

CCP The Common Closure Principle Classes that change together are packaged together.

CRP The Common Reuse Principle Classes that are used together are packaged together.

ADP The Acyclic Dependencies Principle The dependency graph of packages must have no cycles.

SDP The Stable Dependencies Principle Depend in the direction of stability.

SAP The Stable Abstractions Principle Abstractness increases with stability.

for more information you can read book "Agile Software Development, Principles, Patterns, and Practices"

We are following Domain Driven Design for the implementation of a large website.

However by putting the behaviour on the domain objects we are ending up with some very large classes.

For example on our WebsiteUser object, we have many many methods - e.g. dealing with passwords, order history, refunds, customer segmentation. All of these methods are directly related to the user. Many of these methods delegate internally to other child object but
this still results in some very large classes.

I'm keen to avoid exposing lots of child objects e.g. user.getOrderHistory().getLatestOrder().

What other strategies can be used to avoid this problems?

The issues you are seeing aren't caused by Domain Driven Design, but rather by a lack of separation of concerns. Domain Driven Design isn't just about placing data and behavior together.

The first thing I would recommend is taking a day or so and reading Domain Driven Design Quickly available as a free download from Info-Q. This will provide an overview of the different types of domain objects: entities, value objects, services, repositories, and factories.

The second thing I would recommend is to go read up on the Single Responsibility Principle.

The third thing I would recommend is that you begin to immerse yourself in Test Driven Development. While learning to design by writing tests first won't necessarily make you designs great, they tend to guide you toward loosely coupled designs and reveal design issues earlier.

In the example you provided, WebsiteUser definitely has way too many responsibilities. In fact, you may not have a need for WebsiteUser at all as users are generally represented by an ISecurityPrincipal.

It's a bit hard to suggest exactly how you should approach your design given the lack of business context, but I would first recommend doing some brain-storming by creating some index cards representing each of the major nouns you have in your system (e.g. Customer, Order, Receipt, Product, etc.). Write down candidate class names at the top, what responsibilities you feel are inherent to the class off to the left, and the classes it will collaborate with to the right. If some behavior doesn't feel like it belongs on any of the objects, it's probably a good service candidate (i.e. AuthenticationService). Spread the cards out on the table with your colleges and discuss. Don't make too much of this though, as this is really only intended as a brainstorming design exercise. It can be a little easier to do this at times than using a whiteboard because you can move things around.

Long term, you should really pick up the book Domain Driven Design by Eric Evans. It's a big read, but well worth your time. I'd also recommend you pick up either Agile Software Development, Principles, Patterns, and Practices or Agile Principles, Patterns, and Practices in C# depending on your language preference.

What are the basic steps for Agile software development?
And how you start a new project with agile methodology?

have a look at "Agile Software Development, Principles, Patterns, and Practices" by robert marin. there is a java and a c# version.

I'll second Ilja's recommendation for the book:

I think the single most valuable piece of the book is the description of what practices to adopt first to achieve certain business values (quality, time to market, ...).

Reviews of the book: Sample Chapter:

Finally come join an Agile mailing list at either ScrumDevelopment or AgileProjectManagement will suit your needs well.

Recently I heard that there are 9 rules for OOP(Java). I know only four as Abstraction, Polymorphism, Inheritance and Encapsulation. Are there any more rules for OOP?

Seems like what you're looking for are the Principles of Object-Oriented Design.

Summarized from Agile Software Development Principles, Patterns, and Practices. These principles are the hard-won product of decades of experience in software engineering. They are not the product of a single mind, but they represent the integration and writings of a large number of software developers and researchers. Although they are presented here as principles of object-oriented design, they are really special cases of long-standing principles of software engineering.

SRP The Single Responsibility Principle A class should have only one reason to change.

OCP The Open-Closed Principle Software entities (classes, packages, methods, etc.) should be open for extension, but closed for modification.

LSP The Liskov Substition Principle Subtypes must be substitutable for their base types.

DIP The Dependency Inversion Principle Abstractions should not depend upon details. Details should depend upons abstractions.

ISP The Interface Segregation Principle Clients shold not be forced to depend upon methods that they do not use. Interfaces belong to clients, not to hierarchies.

REP The Release-Reuse Equivalency Principle The granule of reuse is the granule of release.

CCP The Common Closure Principle The classes in a package should be closed together against the same kinds of changes. A change that affects a closed package affects all the classes in that package and no other packages.

CRP The Common Reuse Principle The classes in a package are reused together. If you reuse one of the classes in a package, you reuse them all.

ADP The Acylcic Dependencies Principle Allow no cycles in the dependency graph.

SDP The Stable Dependencies Principle Depend in the direction of stability.

SAP The Stable Abstractions Principle A package should be as abstract as it is stable.

These OO principles are straight from Head First Design Patterns:

  • Encapsulate what Varies
  • Program to an Interface, rather than an Implementation
  • Favour Composition over Inheritance
  • A Class should have only one reason to Change (Single Responsibility Principle)
  • Sub-Types must be substitutable for their Base (Liskov Substitition Principle)
  • Classes shoule be Open for extension, but Closed for Modification (Open-Closed Principle)

The Interface Segregation Principle (ISP) says that many client specific interfaces are better than one general purpose interface. Why is this important?

ISP states that:

Clients should not be forced to depend on methods that they do not use.

ISP relates to important characteristics - cohesion and coupling.
Ideally your components must be highly tailored. It improves code robustness and maintainability.

Enforcing ISP gives you following bonuses:

  • High cohesion - better understandability, robustness
  • Low coupling - better maintainability, high resistance to changes

If you want to learn more about software design principles, get a copy of Agile Software Development, Principles, Patterns, and Practices book.

I need a urgent crash course on software development. We are about to start a major project at work. The project is a huge web application and I have been chosen to lead the team. The problem now is, I am not familiar with the software development process. The way I used to go about my development is think it and do it, but now I won't be able to do that because I have to collaborate with others. I will very much appreciate if someone can help with a link to a crash course. Thanks.

You want to look at Construx. It's owned by Steve McConnell, the author of Code Complete.

You'll probably want to read Rapid Development.

Bug tracking, source control and code reviews are your friend. You might want to read Agile Software Development and adapt some of those processes to your needs.

what book would you recommend to improve one's c# style of writing? I know Code Complete has a few tips on style and organizing code but it's not specific to c#.

I would also recommend Clean Code by Robert Martin. Yes, it's not C#-specific, and yes, it will improve one's C# style of writing. It might be a good idea to continue with Agile Software Development, Principles, Patterns, and Practices book by the same author.

And here is 1 hour video from uncle Bob at Øredev conference Clean Code III: Functions

PS: Shameless plug. I developed a site which answers exactly this question: "Which book is of higher importance in given area?". I get the data from Amazon, and draw a network of books. The more links one book has the higher its importance. Thanks to this site I also found "Agile Principles, Patterns, and Practices in C#", again by Robert Martin, but I prefer the original book.

CLR Via C# by Jeffrey Richter contains all the 2.0 patterns you need to follow in order to produce good code. Helped me immensely.

Effective C# by Bill Wagner, as well as the sequel, More Effective C#.

Elements of C# Style is a good primer.

While it may not go into as much detail as other books that are available but I've definetly got my moneys worth from it - highly recommended.

C# Concisely very thorough

I'm building a tiny MVC framework for learning/experimenting and small project purposes. I needed to find out the basics of the internals of the Model since a full MVC framework and ORM is overkill for just a few database calls.

Class Model

Using an empty class where would I have to call a new PDO object for database calls?

What would calling a query look like inside the Model?

Additionally, where can I find a beginner's web/book resource to MVC (with lots of example code)? I've heard a lot of terms such as business logic and database logic. I remember reading somewhere that you should separate business logic and database logic. I can understand the concept somewhat, I just wonder what it looks like or what they mean in code itself. I'm confused how business logic and database logic should be separated but still be inside the Model.

I'm mostly looking for code/logic examples as answers, except maybe the latter paragraph.

The information in this posts is extremely outdated. It represents my understanding of MVC pattern as it was more then 2 years ago. It will be updated when I get round to it. Probably this month (2013.09).

Model itself should not contain any SQL. Ever. It is meant to only contain domain business logic.

The approach i would recommend is to separate the responsibilities, which are not strictly "business logic" into two other other sets of constructs : Domain Objects and Data Mappers.

For example, if you are making a blog, then the Model will not be Post. Instead most likely the model will be Blog , and this model will deal with multiple Domain Objects: multiple instances of Post, Comment, User and maybe other objects.

In your model, the domain objects should not know how to store themselves in database. Or even be aware of the existence of any form of storage. That is a responsibility of Data Mappers. All you should do in the Model is to call $mapper->store( $comment );. And the data mapper should know how to store one specific type of domain objects, and win which table to put the information ( usually the storage of of single domain object actually affects multiple tables ).

Some code

(only relevant fragments from files):

  • I assume that you know how to write a good constructor .. if you have doubts, read this article
  • nothing is namespaced in example, but it should be
  • anything that begins with _ in example is protected

from /application/bootstrap.php

/* --- snip --- */

$connection = new PDO( 'sqlite::memory:' );
$model_factory = new ModelFactory( $connection );

$controller = new SomeController( $request , $model_factory );

/* --- snip --- */


/* --- snip --- */
  • controller does not need to be aware of database connection.
  • if you want to change DB connection for whole application, you need to change single line
  • to change the way how Model's are made, you create different class which implements same interface as ModelFactory

from /framework/classes/ModelFactory.php

/* --- snip --- */

class ModelFactory implements ModelBuilderInterface
   /* --- snip --- */

   protected function _prepare()
      if ( $this->_object_factory === null  )
         $this->_object_factory = new DomainObjectFactory;
      if ( $this->_mapper_factory === null )
         $this->_mapper_factory = new DataMapperFactory( $this->_connection );

   public function build( $name )
      return new {$name}( $this->_object_mapper , $this->_data_mapper );

   /* --- snip --- */

  • only data mappers will use database , only mapper factory need connection
  • all the dependencies of Model are injected in constructor
  • every DataMapper instance in the application uses same DB connection, no Global State (video) required.

file /application/controllers/SomeController.php

/* --- snip --- */

   public function get_foobar()
      $factory = $this->_model_factory;
      $view = $this->_view;

      $foo = $factory->build( 'FooModel' );
      $bar = $factory->build( 'BarModel' );

      $bar->set_language( $this->_request->get('lang') );

      $view->bind( 'ergo' , $foo );

      /* --- snip --- */


/* --- snip --- */
  • controller is unaware of model creation details
  • controller is only responsible for wiring and changing the state of elements

file /application/models/FooModel.php

/* --- snip --- */

   public function find_something( $param  , $filter )
      $something = $this->_object_factory('FooBar');
      $mapper = $this->_mapper_factory('FooMapper');

      $something->set_type( $param );
      $mapper->use_filter( $filter )->fetch( $something );

      return $something;

/* --- snip --- */
  • domain object is responsible for validating the given parameters
  • view receives and decides how to present it
  • mapper takes the object and puts in it all the required information from storage ( it doesn't have to be DB .. it could be taken from some file, or an external REST API )

I hope this will help you understand the separation between DB logic and business logic ( and actually , presentation logic too )

Few notes

Model should never extend Database or ORM, because Model is not a subset of them. By extending a class, you are declaring that has all the characteristics of the superclass, but with minor exceptions.

class Duck extends Bird{}
class ForestDuck extends Duck{}
// this is ok

class Table extends Database{}
class Person extends Table{}
// this is kinda stupid and a bit insulting

Besides the obvious logic-issues, if your Model is tightly coupled with underlaying Database, it makes the code extremely hard to test (talking about Unit Testing (video)).

I personally think, that ORMs are useless and in large project - even harmful. Problem stems from the fact that ORMs are trying to bridge two completely different ways of approaching problems : OOP and SQL.

If you start project with ORM then, after short learning curve, you are able to write simple queries very fast. But by the time you start hitting the ORM's limitations and problems, you are already completely invested in the use of ORM ( maybe even new people were hired , who were really good at your chosen , but sucked at plain SQL ). You end up in situation where every new DB related issue take more and more time to solve. And if you have been using ORM based on ActiveRecord pattern, then the problems directly influence your Models.

Uncle Bob calls this "technical debt".

Few books

loosely related to subject

I am starting my graduate thesis and the subject will be "agile architectures"

Basically, it will start with a description of traditional software development methologies, and the subsequent birth of agile methodologies, finishing with recommendations and a design of a flexible application architecture easily adaptable to the inherent changes in software construction.

My question is, what patterns and design practices would you recommend for such an architecture? I'm interested in patterns that allow for maximization of class decoupling like dependency injection, high maintanability, and maximum abstraction from the specific problem.

If Robert Martin has anything to say about it (and he called the original Agile Manifesto meeting IIRC), then absolutely architecture has everything to to with Agility. The entire first section of his book Agile Software Development, Principles, Patterns, and Practices is about the SOLID architectural principles. This has been somewhat controversial in some quarters but I don't understand why. If your codebase is brittle and heavily coupled then it cannot be very open to change, which is the hallmark of agility. Conceptually separating process from code practice is a very un-agile thing to do.

Principle 1 of the manifesto: "We value individuals and interations over processes and tools."

Defining Agile "process" as an abstraction separate from the architecture of the codebase to me violates the spirit of this first principle.

I find that whenever I begin writing an app in Java/C#, things start off good, but over time, as the app becomes more complex, it just gets more and more complicated. I've become aware of the fact that I'm not very good at design and high level architecture. All my classes become fairly strongly coupled and the design isn't "elegant" at all. I'm fairly competent at "low level" programming. That is, I can get just about anything done within a function or a class, but my high level design is weak and I'd really like to improve it. Does anyone have pointers to techniques, books, etc. that would be helpful in making me a better software engineer?

The answer to your question could fill a book on its own, but I'd suggest you take a look at design patterns.

The classic book on the subject is referred to as the "Gang of Four" book:

Gang of Four Design Patterns Book

Martin Fowler is also highly regarded in the field.

I disagree about starting with a book on design patterns or refactoring.

In my opinion, for a solid OO design, you should first be familiar with the main OO design principles, then understand how your problem can be represented in those basic principles. Then you can start discovering opportunities for applying design patterns and refactoring techniques in order to achieve those fundamental principles.

I would start with this book:

Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin

In this book, Robert Martin describes the fundamental principles that make a good OO design, all of them related to encapsulation, coupling and modularity:

  • The Open/Closed Principle
  • Liskov Substitution
  • Dependency Inversion
  • Granularity
  • Common Closure
  • Reuse
  • No Cyclic Dependency
  • Stability Of Dependency
  • Abstraction And Stability

After all, almost every Design Pattern and Refactoring technique I have seen documented in GoF and Fowler is aimed at achieving one of several of these basic principles, depending on their relative priority for a given scenario.

Obviously, reading some of the recommmended books will help. I think Head First Design Patterns is definitely less abstract than GoF book.

The primary question I ask is "Is this code doing something very specific that could be re-used anywhwere else?" If so, put in in a class in an assembly that allows for re-use.

If you truly are just starting then one thing I used to do was to consider each database table an 'object'. So each database table represents a class. The purists will tell you this is a disaster, but I found it a good way to get myself started thinking in object terms.

I'm very new to TDD world. I have a few questions regarding TDD.

  1. Do I have to do test-first in TDD? I heard that TDD is not about test. It's about design. I'm agreed that it's good to do test-first but what I like to know is that is it still TDD if we follow the test-last approach?

  2. Shall we prefer to use BDD over TDD? I used to list out the specification of my task first and I try to write the test case based on my specification. Is it wrong approach? Do you guys prefer using BDD or TDD for your development?

  3. Mocking? Some people from my team used to say that they are praticsing TDD. But they never follow test-first approach. they never mock the data. Do we have to mock the data in TDD?

  4. "Using Mock Library" Vs "creating the mock class with data manually". Do you prefer to use mock library or create the mock classes with some mock data?

  5. Any recommended book for TDD or BDD? I read Kent Beck's classic Test-Driven Development - By Example. I found that this book is published in very early stage of TDD so some of the things in this book are not a bit outdated.

(I picked the easiest question to answer as I am not qualified to answer other questions )

Any recommended book for TDD or BDD?

Agile Software Development, Principles, Patterns, and Practices , by Robert C. Martin

Extreme Programming Explained ,by Kent Beck

Is there a name or a particular rule for objects that contain objects that contain... and so on. I'm working with a complex system that often has objects running 5-10 layers deep. One reason I'm hearing for why this is done is to pass a lot of data from server to client all at once, is there a better way to do this?

Edit: It seems that it is a combination of a few anti patterns. The Domain model should be cleaned up, and the following antipatterns are the smells: Train Wreck Pattern, and Everything but the kitchen-sink map

Objects containing objects containing… etc

is called a list and perfectly fine ;)

But you are right, long sequences of method calls is all but fine and a clean code smell called inappropriate intimacy.

Inappropriate intimacy can increase coupling, decrease cohesion, goes against the law of demeter and the rule tell, don't ask.

References: If you look up those terms, you will find a fantastillion many answers. Particularly good ones are Cohesion and Coupling and the book Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin.

Like there are many Applications which are just basic but you can have install add-ins for it which extends its functionality in that Application. For example:

Fire Bug in Mozilla Firefox.

How do they design such applications and how does the application accept the module and how can it automatically integrate.

Secondly I do not know if the above process is generic or some language or tool dependent. Can we make such application in WPF or Winforms?

If you're focussed on WPF and .NET specifically, check out Mono.Addins. There is a list of projects that use Mono.Addins on the documentation site - I'm sure that you can find many examples of how to write an add-in ready application from there.

As far as the correct design goes, this is a little tricky to get right. If you follow the packaging principles mentioned in Robert C. Martin's book, Agile Software Development, Principles, Patterns and Practices, the design of your application will naturally allow for addins. Two principles that are of particular importance is the Dependency Inversion Principle and the Stable Abstraction Principle.

Are there objective metrics for measuring code refactoring?

Would running findbugs, CRAP or checkstyle before and after a refactoring be a useful way of checking whether the code was actually improved rather than just changed?

I'm looking for trends we can capture that can help us improve the code review process without wasting time on code that gets changed for simple personal preference.

Yes, several measures of code quality can tell you if a refactoring improves the quality of your code.

  • Duplication. In general, less duplication is better. However, duplication finders that I've used sometimes identify duplicated blocks that are merely structurally similar but have nothing to do with one another semantically and so should not be deduplicated. Be prepared to suppress or ignore those false positives.

  • Code coverage. This is by far my favorite metric in general, but it's only indirectly related to refactoring. You can and should raise low coverage by writing more tests, but that's not refactoring. However, you should monitor code coverage while refactoring (as with any other change to the code) to be sure it doesn't go down. Refactoring can improve code coverage by removing untested copies of duplicated code.

  • Size metrics such as lines of code, total and per class, method, function, etc. A Jeff Atwood post lists a few more. If a refactoring reduces lines of code while maintaining clarity, quality has increased. Unusually long classes, methods, etc. are likely to be good targets for refactoring. Be prepared to use judgement in deciding when a class, method, etc. really does need to be longer than usual to get its job done.

  • Complexity metrics such as cyclomatic complexity. Refactoring should try to decrease complexity and not increase it without a well thought out reason. Methods/functions with high complexity are good refactoring targets.

  • Robert C. Martin's metrics: Abstractness, Instability and Distance from the abstractness-instability main sequence. He described them in his article on Stability in C++ Report and his book Agile Software Development, Principles, Patterns, and Practices. JDepend is one tool that measures them. Refactoring that improves package design should minimize D.

I have used and continue to use all of these to monitor the quality of my software projects.

There has been a lot of discussion on the subject of “Open Closed Principle” on stackoverflow. It seems however, that generally a more relaxed interpretation of the principle is prevalent, so for example the Eclipse is open for modification through plug-ins.

According to strict OCP, you should modify the original code only to fix bugs, not to add new behaviour.

Are there any good examples of strict interpretation of OCP in public or OS libraries, where you can observe evolution of a feature through OCP: there is a class Foo with method bar() and than there is a FooDoingAlsoX with foo2() method in the next version of the library, where original class has been extended where original code was not modified.

EDIT: According to Robert C. Martin: “The binary executable version of the module, whether a linkable library, a DLL, or a Java .jar remain untouched”*. I never see libraries kept closed, in practice new behaviour is added to a library and new version published. According to OCP, new behaviour belongs to new binary module.

*Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin


In page 100 of PPP Robert Martin says

"Closed for modification"
Extending the behavior of a module does not result in changes to the source or binary code of the module. The binary executable version of the module, whether a linkable library, a DLL, or a Java .jar, remains untouched.

Also on page 103 he discusses an example, written in C, where a non-OCP design results in recompiling the existing classes:

So, not only must we change the source code of all witch/case statements or if/else chains, but we also must alter the binary files (via recompilation) of all the modules that use any of the Shape data structures. Changing the binary files means that any DLLs, shared libraries, or other kinds of binary components must be redeployed.

It's good to remember that this book was published in 2003 and many of the examples use C++, which is a language notorious for long compile times (unless header file dependencies are handled well - developers from Remedy mentioned in one presentation that Alan Wake's full build takes only about 2 minutes).

So when discussing binary compatibility in the small scale (i.e. within one project), one benefit of OCP (and DIP) is faster compile times, which is less of an issue with modern languages and machines. But in the large scale, when a library is used by many other projects, especially if their code is not in our control, the benefits of not having to release new versions of the software still apply.


As an example of an open source library which follows OCP in binary compatibility, look at JUnit. There are tens of testing frameworks which rely on JUnit's @RunWith annotation and Runner interface, so that they can be run with the JUnit test runner - without having to change JUnit, Maven, IDEs etc.

Also JUnit's recently added @Rule annotation allows test writers to plug into standard JUnit tests custom behavior, which would before have required a custom test runner. Once more an example of library-level OCP.

To contrast, TestNG does not follow OCP, but contains JUnit specific checks to execute TestNG and JUnit tests differently. A representative line can be found from the method:

  if(test.isJUnit()) {
  else {

As a result, even tough the TestNG test runner has in some aspects more features (for example is supports running tests in parallel), other testing frameworks do not use it, because it's not extensible to support other testing frameworks without modifying TestNG. (TestNG has a way to plug in custom test runners using the -testrunfactory argument, but AFAIK it allows only one type of runner per suite. So it would not be possible to use many different testing frameworks in one project, unlike with JUnit.)


However, in most situations OCP is used within an application or library, in which case both the base module and its extensions are packaged inside the same binary. In that situation OCP is used to improve the maintainablity of the source code, and not to avoid redeploys and new releases. The possible benefit of not having to recompile an unchanged file is still there, but since compile times are so low with most modern languages, that's not very important.

The thing to always keep in mind is that following OCP is expensive, as it makes the system more complex. Robert Martin talks about this on PPP page 105 and the conclusion of the chapter. OCP should be applied carefully, for only the most probable changes. You should not preemptively put in the hooks to follow OCP, but you should put in the hooks only after a change happens that needs them. Thus it is unlikely to find a project where all new features would have been added without changing existing classes - unless somebody does it as an academic exercise (my intuition says that it would be very hard and the resulting code would not be clean).

I like reading open-source code to see how particular problems have been solved, or simply to study how to create nice and clean code.

I was wondering if there actually was any good book out there that goes through excerpts of different (preferably in Java) open-source projects to show how patterns have been used and implemented, some nifty tricks, etc.?

Update: I took design patterns as an example, but it’s not really what I am after. I read a lot of open-source code, and I often find interesting ways of doing things which I didn’t think of before – my question is whether there is a book that shows some “cool” open-source code, a bit like how Clean Code uses FitNesse code to illustrate refactoring and other points.

Well, you can read just book about open source project, and authors can show what and how. E.g. I read Pro Spring 2.5 and there is even chapter called "Spring Patterns" with explanation of why and how they call files, directories, design patterns they use and invite you to use etc. Probably take a look at the books about open source projects you investigate.

UPDATE (just that paragraph insert to extend answer:) : as I told previously, you can look through the books about open source projects and find there information how this project is developed, architectural issues etc. Once I looked for real good example of "Open/Closed Principle" using, theory is nice but I would not say that it is so clear how to use it. The only book which helped me was Expert Spring MVC and Web Flow (I already pointed you to google books with that chapter I read). I didn't read the whole book, but I am sure it contains a lot of such things (what and how was used to make Spring done). From book Clean Code: A Handbook of Agile Software Craftsmanship I remember that there is a chapter, when they take a code from one open source project and make it better (unfortunately open source does not mean that it is good enough); that book also contain reference to how some other projects where written (e.g. jUnit). I don't know any book, which is completely dedicated to any project, there are just books where is "theory", and books about project which can have some explanation of what is inside. I would recommend books from APress (Pro and Expert series, afaik "beginning" books does not contain such explanation), and Packt Publishing - their main topic is open source.

UPDATE 2 (just can't stop :) Just remembered new series of books from OReilly "Beautiful ...." - I never read it, but I looked through. It actually consists of different stories behind development, real stories from life. I see there is also Beautiful Code: Leading Programmers Explain How They Think - I should contain what you need. Other "beautiful" books can be worth of your time too.

About patterns in general there are a lot of good books, and it depends on what exactly are you looking for. E.g. Head First Design Patterns is quite good to explain common patterns in fun way. If you need more, you can take a look at Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions to see how different applications, systems etc. can be integrated (and how open source projects do it too). Etc. Just specify what patterns or tricks do you want to read about, community will make its suggestion ;)

Some web links out of my bookmarks:

  1. Anti Patterns Catalog - know what you are not going to do!
  2. Design Patterns and Martin Fowler's Catalog - that's shortly about what is good to use and know about
  3. SOA patterns - community site for SOA patterns (integration etc.)

And few more books to take a look at:

  1. Head First Object-Oriented Analysis and Design
  2. Agile Software Development, Principles, Patterns, and Practices
  3. Code Complete - this book is just a bible of how to write code...

people, who develop open source definitely know what are those books about ;)

Hope that helps

UPDATE (25-05-2011) Just found one book, which I definitely going to buy, and I think it perfectly fits your question:

The Architecture of Open Source Applications
enter image description here

Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters. In contrast, most software developers only ever get to know a handful of large programs well — usually programs they wrote themselves — and never study the great programs of history. As a result, they repeat one another’s mistakes rather than building on one another’s successes. This book’s goal is to change that. In it, the authors of twenty-five open source applications explain how their software is structured, and why. What are each program's major components? How do they interact? And what did their builders learn during their development? In answering these questions, the contributors to this book provide unique insights into how they think. Electronic versions of The Architecture of Open Source Applications for e-readers will be available for download soon.

What tips/suggestions do you have for writing more understandable code?

I've been somewhat frustrated by the lack of structure and bad format of some code I've been maintaining lately and would like to propose a series of guidelines for writing more understandable code.

Any suggestion might help, no matter the language.


The key to writing maintainable code is to follow some fundamental code design principles:

  1. Single Responsibility Principle - SRP - One class must implement one responsibility.
  2. DRY - almost reciprocal to SRP - Don't repeat Yourself - in other words don't let the same responsibility be implemented by multiple classes (for it would result in repetition of the same code)
  3. Make vertical slices of the application and call each slice a module. Come up with a modular structure with clear cut dependencies between modules. Publish a module structure for the project and enforce that the team complies to it. Obviously no cyclical dependencies. Use a tool like maven or apache ivy for dependency management during builds.
  4. Have an approach to implement non functional requirements as horizontal requirements using strategies such as AOP, decorators etc.

With these things in place, most of the code would become maintainable. Each of the points above is itself pretty involved. I absolutely love this book.

Look at blogs etc where these things are discussed. All the best

I liked these books:

You should also read code. If the code is hard to read, ask yourself what exactly the author did or didn't do that makes it hard to understand, and more importantly, how you can use what you've learned to write better code yourself.

Five years ago I used to program in SAS. Since then I've been doing software QA of various types. Mostly manual (video games + web apps) testing with a tiny bit of automation.

I'd really like to shift careers back into programming. Specifically the Android platform has caught my attention. These are the books I've been reading and working through.

  • Learning Java, Third Edition - O'Reilly
  • Beginning Android 2 - Mark Murphy
  • Hello, Android - Ed Burnette

However, I think I need something that looks at programming from a less language dependent standpoint. Something that takes a bird's eye view if that makes sense.

It's very easy to see how particular functions work, but I'm looking to get a better sense of how all the pieces fit together. How does one split up an app into individual classes and packages? Do I have a method in main that shuffles my deck of cards (object) or does the class deck of cards have a method I can call to shuffle itself?

I think I'm looking for a book on object oriented design?

I've also been working through the tutorials and examples at and also in the three books I've been reading so far.

Maybe I just need to spend more time coding though?

You might want to read about design patterns. The classic book is Design Patterns by the "gang of four", Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.

The books that did the most for me are: Agile Software Development, Principles, Patterns, and Practices (among many other design issues, this one actually tackles strategies for organizing an app into packages, which is pretty interesting) and Head First Design Patterns which is, I think, a much easier read than the Gang of Four book mentioned earlier.

Good luck!

Ideas on how to develop software that is capable of adapting to meet changing business requirements? Any patterns, architectures, etc. Possibly some anecdotal examples would be great. This is more of a survey than a concrete questions. Thanks

You will want to learn more about the entire Agile Development movement. Agile is just what it says: able to quickly adapt.

I've been a software developer for 10 years and came all the way from a wild world of assembly language programming, then server side of C++ and COM, and for the last 5 years I was comfortably settled in a quiet world of .NET, C# and development of business applications.

The problem is - the last couple of years was so comfortable and I was also spending almost half of my time doing a BA's work, that I feel like I forgot a good part of low level C# language, Design Pattern and ASP.NET. And after almost 5 years of not using C++ for a big projects my skills in that language are even worse.

That does not mean I can't program - I do it every day and quite successfully - but I feel what I would not be able to pass most of tough job interviews should the need arises, which is very likely in a current recession. And the reasons I think I would not pass - is that I forgot all the standard things what usually people are being asked on the interviews (e.g. I use the design patterns - but if you ask me - which pattern what that - I would probably not give you the correct name, because all he DP for me are just a smart ways of using static functions and virtual functions).

Can someone please point me to a resource or give me an advice (can I have both please?), how can I quickly (in a week or so) could brush up my knowledge of C#/.NET, DP and ASP.NET to the level of the very good senior dev (whom I was a 2 years ago). As for the C++ - I am willing to spend a month to get my knowledge back again, but this is of less priority.

Please do understand me right - I am not a newbie and all these things I knew before - just want to be back in business 100% again.

Thank you.

Design Patterns are covered in many books today. The stanard of course is the "Gang of Four" book named "Design Patterns".

Put OO, Agile and Pattern together

Another book is more hands-on and combines Design Patterns with an other new thing -- "Agile Development". The good thing is, that design patterns are presented in live examples and interestingly presented in context. I think Robert C. Martin also brings a lot of insight into many OO development principles. The book is called Agile Software development.

But of course, it depends how far you want to go. Do you really want to brush up your knowledge (then I could maybe give further hints) or do you want to just be upto date for interviews?

I've worked with designing databases for a loooong time, and these days I'm working in C# too. OO makes sense to me, but I don't feel that I have a good grounding in the deep theory of OO design.

In database land, there's a lot of theory around how to design the structure of a database, the main notion being normalisation. Normalisation directly steers the structure of a database and to some extent dictates how to arrange entities in a database.

Are there any similar concepts behind how to design the structure of an Object-Oriented program?

What I'm reaching for is one or more underlying theoretical principles which naturally guide the developer into the "correct" design for the solution to a given problem.

Where can I look to find out more?
Is there a go-to work I should read?


Thanks to everyone for their answers. What I'm reading seems to say that there is no "Grand Theory of OO Design", but there are a bunch of important principles - which are largely exemplified by design patterns.

Thanks again for your answers :)

The book "Design Patterns" is your next step.

But, you don't have to use an OO approach to everything. Don't be religious about it. If a more procedural approach feels more straitforward, then go with that. People new to OO tend to overdue it for a while.

I think Agile Software Development, Principles, Patterns, and Practices is quite good.

It provides a lot of in-depth disccusion of OO principles listed here:

  • The principles of Object Oriented Design and Dependency Management
  • SRP — The Single Responsibility Principle
  • OCP — The Open Closed Principle
  • LSP — The Liskov Substitution Principle
  • DIP — The Dependency Inversion Principle
  • ISP — The Interface Segregation Principle
  • REP — The Reuse Release Equivalency Principle
  • CCP — The Common Closure Principle
  • CRP — The Common Reuse Principle
  • ADP — The Acyclic Dependencies Principle
  • SDP — The Stable Dependencies Principle
  • SAP — The Stable Abstractions Principle

Be careful some of the design patterns literature.

There are are several broad species of class definitions. Classes for persistent objects (which are like rows in relational tables) and collections (which are like the tables themselves) are one thing.

Some of the "Gang of Four" design patterns are more applicable to active, application objects, and less applicable to persistent objects. While you wrestle through something like Abstract Factory, you'll be missing some key points of OO design as it applies to persistent objects.

The Object Mentor What is Object-Oriented Design? page has mich of you really need to know to transition from relational design to OO design.

Normalization, BTW, isn't a blanket design principle that always applies to relational databases. Normalization applies when you have update transactions, to prevent update anomalies. It's a hack because relational databases are passive things; you either have to add processing (like methods in a class) or you have to pass a bunch of rules (normalization). In the data warehouse world, where updates are rare (or non-existent) that standard normalization rules aren't as relevant.

Consequently, there's no "normalize like this" for object data models.

In OO Design, perhaps the most important rule for designing persistent objects is the Single Responsibility Principle.

If you design your classes to have good fidelity to real-world objects, and you allocate responsibilities to those classes in a very focused way, you'll be happy with your object model. You'll be able to map it to a relational database with relatively few complexities.

Turns out, that when you look at things from a responsibility point of view, you find that 2NF and 3NF rules fit with sound responsibility assignment. Unique keys still matter. And derived data becomes the responsibility of a method function, not a persistent attribute.

For many years, I have been re-reading John Lakos's classic Large-Scale C++ Software Design. Not only it was the first guidebook of this kind, but it also revolutionized how to develop a project in C++, in an efficient fashion to this day!

Do you feel his ideas are outdated now? Some C++ techniques in the book are in fact old (don't forget that book has been written before the latest standard was published) .

What's a good authority to guide building of a big system in C++ nowadays.

Don't get me wrong, I am not giving up Lakos at all. It will always be referenced for me, and occupy a prime location on the bookshelf.


Interestingly, his next book, Scalable C++: Component-Based Development, is anticipated in 2006.

I don't think it has ever came to fruition... one day it may!

Also, Agile Principles and patterns are widespread and effective software developing paradigm. I am shifting my gears in that directions.

Check out this book: Agile Software Development, Principles, Patterns, and Practices

I think I am pretty good with programming C# syntax. What I am looking for now is some resources, books(preferable), websites, blogs, that deal with the best way to design object oriented Desktop Applications and Web applications, especially when it comes to data and databases.


Martin Fowler's Enterprise-Application-Architecture is a great book for common pattern's you'll see in a lot of client server applications.

More of a book on thinking about object oriented problems is Eric Evan's Domain-Driven Design: Tackling Complexity in the Heart of Software

You are asking to drink from a firehose. Let me encourage you to write some small programs before you tackle big ones. However, here are a few books about design and a paper which argues that a lot of design can't be learned from books:

  • On System Design is a good short paper that articulates what a lot of experienced programmers think about the art of design.

  • Programming Pearls by Jon Bentley presents some lovely examples of design in the small. It's a fun read and includes many classic stories.

  • The Unix Programming Environment by Kernighan and Pike presents one of the great software-design philosophies of the 20th century. Still required reading after almost 25 years.

  • Software Tools in Pascal is narrower and deeper but will tell you a lot about the specifics of building software tools and the design philosophy.

  • Abstraction and Specification in Program Development by Barbara Liskov and John Guttag will teach you how to design individual modules so they can fit with other modules to form great libraries. It is out of print but your local University library may have it.

  • C Interfaces and Implementations presents a very well designed library that gives C programmers the abstractions found in much higher-level languages.

  • Finally, Test-Driven Development will teach you how to articulate and develop a design through the stuff that matters: what your software actually does.

I learned a lot from Composite/Structured Design by Glenford Myers, but it bears a little less directly on the topics you asked about. It talks primarily about good and bad ways modules can interdepend.

For a book on how to develop software I would recommend The Pragmatic Programmer. For design you may want to look at Interface Oriented Design. Code Complete is an "A to Z" reference on developing software. You might also want to consider the O'Reilly Head First books, especially Head First Object-Oriented Analysis and Design, as something a little easier to start with.

EDIT I don't know how I forgot about Bob Martin, but you could also read any of the books that Object Mentor has on any of it's lists. Here is their section on Software Design. In particular I'd recommend Agile Software Development: Principles, Patterns, and Practices (Amazon, but it's also the second book on the Object Mentor list).

I haven't been thrilled with any of the recent books, so much so that I'm seriously thinking about writing a new one. The "Head First" books generally have read to me ike one step above the "For Dummies" books (to be fair, I haven't read that one.)

I'm actually fond of Peter Coad's Java Design; you can get one cheaply used, it's no longer in print. Obviously, it's Java heavy, but the design part is good, and pretty lightweight.

Ivar Jacobson's Object Oriented Software Engineering is also very good (it introduced the idea of "use cases", among other things) and does appear to still be in print, but there are zillions of used copies around.

As we know, nearly every complex architecture contains multiple layers. In a management system, we can easily come up with data access layer, business logic layer, and presentation layer without too much thinking. I want to know if there is a clear principle for how to create multiple layers. PS: It's not limited to management system.

In software engineering, when designing systems, you have to adhere to certain design principles. If you do this right, the layers pretty much emerge on their own. Some of the principles are:

  1. Open/Closed
  2. Single Responsibility
  3. Interface Segregation
  4. The Release Reuse Equivalency
  5. The Common Closure

There are others as well. You can read about them online or get a book by Robert Martin called "Agile Software Development, Principles, Patterns, and Practices"

Here's a link to the relavent chapter from the book.

I am new to object oriented programming and learning to design classes.

I am wondering how can i design a class which holds list of itself.

For example, I have a class named Game will following definition:


  • title
  • description
  • screenshot
  • flash (holds flash game object)

I want to display list of games on a page. What approach is good for it? Either create another class GameList and create array of Games to be listed or create a function Game.ListAll to display game list?

I feel former is better approach to do so. I need your guide please. Also i dont know what to actually study to clear my concepts in designing class and their relationships etc. Can you please suggest me a book CBT which is easy to understand ?

Thank you very much.


I think it would be a bad design to have a (static) method listAll() within Game: Games shouldn't know about other games, you would need the constructors or factory methods to take care of the list, and you couldn't handle separate lists.

So use a list outside of Game. If you do not need special behavior of the GameList, a field List where you treat the list will do. If you have special behavior, your design with GameList is the right choice.

For good OO design, I would read up in the following order:

  1. the relevant articles from the object mentors article list to get an overview. You can find links to the most relevant for you at principles of ood.
  2. a book about design patterns, my favorite still being the classical Design Patterns from the GoF
  3. read Agile Software Development, Principles, Patterns, and Practices from Uncle Bob

I am writing an android app that has two different background services, one to send and receive requests from a server, and one to download images from url's. Multiple pages of the app need to do these activities, so I wrote two interfaces, RequestReceiver for handling server requests, and ImageReceiver for downloading images.

To receive a broadcasted intent in Android, I am extending the BroadcastReceiver class and overriding its onReceive() method. This should be done via an inner class in the intent that calls a method in the class that implemented it. But, I can't call a non-static method from my static inner class.

public interface RequestReceiver {
    void handleRequest(int status, JSONObject object);

    class Receiver extends BroadcastReceiver {
        public void onReceive(Context context, Intent intent) {
            int status = intent.getIntExtra("STATUS", -1);
            try {
                JSONObject object = new JSONObject(intent.getStringExtra("DATA"));
                handleRequest(status, object);
            } catch (JSONException e) {
                Log.e(this.toString(), "JSONException");

This doesn't compile:

non-static method cannot be referenced from a static context

What should I do differently?

EDIT: The reason I can't use an abstract class is that I need multiple inheritance. Some activities need to be ImageDownloaders and not RequestReceivers, and vice versa. Also, the classes that are implementing this interface are already inheriting from other classes. Some are extending Fragment and others are extending Activity, but they both need access to these abilities. Thus, it must be an interface.

I should drink coffee before jumping into StackOverflow.


you're trying to access a non-static method from your static inner class (that's how Java works).

Although some methods to provide a workaround have been provided, this usually highlights a higher level architecture problem.

Why are you having a class inside an interface and why is this class a BroadcastReceiver?

Shouldn't you be trying to abstract this a little bit differently?

I would personally frown at such code. What is the intent you're trying to explain in your code? When I read this code, what am I supposed to infer from it? What's the intention of such interface?

Am I supposed to use this interface and care that there's a broadcast receiver in it?

I think you should reconsider writing this code differently, rather than try to fight the tools/language.

How would I approach your problem?

Multiple pages of the app need to do these activities

1) Send and receive requests from a server

2) Download images from url's

Why not create these implementations in an abstract classes that each activity can extend when they need such behavior. (You can interface the methods later if you really need them).

The details of each implementation doesn't really concern the children. Nor you want to change each activity should your "image downloader" code changes.

Re-think your problem :)


I have the feeling you're lost in the "Object Oriented" world. I strongly recommend you take a look at this (old but still valid) book: Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin.

Don't be fooled by its title tho, this is not a book about "Scrum meetings".

I don't know the implementation details about your problem in particular, but I suggest you re-think your design; image downloading and network request/response have nothing to do with activities per-se and should not have to be implemented by an activity through an interface.

You should consider having a more "Factory-Oriented" approach (And I hate naming "patterns" because I think they tend to "over-complicate" things).

Although I don't agree 100% with the suggestions made in this other book, I also recommend it. I've learned a few interesting things out of it and I think it's a prequel of the Agile one, written years later ;)

An Activity that has to make a request, should call your DAO (Data Access Object) and request for the data. The data may come from the network, may come from a local cache, may come from a local file, who knows. The activity certainly doesn't care. And it shouldn't.

Downloading an image from a URL is probably left to a simple and robust library like Picasso, but if you insist on writing your own, then, the implementation and usage should never be tied to a particular Activity.

Without any more information, it's hard to tell what exact problem you're facing and how you are trying to solve it.

Your particular problem (the non-static method error) is a clear indicator that you're trying to go towards a non-standard/hacky solution and you should take a couple of steps back before it's too late (as the second book I linked will happily explain) ;)

I try to research every pages about UML. There none of impact about UML.. anyone have this experienced before? what i mean is the standard of terminology and diagramming itself.. and the reason why uml so important for the success of the object oriented...

The book "Agile Software Development, Principles, Patterns, and Practices" goes through many of the components of the UML diagrams and describe their use in designing an OO architecture. For some of the diagrams, the author's suggestions boiled down to "keep it simple". Use case diagrams, for example, is shafted in favor for just written use cases. An alternative for complex state diagrams is offered in the form of a state transition table.

At the beginning of the book, the author describes several principles for OO design, such as the dependency inversion principle and the single responsibility. Those have nothing to do with UML. UML is a communication tool which purpose is to allow one to visualise the architecture. Different components of UML has a different purpose- class diagrams for the architecture, object diagrams how objects interact with each other, sequence diagrams for interaction with objects (and itself) over time.

So is UML responsible for the success of OO design? I think UML coming along shows that OO design is worthwhile because UML is to used to present OO design. Same way with that Jackson diagram was used for structural programming.

I am try to learn DDD, so bear with me please. Let say I have an aggregate called Issue. It has a StatusId property. This status can be ie. Open, Closed... and it is stored in a database table called Statuses. (this is because specific user can have specific statuses, so I want the user be able to add new statuses) Now, I have crated a method like this in the Issue aggregate: public static void SubmitIssue(Guid projectId, string issueTitle, string description...)

this method Creates new Issue with the req. params and after that I need to set it into the correct state. But the state is specified in the DB. How to handle this scenario when I must get the data from the DB when doing business logic that must not be couplet do the database access at all? Please help

Your problem is a little more than just a DDD one. It is really about OO design. The problem is that you do not want an enum that will force you to make decisions all over the place. -Littering code with ugly switch and if statements.

There is no easy or precise answer to this.

What I would try to do:

You have Issue class (that can be different types) which means you could inherit and implement concretes based on that type. Important though! If the Issue can change from one type to another, inheritance on the Issue class is the wrong route. In that case you need to move the logical differences of those types (and the business rules they apply) onto the IssueType class, and your Issue class will have to be constructed with the relevant IssueType.

Uncle Bob has a very nice example that is very similar to your problem that he discusses in his book:

Of course he does not speak about the DB in the example, but that is kind of the point of DDD.

I have the PDF version so pages may differ slightly. :Pages 454 to 456 discusses the specific use case.

Really hope this helps somewhat. -almost wish I was working with you on this in a team and could solve it.

I'm reading some text files to create objects from. Which class should process the text files according to OOP principles?

I have my GUI object with a method to draw a table and fill it with data. This data is either parsed from an HTML page, or read from a cached text file. I can think of two ways to handle this, and I'd like to know which one is better.

Option 1:

public void drawSchedule()
            if (CacheManager.hasData("schedule")) //this is not the complete logic, but enough for this post
                String cacheString = CacheManager.readData(this, "schedule");

                Schedule schedule = new Schedule(cacheString);
                //read data from HTML page
        catch (IOException e)
            //generic error handling

Option 2:

public void drawSchedule()
        if (CacheManager.hasData("schedule")) //this is not the complete logic, but enough for this post
            String cacheString = CacheManager.readData(this, "schedule");

            //parse data here so we end up with a bunch of variables

            //courseList would be an ArrayList of Courses, if it makes any difference
            Schedule schedule = new Schedule(firstDay, courseList);
            //Read data from HTML page
    catch (IOException e)
        //generic error handling

I vote for Option 1.

Schedule should know how to create itself from a String or an HTML page. None of that logic should be in drawSchedule, whose job should simply be, as one might guess, to draw a Schedule. You want to separate the concerns of building a Schedule from drawing it.

Since this won't be too hard to do, you might as well do it. But be careful trying to be too elegant too soon. As Bob Martin advises in Agile Software Development, Principles, Patterns, and Practices with "taking the first bullet" and Nathan Marz advises with "suffering-oriented programming," don't be so quick to be as "pretty" as possible. Make everything work first; then refactor to a more elegant approach only when the pain of not doing so makes it worth it.

Is there any smell associated with having say a File.IO library being loosely coupled to the logging library? Or should they be kept separate and only combined in the application services?

Loosely coupling is beneficial in all circumstances, but you should also be aware of the additional complexity it may introduce. If you apply the Dependency Inversion principle (read Robert C. Martin's book on Agile Principles for an excellent discussion), you might consider the File.IO library to define an abstraction (e.g. an interface) that it needs for logging. You can then provide an implementation of that abstraction using your preferred logging library. To be clear, that's not the same as using the abstraction offered by the logging library in the File.IO library. Then you would still be locking them together.

I will describe a simplified example of such "dependency hell".

Imagine a video player with "play/pause" and "mute/unmute" buttons. Pausing the video should pause sound but not mute it, so that unpausing the video should unpause audio.

Then imagine we are downloading audio and video in separate files, so we have four success/error callbacks. Imagine video can play without audio but not conversely. Now imagine how many changes should be made to the code if the requirements update so that video and audio should wait for each other.

Currently I'm dealing with this using callbacks and boolean variables. I have a feeling this is stone age, because something like this:

if (videoShouldPlay && audioShouldPlay && isAudioPlaying && isVideoDownloaded && isAudioDownloaded) {

or 4 similar callbacks:

audio.onload = function () {
    if (isVideoDownloaded)
    } else { ...

is neither readable nor maintainable. The number of dependencies grows exponentially with the number of components, but I should not track every dependency when I can define some general rules .

I'm sure computer science has solved this problem already.

It looks like to me you need a state machine. Let's take for example the states "playing" and "paused". The rule for the transition "playing" ➜ "paused" would be what you write: "Pausing the video should pause sound but not mute it", etc. It's hard to tell more about it without seeing the actual problem you have at hand.

I would recommend Chapter 29 State from Agile Software Development, Principles, Patterns, and Practices and Replace State-Altering Conditionals with State from Refactoring to Patterns. I personally find the famous Design Patterns: Elements of Reusable Object-Oriented Software book somewhat difficult to read, nevertheless it is the State pattern in it.