Why did design patterns become a popular topic?

Miklos_Hollender

1) They are carbon copies of what the standard does and if you know the standard functionality, you know them already. Instead of writing a long essay on "released entity" they could just as well write "just like status on Sales Order".

2) They are strongly add-on focused, not customization focused (too heavy weight, does not worth the effort if you think no more than 2 users will use this feature you just built)

3) Even on an add-on level, they tend towards being heavy-weight, just like the standard is. Here is an example. For the hooks pattern, using a separate object for every hook is a huge overkill. Even in an add-on, one (or one per licencing option, licence granule) suffices.

On the plus side, if you are new to this all, they help understanding the standard better.

I am not saying it is a bad idea or anything. Making add-ons more standard and helping new people understand the standard are useful and okay goals.

I am just bothered that you are not making it clear that these are patterns for large add-ons, where it is worthwhile to invest your time because it will have a hundred users.

So you are not making it clear enough they are not "mandatory" if you are making one button that Katie from Accounting will click once a week.

Look, one issue with the whole ERP or even whole software industry is that everybody is talking about always scaling things _up_.
But in the NAV world I think we all know scaling things _down_ is also a problem, because we often have small clients, who cannot afford large projects and so on. It is often said that this - that small changes could be made lightning-quick - led to the popularity of NAV: once a guy who knows both SAP and NAV explained to me that it takes more time configure the equivalent of General Posting Setup in SAP than extending, via programming, it in NAV by a completely new kind of transaction i.e. column, and posting logic.

Our advantage is that we can be quick, if must be. You have seen customers throwing an 50 item list of small change / trouble requests at you and seen good developers chew through them in less than a week, right?

For this reason, we should not really give people the message that heavy-weight design patterns are to be used all the time, or to put it differently, we should not tell people to do every job as if it was making an add-on.

Since technically they are very similar, we need to separate add-on development and quick customizations "culturally".

I propose to consistently rename terms like Design Patterns to something like Add-On Design Patterns.

jglathe

Hi Miklos,

+1, or, well, sort of. Design patterns are a good thing, or most of them. The small change should adhere to system logic (and patterns) if apropriate. It is good practice, and makes life better in the long run. More important is that even the small changes don't break standard functionality. If you try to adhere to this, the solutions are often more complex, and tend to follow the design patterns. But they don't creep up as issues again and again when they don't break the standard.
You're right about the flexibility, though. We have lost quite a bit of this with the RTC and RDLC. To have the means for a quick hack doesn't mean that you have to use it all tge time, but it's good to have it for the moment when (not if) you need it. That's far more complicated now. And a lot of things can't be done anymore. Inside NAV, I mean.

Marije_Brummel

Hey Guys,

Thanks for starting this thread.

I also mostly agree with you.

The Design Patterns are written by a lot of people and can be divided in to categories.

Just last week I was in Denmark to discuss the project.

IMHO, the Released Entity pattern should not have been published. We should have made the blocked entity pattern more generic. This is discussed last week and will be changed.

The hooks and facade pattern are great patterns but they should be made obsolete by the development environment. We are in constand talks about this with the architects at Microsoft. I think we make great progress. Look at the merge commandlets released last year.

Making an object per function is not my idea. If this is still documented somewhere please let me know. This discussion goes back to the patterns/videos about Class/Method/Property, Natural Language Programming and Encapsulation. These patterns are general OOP concepts and in my articles and videos I try to map them to the current possibities in NAV. If I remember correctly my advice in the article is not to make a codeunit for a function if it is only a few lines of code.

Some people disagree and take it more strickt. That's an opinion. Fine.

Also in C# forums people discuss about when to make new classes, how to structure your files etc. This is going on everywhere.

Some patterns like Architectural patterns are only applicable when making new objects which you don't do very often for small customisations.

The smaller elements like Design Patterns, (don't get me started why design patterns is a sub category of design patterns) are very applicable to small changes. They document how to use Address Formatting for example.

If you make a small change somewhere, add an action or change one line of code, the new mergetool will pick it up and bring it forward without any problem.

I guess it all comes down to think about what you do and apply common sense.

It is good that the "Navision Way" of doing things is documented and you can point someone that is new to NAV to some point of documentation.

After four years working with the Design Patterns we are at a point where we are maturing and need to do housekeeping. If you have any suggestions on cleaning up, combining, new patterns, categories, don't hesitate to reply.

I am also more than willing to setup an online meeting to discuss this with the hardcore mibuso community.

Thanks again.