Hacker News Reader

> I did not start with OO, I never read the GoF book, and don't really get the obsession with design patterns and everything surrounding them. I've surprised a lot of others who likely have, by showing them how simple the solutions to some problems can be. Perhaps it's the education of programmers that is to blame for this.

Design patterns are mostly crutches for languages that have pretty weak expressive power. In a powerful language, you don't need most of them.

See also: http://norvig.com/design-patterns/design-patterns.pdf, slides 9 and 10.

Or rather, they can become either invisible or first class citizens that you can assign to a variable and pass around.

No, they disappear completely. You stop thinking in terms of "factories" or "strategies" and start to think in terms of simply passing methods around, etc.

I still think "oh, a generator function" when I program in clojure. I'm just not excited every time I got to use it. That's all the difference IMHO.

Also - there are such "nonexciting patterns" in OOP languages as well, and they are much less often abused. For example "a switch inside a while" pattern. Which I think I will need to name "StateMachinePattern" to make it cool and stop people refactoring it into strategies and stuff.

There is value in one-screen definition of the whole machine, instead of separating it into 6 files.

Agreed.

I never really saw design patterns as a reference manual for how to solve problems (as I think some people do/did). Instead, I saw it as a shared vocabulary.

For example, if I say that X is a factory for Y or an iterator over Z, you know exactly what I mean.

We still have monads and functors in Haskell. People in other languages have eg picked up the `monad' pattern. (Look for eg `flatMap' to spot it; that's monadic bind.)

In Haskell even the compiler knows that there are common elements to all instances of the monad pattern---they can reference a common typeclass. (But even if you don't implement an instance of the typeclass, you might still have implemented the monad pattern, but just don't realize it.) In eg JavaScript it's all by convention only.

But even in Haskell, the compiler does not enforce all monad laws, yet.

A more common example, but perhaps invisible today, is the `function' pattern. In most assembly languages, functions are a convention only, and you have to manipulate your call stack somewhat manually.

In almost all languages anyone is using these days, that's done automatically. Functions are not `invisible' but they are citizens with more right, ie the compiler / interpreter knows about them, you can give them a name, and in some more modern languages even pass them around, or _not_ give them a name.

Some patterns do become invisible as you say.

