1

Do experienced developers and software architects see entire application in terms of design patterns? In other words experienced developers and software architects able to describe an entire software application in terms of design patterns? By experienced, I mean developers with 10+ years experience. Is that something I should strive to achieve. I am talking about developers working on object oriented languages like C#, Java and C++ but would like to hear from Javascript developers/architects as well.

4
  • 4
  • Nope, patterns are not components you build an application from.
    – JacquesB
    Jul 26 at 20:34
  • This entirely depends on your definition of "design patterns". If you mean "design patterns" in the restricted sense like "GoF design patterns", the answer is clearly "no", but sometimes askers on this site use the term "pattern" synonymously for "approach", and then the answer is not that crystal clear. Voting to close as "opinionated" until the question is edited to give a better description of what is meant, with some clarifying examples.
    – Doc Brown
    Jul 27 at 5:39
  • There is nothing to say that creating entire applications with design patterns is wrong. If you see the solution in terms of design patterns then that's fine, what's the worst that could happen? Jul 27 at 19:48
9

A common misconception among developers is that you can describe an application, or build an application, entirely by bolting together design patterns. Writing software is not a matter of choosing design patterns, arranging them properly, and then shipping a product. Software development has not become quite that modularized. If developers cannot build software entirely composed of design patterns, then software architects cannot have conceptual discussions about software entirely composed of design patterns.

A design pattern is a specific problem coupled with a general description of how to solve that problem. It is a tool for communication, primarily, so I can see how someone might think architects can speak in terms of design patterns. They do speak in terms of design patterns, but there is not a design pattern to solve every problem. Instead, architects will speak and think in terms of the bigger picture elements of software design. Design patterns are certainly part of an architect's vocabulary, but it extends far beyond that. Design patterns, architectural patterns (onion architecture, clean architecture, micro services architecture), design philosophies (domain-driven design) and design techniques (separation of concerns, interface segregation principle, polymorphism, encapsulation, data hiding, etc) can be the main tools of communication.

So, no. Architects cannot describe an application entirely using design patterns. They need architectural patterns, design philosophies and techniques as well.

1
  • 2
    You might add to your last paragraph that even then there can be still parts that are specific enough that they cannot be captured with generic language/tools. Jul 25 at 6:06
0

That will very much depend on the size of the application and at what abstraction level the architect is working.

If the application is a trivial application (like a school assignment) solving a well known problem with a well know pattern, most probably its architect will know the design pattern and be able to describe it like that. In larger systems, this becomes a lot harder: many patterns overlap, every solution has some specific requirement breaking some patterns, platform limitations force out deviations, etc... On this size it becomes a lot harder to explain the whole architecture with design patterns, but might still be possible to some degree.

In large-scale software systems with millions of lines of code (or in some case hundreds of millions) completely new patterns start to emerge. Understanding, or even just describing what happens on that scale can still get you a PhD degree. At this size if the architect is responsible for some sub-system leading a team, they could describe their own part related to design patterns, but most likely will have no or limited overview of the entire system. If the architect is working on the "top of the system" coordinating other architects, sub-systems, maybe negotiating with business partners, etc... they might give you a description on the overall system, but they will not really be able to give detailed information on how each part works.

Please note, that after a size and complexity it is no longer an architects fault if they can not "understand"/"describe" the whole system in detail. Size and complexity can grow beyond anyone's capabilities (or at least with the tools we currently have).

Some personal observations on large-scale software systems:

This site is temporarily in read only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .