Least favorite design model

Well, I'm not looking for anti-patterns - I'm looking for things that aren't really patterns or maybe patterns that have been abused.

My personal least favorite is the Helper template.

eg. I need to create a SQL query, so call SQLQueryHelper. This is necessary to process some strings, so it, in turn, calls StringHelper. Etc. etc.

Look, this is not a design template at all ...

[edit] Do you people who vote for this think you should add a constructive comment?

+4
source share
6 answers

Singleton

This is a global variable, hidden and difficult to fake / stub for unit testing.

A service locator is better, dependency injection / control inversion is even better.

Most of the links to the wikipedia article explain why this is evil.

+25
source

"Dispatcher". eg.

DataManager BusinessLogicManager WidgetManager 

What does manager mean? More specific! If your WidgetManager has so many Widget responsibilities that there is no more specific name, then break it.

This is a conversation that I had too many times when I looked at the old code.

+11
source

I think that design patterns should not be used blindly, implementing them simply because it is cool: they have a well-defined CONTEXT and using them when possible can help, but in any other case they are just a waste of time when not prevents the proper functioning of the system.

+5
source

My least favorite is "put" Helper or "Manager" at the end of the class name template.

EDIT: And I proved that I am a lame programmer, as Chris remarked, forgetting "Util".

+4
source

Strategy

The reason is because I suspect that most people are taught to implement it using the class and method.

Consider the following Haskell code:

 ascending = sortBy compare somelist descending = sortBy (flip compare) somelist pairsBySecondComponent = sortBy (comparing snd) somelist 

What is the strategy template in action: compare , (flip compare) and (comparing snd) are specific strategies in this case (they are simple old functions), and the function signature a -> a -> Ordering is the "interface" of the strategy.

The brevity of this illustrates that design patterns do not have to be so heavy or bulky. The way you want to implement the Strategy in Java (interface, classes) is not a good way. This is a way that works around Java, giving you the wrong abstractions for the work you need to do. This should not be considered normal or acceptable.

For this reason, believing that my assumption about how he teaches is correct, I really dislike the strategy template.

There are some other patterns that are also specific instances of the generic "Function Pointer" pattern. I don’t like them either, for the same reasons.

+2
source

MVP This is MVC, but broken.

Oh no, but wait, application development is completely different from best practices such as "It's just a presentation."

Update

I refer to “It's Just a Look,” which is from the book “Pragmatic Programmer”. My main problem is that almost every MVP implementation has a view leading to the lead, and tells the lead to do something. This is conceptually the opposite. The user interface should not be logic dependent. This is just a look. Logic is the main cause of the application, how this logic is displayed is a secondary problem. I could use one winform, or I could use a lot. Hell, I could put it all in ASCII text or create a “performance” by sending the charges to a wire attached to an artist who displays the performance through a mediocre dance.

In practice, this assumption does have some viable uses. Some of the controllers that I wrote in the past have MANY views, which are displayed mainly and can be entered into the user interface, as the application deems necessary. Consider a live data feed. I could imagine this as statistics, as line graphs, as pie charts. Perhaps all at the same time! Then the view holding the controller looks stupid, the parent is the controller, and the children are the views.

Traditional (the form holds the presenter). Implementing MVP has other implications. One of them is that your user interface now has a dependency on code that executes logic, which means that it will also require links to everything that needs to be logical (services, etc.).

The fix is ​​to pass in the interface (again, most of the MVP implementations I see have a form that creates a lead, but hey). Then it becomes a workable model, although I have never been a fan of passing args to the form constructor.

At the end of the day, it seems like people are spinning around trying to justify the shattered model. I personally believe that the MVP pattern exists solely as an attempt to streamline the work of Visual Studio Windows Forms applications. They start with the "Form First" mentality.

"Oh hi, here is your form, now go and drag your controls and logic into the interface"

Anyone who has experience working with any applications that are outside of use understands that this way of working does not scale. I see MVP as a way to make this scale, but it just looks like the support of the architectural team around the broken “form of the first” development model that the IDE promotes.

I affirm that MVC is just MVC, MVP is a template bastard. Infact all MVC definitions are incorrect. An important part of this is the separation of concerns. The user interface, logic, data and / or services that you consume. Keep them separate. You do not implement MVC for this, you do this, and by doing this, you get the MVC form. MVP does not fit into this because you do not fall into MVP if you start by thinking about sharing the problems you have in MVP if you are stuck on the ground “Form First” and you feel like you have to do something a bit more MVCish.

That I will take it anyway.

+1
source

Source: https://habr.com/ru/post/1277217/


All Articles