`Factories' are one that only exists because of weird restrictions in eg Java. They are invisible in Python.

In Haskell for different reasons we have a similar solution where we define extra functions to return our create our objects instead of using constructors directly. Instead of factories, people call these smart constructors (https://wiki.haskell.org/Smart_constructors).

Smart constructors in Haskell could go away with a stronger type system like in Agda. (Yes, there are languages with stronger types than what Haskell has.)

That presentation makes a funny assumption that it's dynamic languages that do that. Haskell is nearly as far from dynamic as possible, with all the same advantages w.r.t. patterns.

The presentation is about dynamic languages, but the observation about design patterns being crutches for offsetting language deficiencies is in fact a general one.

Haskell needs "zip3" when there are three arguments to zip.

That's a design pattern for optional arguments straight out of ISO C.

I think it would be possible to create a generalised `zipN` function, using the Haskell printf trick[0], but it would be a lot of complication for little benefit. It's rare that you need to merge that many streams at once, and adding a single digit is not a huge hassle in those cases. Also I'd probably consider splitting the operation up into stages if I was using anything higher than `zipWith3`.

[0]http://stackoverflow.com/questions/7828072/how-does-haskell-...

You also have an equivalent on a family of isomorphic types, namely the types

    forall z. (a -> b -> c -> ... -> z) -> ZipList z

This is gotten by taking your `list_a :: [a]` etc. and writing:

    \f -> f <$> ZipList list_a <*> ZipList list_b <*> ZipList list_c <*> ...

You can of course also use Haskell pair-stacks to do all of this, storing (a, b, c, ...) as the type (a, (b, (c, ... ())))...

I've done some examples of transposing Java code explaining various design patterns from the GoF book to Haskell, then seeing how it gets simpler when you have a couple of higher-level ideas from Haskell to work with. It could make a fun talk to present at a Java-centric conference, "today I'm going to teach you some Haskell." As a bonus, you get to see how the Java code deals with a tremendous amount of needless complexity.

For example, here's what I've written so far for the Visitor pattern:

https://gist.github.com/drostie/818c54ca5c8182143699a72da986...

It's true, as Norvig points out, that newer languages are making old design patterns disappear (slide 10), but new ones are appearing at the same time, and he mentions that too. The simple design patterns like iterators die when iterators become intrinsic, but now we get higher level patterns built out of the small patterns now in the background.

I wonder if it's more about how much code you have to write. Patterns are patterns because you have to write some code to make them, i.e., they're not already there in the language, and as soon as you have a generalized class that actually solves a structural problem, you have a pattern.

I suspect that powerful and expressive languages won't make patterns go away, we'll just get powerful and expressive patterns.

Lisp macros give you the ability to abstract away patterns ad infinitum. There's no hard ceiling there. So you can make patterns go away with enough expressive power.

Can you give us a couple of examples of how lisp macros "abstract away" patterns?

Take the example from [0]:

> Also - there are such "nonexciting patterns" in OOP languages as well, and they are much less often abused. For example "a switch inside a while" pattern. Which I think I will need to name "StateMachinePattern" to make it cool and stop people refactoring it into strategies and stuff.

> There is value in one-screen definition of the whole machine, instead of separating it into 6 files.

In Lisp you could create a macro, say, define-state-machine, and use it like that:

  (define-state-machine :my-state-machine
    ((:state-1
      (do-something)
      (do-something-else)
      (if (condition)
          (transition :state-2)
        (transition :state-3)))
  
     (:state-2
      (do-something)
      (transition :state-3))
  
     (:state-3
      (do-something)
      (when (should-quit)
        (quit-state-machine)))))

This macro could easily expand to a "switch inside a while" (or, possibly, to a "let over lambda over cond", or maybe even into a series of low-level tagbody and go constructs). The resulting abstraction is clean and communicates its meaning well.

--

Different example - when writing macros in Common Lisp, there are two things one usually has to be wary of - unwanted variable capture, and unwanted re-evaluation. So you might end up manually assigning gensyms[1] to avoid variable capture, and manually creating lexical environments to evaluate passed forms only once. But you can also abstract it away! For instance, with with-gensyms and once-only macros from Alexandria[2]. Or you could build something like defmacro! described in Let Over Lambda[3], i.e. a macro that automatically code-walks your macro definition and extracts variables named g!foo and o!bar to apply gensyms and once-only to them, respectively.

--

Those are only two examples, but the general idea is - whenever you see yourself repeating the same boilerplate in similar places to express a concept, you can wrap that boilerplate inside a macro and make the compiler generate it for you. Since Lisp makes all of its capabilities available for you during macroexpansion, you can continue this until you're satisfied that your code is readable, boilerplate-free and clearly expresses your intentions.

--

[0] - https://news.ycombinator.com/item?id=11730248

[1] - gensyms are symbols generated on demand, that are guaranteed to have no possible collision with anything ever

[2] - https://common-lisp.net/project/alexandria/draft/alexandria....

[3] - http://letoverlambda.com/index.cl/guest/chap3.html#sec_6

I use this sort of thing in Tcl ( for path-dependent reasons ) A Whole Lot. You can have arrays, indexed by state, and use the "eval" operator to "eval $fsm($state)"

fsm is an array of strings, indexed by whatever.

I have made dynamic state machine generators this way, although it gets kinda disorienting.

The tactical advantage to Tcl (for me) is that it has serial ports and sockets as first-class objects with essentially identical semantics. I work in the embedded space, and this seems 1) unusual and 2) a very nice thing to have to write comprehensive test rigs.

I rather like it better because it's all in the "string" & "list" domain rather than the lambda domain. I really should try this in Lisp just to see how wierd it gets.

Eh, lisp macros are nothing more than a way to avoid quoting your symbols. Functions are more clear, and do not try to hide what is going on. Honestly wish it was like this: (defun 'my-adder '(x y) (+ x y)) ;; emacs lisp.

I'm a lisper and clojure user. Those are my main languages. Don't get the hype for macros, but lisp is the best.

The main difference is that unless you are using an interpreter, you can apply macros at compile-time. Also, without macro you build forms which you must then evaluate: eval cannot access the lexical environment. You need to systematically pass an environment, either at runtime in an interpreter or at compile-time: more boilerplate.

To summarize, meta-programming is a recurrent pattern that was abstracted with macros. The defmacro macro itself produces functions like you want to use, except that it integrate them with the macroexpansion facility offered by the environment.

I'm happy to be part of a community, where even when I spew out something ignorant there is a clear explanation that makes sense. Thanks for your answer.

I think this perfectly shows that design patterns are just that patterns. They're not goals but they aren't really tools either. They're just what you see when you compare different code bases because similar problems will provoke similar solutions even from different people.

Design patterns only become problems when people learn about them and try to apply them without learning or understanding how they came to be.

Or, apply them even though they likely will never need them...

One pattern implementation that I always hated, and still do was MS Enterprise Library's Data abstraction. I worked on one project that targeted three different databases for Enterprise customers, which was a great fit. That's the only time I worked with EntLib where using it was better than just using other tooling for the specific database directly.

In the end, sometimes people get used to a given framework, and don't stop to think if they really need that framework for what they're working on. It's one of the things I really like about the node ecosystem, though sometimes that goes too far the other way. That said, I tend to rail against certain patterns as they don't have much place in a given language/platform.

It tends to be something that comes with age/experience. But not always, I've known plenty of older devs stuck in framework/pattern rutt.

Unfortunately, power was too much for his readers, so he dumbed down his work into Python.

Like C#? It may be just the opposite: What if design patterns are popular with complicated, highly expressive toolchains because they make users think they have control of, and are being productive with those toolchains?

You don't hear design patterns mentioned a lot with simple toolchains like that supporting golang.

No, unlike C#. Design patterns are pieces of boilerplate code you should, but are unable to, abstract away. Which means that by definition the language lacks the expressive power to abstract them away.

Yup. Visitor is a dirty hack for pattern matching, for example.

Design patterns are fundamental, you cannot avoid using them, the key is to understand this, learn about good design patterns versus bad design patterns (or "anti-patterns") and use them appropriately. The book "Design Patterns" by the GoF does include many patterns which are specifically targeted to working around the shortcomings of "weak" languages, specifically Java. However, that book is not the end-all-be-all of design patterns, and using different, more straightforward "idioms" in more expressive (typically more "functional" languages) doesn't mean you're avoiding using design patterns, you're just using different ones.

Unfortunately, a lot of people make the mistake of seeing the GoF list of design patterns as being the holy scripture of patterns, when it's merely an enumeration of some patterns that proved useful for a particular language in particular contexts. The concept itself (of looking at design at a level above mere algorithms and data structures) is hugely important, it's unfortunate that it suffers from a bit of the "kleenex" effect, instead of being seen as a general purpose concept with wide ranging applicability.

Totally agree.

Functions are a design pattern in assembler, but a language feature checked by the compiler in more advanced languages.

Classes are design pattern in C (called ADTs), but a language feature in all OOP languages.

Generalizing the concept: A design pattern is something the programmer has to check himself/herself for correctness, instead of being automatically checked by the compiler or interpreter.

> the majority of developers, who for some reason appear to love immense complexity and solving simple problems with complex solutions.

It took me a while to break out of what I learned in school about how to write software. My single most important takeaway has been to not seek generalization and abstraction of the problem I'm working on, but solve it as directly as possible, and only generalize or abstract my code after I've completely finished solving the same problem at least twice. In my experience, the single biggest software time waster I've witnessed (and participated in) is people solving problems they don't have.

In school are students not always taught to solve using the naivest implementation possible, and then improve?

My classmates and I were taught to use the most naive code possible, and then improve it immediately using patterns that abstract and generalize the problem being solved. We were taught to look for improvements that solve problems of safety and scale, we were taught to look for ways to use existing design patterns.

Those are important basic software skills to learn, but in my schooling they were never offset by a philosophy that dealt with how and when to use them, and more importantly, when not to use them.

I've personally seen in my ~20 year professional software career so far a lot of software engineering that is overly expensive by a long way because people decide to add unwarranted complexity.

The first time I was told, "Make it work, make it right, make it fast," was in my first programming course. However, it was in passing by another professor substituting. After the first programming course, we had OOP Design. It's how to better structure OOP software, abstractions and design patterns. This was our, "This is how good programmers do it."

That same professor who had subbed then beat it into our heads - in our senior level programming languages course - that making the damn thing work takes priority over all. I guess better late than never.

I agree 100%. I think you have to experience the problems of having to deal with a system that was over-engineered from the very start using all kinds of unneeded abstractions. Once you ran into that, you hopefully appreciate simpler solutions that most of the time tend to be far more adaptable to changes than your OO-monster you accidentally built.

I once had the joy of witnessing a program I wrote being rewritten. Before the rewrite it was ~400 lines of Python written in the most obvious way possible without any abstraction overhead. You could easily scan the complete code and understand what happens. The rewrite was totally over-engineered, split up into a dozen files, organized into some inheritance hierarchy. Even the database access was abstracted out, so it could potentially use another DB at some point. It didn't improve anything at all but bloated the code by at least a factor of 2. But it was more "correct" according to some metric...

> Even the database access was abstracted out, so it could potentially use another DB at some point.

Did they use a library?

I tend to unconsciously follow the rule "write for the problem at hand, aggressively abstract as soon as you have to solve a variation of that problem."

Sometimes that means I'm writing a function, and I find I've written a few lines to summarize and output info about a data structure the same way a few times in that function for debugging purposes. I'll pull that out into a function.

Sometimes that means I have a fairly complex processing function for a data source, and a few months later I need to process a new data source of similar, but not the same, info. I'll try to (somewhat) normalize the data sources to a format that can be processed or almost be processed by that function, and make the changes to the function so it can work on the mostly normalized data, and handle the specific differences as needed.

It's almost never a good idea to make your algorithm very abstract in the beginning, as it generally makes it more error prone, and usually you don't know the specifics about how things need to work anyway. By the time you're feeling the need to abstract the function, not only do you know more about the problem and can implement it cleaner, but you can use the prior implementation as a test harness to confirm the rewritten version is functionally the same (or better). I can't stress how useful that is and how much time and pain it can save.

Ok but under-engineering can also be a problem.

Say you and your team are going to build a REST server that will serve hundreds of endpoints.

Nothing complicated, just a bunch of CRUD code with some business logic.

So here is the simple way to write each endpoint function, or method.

  RESTResponse getUserPrefs(Userid id)
  {
     return DB.getUser(id).prefs;
  }

except you need security and code to setup and teardown DB the transaction.

  RESTResponse getUserPrefs(Userid id)
  {
     if( !Security.checkAllowed(id) )
       return REST.403;

      RESTResult result;

     DB.getConnection();
     DB.beginTransaction(true /*Readonly*/);

     RESTResult result = DB.getUser(id).prefs;

     DB.endTransaction();
     DB.closeConnection();

     return result;
  }

Now imagine giving this example to a team of devs to develop those hundreds of bitty REST endpoints.

Also as you can imagine, the boilerplate introduced here may have to change per endpoint. There might also be other boilerplate that may need to be added for object level security, authentication, error logging etc ...

So when you throw this code at your developers, it means that you'll end up with hundreds or thousands of little methods all similar but all different.

They are going to cut and paste this example and modify as they go. They may come up with better ways to structure the boilerplate, leading to some old code mixed in with code written in a newer style.

Good luck working with that after a few years.

All these encomia for simple code usually considers only a single small program, with one person working on it.

Once code is loosed in the wild for a team of maintenance programmers to work on, you have a whole new problem, and lack of structure form the simple approach will cause weeds and vines to choke your codebase.

Generally, it's much easier to add complexity than remove it once it has been added.

> So when you throw this code at your developers, it means that you'll end up with hundreds or thousands of little methods all similar but all different.

If that's what happens with your developers, you need new developers or new management, clearly the ones you've hired are either incompetent or their management is forcing them to suck.

> If that's what happens with your developers, you need new developers or new management

I don't think so, it's just human nature and other pressures besides the purely technical ones: like the pressure to just get a task done, or to get the job done as easily as possible, and so on...[1]

As programmers we tend to think the the biggest challenges are technical, but they aren't: the social problems are a way bigger factor.

Also the problem I'm describing here applies to large low-complexity codebases, to be worked on by large teams.

These are common in 'enterprise' settings, which is why I think design patterns have so much appeal there.

[1] https://en.wikipedia.org/wiki/Tragedy_of_the_commons

I couldn't resist making a Common Lisp version.

DB, REST and SECURITY are imaginary packages. CLSQL is an existing library for interfacing with databases. You define the meat of your code with a primary method:

     (defmethod get-user-preferences (id)
       (user-preferences
        (db:get-user id)))

Then, you add security checks with an AROUND qualifier; CALL-NEXT-METHOD is a little like super() in Java, but with multiple-inheritance and method qualifiers (around, before, after, ...):

     (defmethod get-user-preferences :around ((id integer))
       (if (security:allowedp id)
           (call-next-method)
           rest:+FORBIDDEN+))

You can add logging, executed before the primary method, after security checks.

    (defmethod get-user-preferences :before (id)
      (log "Getting user preferences for id ~S." id))

Likewise, you could log the outcome of the security check;

    (defmethod security:allowedp :around (id)
      (let ((result (call-next-method)))
        (log "Access ~:[denied~;granted~] for id ~S." result id)
        result)))

Also, you can wrap the call to db:get-user with the appropriate dynamic context where a database connection is open (it could be from a pool, or something else) within a transaction.

     (defmethod db:get-user :around ((id integer))
       (clsql:with-database (db *database*)
         (clsql:with-transaction (:database db)
           (call-next-method))))

I did not find an equivalent for the read-only flag.

If more methods need to follow this pattern, it might be preferable to define them directly with a macro which always open the connection and the transaction. The WITH-X macro ensure that transactions and connections are properly handled when unwinding the stack.

AOP huh? Nice.

The scenario i described above was from a real project I was on a few years ago.

The way I handled it (partially) was via the use of AOP. I also made use of dependency injection.

These two approaches combined managed to reduce the boilerplate to near zero.

Of course, in Java AOP means you have to take care to enable it in each part of the toolchain (build system, CDP, IDE ...) but it wasn't too bad.

I'm not sure which gang of 4 patterns I may have been using, and I don't care, but I do know that leaving it simple would have led to chaos, because I'd seen it happen before.

I'm always curious about whether or not people are lumping in lower-level "coding best-practice" concepts like DRY in with this idea of "complexity."

It's fine to complain about people who "over-engineer" things, but I've also come across cases where someone uses "I'm Agile" as an excuse to completely throw out any and all coding structure or best practices.

And every time I try to say that maybe we should spend 3 seconds to remove the comments that are in Chinese and maybe adapt the code to our naming conventions after literally copy&pasting it in from StackOverflow, I get pointed to arguments like this post for why none of that stuff matters.

No one is against coding structure, or even "best practices", if you interpret it as meaning the thing someone fluent in English but with no background in software development would understand it to mean. The problem is that "best practices" in our industry has become a specific term meaning "overly complicated by a factor of about seven, but with enough meaningless jargon invented to describe it that no one feels comfortable saying the emperor is in fact naked".

I totally agree with you, I just think that the ideas being discussed in this thread have a ton of nuance and they can be dangerous to introduce to a junior developer who doesn't quite realize the difference between the idea of "complexity" we're talking about here and the fact that he shouldn't be copy-pasting boilerplate code all over the app and copy-pasting directly from StackOverflow without any editing or integration of the code.

I would agree with that definition has become the new interpretation of "best practices". However, in my 5 year career I have seen the majority of solutions under-engineered. That is much more of an issue these days than over-engineering.

>majority of solutions under-engineered. That is much more of an issue these days than over-engineering.

Couldn't agree more.

The problem isn't "best practice" per se, it's "best practice" in practice. :)

I can see good use cases for OOP, for instance, but OOP's definitely a leading contender for the "over-engineering" trap. I've certainly seen my share of "OOP / pattern spaghetti" to the point where just coding a simple select call involves writing several classes in random locations in the project. Like goto spaghetti, the result is way harder to debug and maintain.

I personally think lower level advice like DRY is much more important overall than patterns (in many OOP projects, it seems, I feel like they violate the KISS principle for no real benefit).

Even naming conventions can fall in this trap. Consistent naming convention is absolutely a great idea. And then you run into the database that have several naming conventions, all inconsistently applied depending on the state of the project at the time. I've found inconsistent naming conventions not much more useful than no naming convention at all.

>I've found inconsistent naming conventions not much more useful than no naming convention at all.

Try working with someone who's idea of expanding the app is literally taking a controller class for another page that does something vaguely related to the new feature, copy-pasting it into a new file, changing the class name (like put an "N" at the end of it like "SearchResultsView"-->"SearchResultsViewN"), and then changing some of the internal business logic without changing the names of any methods or variables.

What you're left with is something that is much, much worse than no naming conventions at all. It's actually naming conventions that actively mislead you as to their scope and function. Like a "clickedEditButton()" method that is actually wired up to a "back" button on the page and takes you back to the previous screen.

I sometimes describe it as “framework envy”. I've worked with a fair number of developers who learned library design by looking at the standard library or popular frameworks and thought it was a model for everything, unaware that in many cases those were either poor examples (e.g. AWT / Swing) or complicated by offering a general solution usable for a wide range of projects and thus overkill for an internal app which would never be used elsewhere, especially when the core structure was still being determined.

It's something to grow out of. I had that "framework envy" towards game engines in my early years, and was designing overcomplicated architectures for a while.

I think this hits the nail on the head. I would say that more generally, a not insignificant number of OO design concepts were developed in an environment of coding modules meant to be used by other people (either in the form of frameworks, or multi million line monoliths).

For a large number of developers, neither of these environments apply, but they are still abiding by the same rules.

Yeah, it's like reading about some cool thing Google or Facebook is doing and then recognizing that your problem is much easier because the data fits in RAM

> I did not start with OO, I never read the GoF book, and don't really get the obsession with design patterns and everything surrounding them.

Unrelated to your original point, you should consider reading the book. Pay special attention to the section introducing the motivation for each pattern and the problem it solves. Over-engineering programs to deliberately include patterns is to be avoided; but there is no harm is knowing the patterns and when they apply by reading the original material.

Often is about developers trying to make their systems flexible.

In software. You can make any part of a system flexible. You can make several parts of a system flexible. But the more flexibility you add the less maintainable the code becomes, and there for the least flexible overall.

So you really have to choose where do you want that flexibility. Often is better to keep your design simple and clean; and add the flexibility when you actually need it.

Yes. The most general problem cannot be solved. So only generalize where you need to.

> the majority of developers, who for some reason appear to love immense complexity and solving simple problems with complex solutions.

This is so true. Of all the projects which I have seen that failed, not a single one failed because its design was too simple. In fact, almost all of them failed because they were over engineered and because of that it was too hard to quickly adjust to changing requirements. And still people keep making the same mistake over and over again.

It's not just related to design patterns, it's everywhere in the IT world. Take for instance protocols. SMTP: before the 80's there was a whole bunch of mail transfer protocols, many of them quite sophisticated. But which one won? The Simple mail transfer protocol. Or HTML, which was derived from SGML, a more complicated and much more generic protocol. The simple protocol won again. Or XML (derived from the more generic SGML), which is now being replaced by the even more simple JSON. The list goes on.

> I did not start with OO, I never read the GoF book, and don't really get the obsession with design patterns and everything surrounding them.

I did some OO, but like functional programming better. In Haskell, there's a certain draw to doing everything in the type systems. Or a quest to find the single abstraction that unifies all your code into a coherent whole.

(For a configuration language pretty printer that I worked on at Google, I recently managed to throw out a couple hundred lines of code, by finding a unifying abstraction for most of the recursive functions on the abstract syntax tree we were doing.)

> so they think "awesome, something new and shiny to use in my code!" and start putting them in whenever they can

Yeah. You do not truly know hell until you're trying to maintain a basic CRUD app used as a tool for someone to learn domain-driven design, CQRS, and event sourcing simultaneously.

Does anyone know how the Design Patterns authors became known as the "Gang of Four"?

I'm guessing it originated from an unflattering comparison, although my knowledge of the Cultural Revolution is pretty weak, maybe it was a compliment.

Not sure, but 4 co-authors is a likely partial reason. Also I guess partly due to imitating various precedents, and not just in tech. E.g. The Three (Musketeers, ...), The (..., ...) Duo, The Famous Five (kids novel series), etc.

A separate HN thread on that might be a fun read :) A similar one is eponymous Laws (Wikipedia has a list).

See here - http://c2.com/cgi/wiki?GangOfFour

Yeah, I don't feel any enlightenment kicking in. I'm aware that the Gang of Four name originated with a cabal of power at the centre of Maoist China, but I'm curious who drew the connection and why.

Well, going by further events related to the use of design patterns (as discussed in the article and, e.g. userbinator's comment (which was at the top of this thread), maybe the connection is "comply, or you will be assimilated" ...

You must use the fancy words- its not just a pointer to common constant struct- its the flyweight pattern. If you just use the pointers and not the words you are not a professional.