Pattern Based Design

[Idan Arye via Digitalmars-d]

On Tuesday, 17 November 2015 at 19:05:30 UTC, Jonny wrote:
> Being able to factor a project into well understood patterns 
> that are loosely bound yet cohesive is fundamental for a 
> successful project.
>
> Does D have an ability to template patterns(or even better yet, 
> a uml like interface that can emit D code) effectively? i.e., 
> saves much more time than doing it by hand?
>
> As I become more knowledgeable about the fundamental 
> programming concepts I realize that modern programming hasn't 
> yet brought design to the forefront of programming, where it 
> naturally should be.
>
> UML is a start, obviously and there are many reincarnations and 
> variations on the theme. But I imagine that a fully integrated 
> design interface is the way to go.
>
> Something that allows you to work in design mode when you are 
> designing and work in implementation mode when you are 
> implementing... keeping the two distinct is what prevents the 
> chaos that tends to happen as a project grows.
>
> Proper design is the key to success, is it not? If so, then 
> wouldn't it be wise for D to be more than just a "compiler"?
>
> Code folding is a cheesy attempt to reduce implementation 
> details. Code should be more than just a text file of the 
> implementation, but should also include details the design of 
> the program(what it should do, the patterns involved, how the 
> patterns are fitting together, etc).
>
> About the closest I have seen to the concept I am interested in 
> is the UML applications like Visual Paradigm which attempt to 
> make design the utmost importance. Because these apps are not 
> integrated with the compiler, the compiler cannot take 
> advantage of design details for optimization. Neither can it 
> properly refactor the implementation details when the design 
> changes.

Code generation from UML is bullshit. The point of design is to 
work at a higher levels of abstraction than your code - levels 
behind what can be automatically compiled to executable code. By 
working at such high levels, you can skip many implementation 
details that can be filled later by the human programmers, which 
allows you to easily apply design changes(before you write the 
actual code) and which provides you with better overview of the 
whole project or specific modules, functionalities and flows.

If you want to generate actual code from the design, you must 
limit the abstraction level of the design to one that can be 
automatically compiled to executable code - a limitation that 
robs you of the benefits mentioned above and essentially makes 
the format of your design a graphic programming languages. Such 
languages have been created before, and never got traction - and 
for a good reason! Over the years, programmers have developed a 
large array of tools for working with textual line-oriented 
source code files - SCMs, sophisticated text editors, search 
tools, text manipulation tools and more. Many language-agnostic 
tools that can work on any source files provided that they are 
composed of textual lines of code. Graphical languages don't 
satisfy that condition - so you can't use these tools with them.