views:

384

answers:

5

Hello fellow programmers,

As I'm a learner and user of design patterns and Delphi I would like you to ask a question which you may find subjective (Ooo just another "what's the best?").

What Design Patterns do you implement in common Delphi programming? What patterns are easier to adapt in Delphi programming? (Every language is excellent in different fields, so what patterns are likely to be very strong structures when using Delphi?)

I would be glad, if you could tell about some changes in design patterns for Delphi 2009 / 2010 (since those support generics, and RTTI in 2010).

There are many articles out there in the wild Internet, but they doesn't discuss the everyday usability and changes in patterns. (Most of them just discuss changes in language specifics, architecture)

Thank you for replies,

best regards. JB

+6  A: 

Only a minority of the Delphi developers knows that every Delphi developer uses a Factory pattern (delphi.about.com has an example in "regular" Delphi), but then implemented using virtual Create constructors.

So: time to shed some light on that :-)

Virtual constructors are to classes like virtual methods are like object instances.

The whole idea of the factory pattern is that you decouple the logic that determines what kind (in this case "class") of thing (in this case "object instance") to create from the actual creation.

It works like this using virtual Create constructors:

TComponent has a virtual Create constructor so, which can be overridden by any descending class:

type
  TComponent = class(TPersistent, ...)
    constructor Create(AOwner: TComponent); virtual;
    ...
  end;

For instance the TDirectoryListBox.Create constructor overrides it:

type
  TDirectoryListBox = class(...)
    constructor Create(AOwner: TComponent); override;
    ...
  end;

You can store a class reference (the class analogy to an object instance reference) in a variable of type 'class type'. For component classes, there is a predefined type TComponentClass in the Classes unit:

type
  TComponentClass = class of TComponent;

When you have a variable (or parameter) of type TComponentClass, you can do polymorphic construction, which is very very similar to the factory pattern:

var
  ClassToCreate: TComponentClass;

...

procedure SomeMethodInSomeUnit;
begin
  ClassToCreate := TButton;
end;

...

procedure AnotherMethodInAnotherUnit;
var
  CreatedComponent: TComponent;
begin
  CreatedComponent := ClassToCreate.Create(Application);
  ...
end;

The Delphi RTL uses this for instance here:

Result := TComponentClass(FindClass(ReadStr)).Create(nil);

and here:

// create another instance of this kind of grid
SubGrid := TCustomDBGrid(TComponentClass(Self.ClassType).Create(Self));

The first use in the Delphi RTL is how the whole creation process works of forms, datamodules, frames and components that are being read from a DFM file.

The form (datamodule/frame/...) classes actually have a (published) list of components that are on the form (datamodule/frame/...). That list includes for each component the instance name and the class reference. When reading the DFM files, the Delphi RTL then:

  1. finds about the components instance name,
  2. uses that name to find the underlying class reference,
  3. then uses the class reference to dynamically create the correct the correct object

A regular Delphi developer usually never sees that happen, but without it, the whole Delphi RAD experience would not exist.

Allen Bauer (the Chief Scientist at Embarcadero), wrote a short blog article about this topic as well. There is also a SO question about where virtual constructors are being used.

Let me know if that was enough light on the virtual Create constructor topic :-)

--jeroen

Jeroen Pluimers
shame I can upvote only once, great post, thank you
Juraj Blahunka
+2  A: 

I frequently uses the following patterns:

  1. Observer in MVC
  2. Singlton
  3. Template Method
  4. State
Edwin
There is an answer about Singletons and it says, that they are pure evil. Disguised global variables :)
Juraj Blahunka
Both are only evil if you abuse them. Singletons can be very handy in certain situations.
Smasher
+2  A: 

I use frequently following patterns:

  • Command
  • Visitor
  • Table Data Gateway
  • Observer
  • Adapter
  • Singleton (with many care!)
  • Abstract Factory
  • Factory Method
  • State
  • Dependency Injection in all of his form
  • Facade
  • Service Locator
  • Separated Interface
Daniele Teti
+2  A: 

You can find an excellent article by Marco Cantu on the equivalence of GOF patterns and Delphi idioms. I remember attending his Borcon session on the subject, it was excellent.
One main idea to remember is that design patterns are needed to supplement shortcomings of the language/framework. And if you have a native idiom, you don't need to reinvent the wheel and implement the whole GOF shebang, just learn to recognize it and name it (as Jeroen did with his superb explanation on the Factory).

François
Brilliant reference, thanks
Juraj Blahunka
+2  A: 

Non-OOP programming (some call it Structured programming) is very common with Delphi programmers. It is very simple: You create a function that does something, and it is not related to a record/object-like data structure. Example: IntToStr()

Delphi does this very well, because encapsulation is delivered using interface/implementation sections, and because the resulting machine code is extremely efficient. When compiling, it also supports optimizations for that, for instance, if you have a typed constant in your interface section, and the program is fully compiled - if you then change the value of that constant, the unit is not recompiled, only the constant changes. This is not really necessary in a daily work, but it is an example of how Delphi works.

Lars D
What does this answer have to do with any of the topics mentioned in the question?
Rob Kennedy
Non-OOP isn't necessarily "Structured programming". There's Functional Programming too, for example, very interesting topic for Delphi programmers seeking to learn something "alien". Check out http://www.delphifeeds.com/go/s/44177 for a introduction geared at Delphi devs.
mghie
-1 not at all about design patterns
Smasher
+1: "non-OOP" is a very important design pattern. It is about KISS. Even though KISS is not mentioned as such in the GOF book, the KISS pattern is one of most important patterns available: it helps you not to 'over-engineer' what you produce. Maybe it is not mentioned in the GoF book because it applies to so much more than just software.
Jeroen Pluimers
@Jeroen: KISS is not in the GoF book because it simply isn't a recognizable pattern as such. It is a good idea, yes, but a pattern is something like a handle for a common and proven solution to a class of problems. Patterns are intended to help people solve problems and communicate about it, just throwing out "KISS" does neither.
mghie
@mghie: KISS is much more of a meta pattern than a concrete pattern (the GoF book is more of a 'conrete pattern' reference). I agree with you it is very important to practice.
Jeroen Pluimers
It is possible to refactor a procedure with many parameters into a class and vice versa. It's definitely an obvious pattern that can be described and defined well, easily, but I don't care what it is called - I don't have the GoF book nearby, and seriously, it doesn't have a monopoly on naming.
Lars D
Lars, just as "non-object-oriented programming" and "keeping it simple" are not patterns, neither is refactoring. And you really *should* care about what something is called — the whole point of patterns is that they give us a **common vocabulary** to use when thinking and talking about problems. Using a name *different* from what the world's most popular pattern book uses doesn't help anyone. You have made several true statements — it *is* possible to refactor a procedure as your describe, and non-OOP *is* very common — but how are they *relevant* to the question at hand?
Rob Kennedy