Pattern Based Design
Idan Arye via Digitalmars-d
digitalmars-d at puremagic.com
Tue Nov 17 15:41:20 PST 2015
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
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.
More information about the Digitalmars-d