Are design patterns frowned upon

design-patternsindustry-standard

I had a discussion with one of our senior developers who's been in the business for 20 years. He's pretty well known in Ontario for a blog he writes.

The strange thing is what he told me: he said that there is a piece of code that is a nightmare to work with because it was written from a textbook, and doesn't account for the real world. Adding a new field to the UI/database/Data layer takes 2-3 hours to do, whereas in his code it takes 30 minutes.

The other thing too is that he avoids design patterns because most programmers don't understand them and they are not good from a maintenance perspective.

Then there's also the idea that most web developers in Canada prefer to have their data model inherit from the Data Layer classes, rather than keeping it isolated. I asked him, "Isn't it industry standard for the model to be separated from the data layer?" He said sometimes, but most people here prefer not to do that because it's too much work.

It sounds like his reasoning for not coding using best practices is because it's a maintenance nightmare, few of our employees understand it (besides myself), and it's slow to work with if you need to push out new features or fields in a few days' time.

It's so strange hearing an opinion like this, considering that Stack Overflow mostly encourages people to follow industry standards. Is the problem that we are constantly forced to churn out new fields and features in a matter of days, that it's not possible to deduce a solid pattern that is flexible enough? That seems to be the gist of what I understand from this.

What do you make of these statements?

Best Answer

These are the words of someone who has found success and ignores people that try to tell him what to do in pattern jargon that he doesn't understand.

Design patterns and best practices are not the same thing. Some people think they are and drive people who know what they're doing nuts. Even if they don't know the proper name for what they are doing.

Design patterns existed before they had names. We gave them names to make talking about them easier. A pattern having a name doesn't make it a good thing. It makes it a recognizable thing.

This guy is likely using patterns neither one of you ever heard of. That's fine, until you need to talk to him about how something is done. He's either going to have to learn how to talk to you or you're going to have to learn how to talk to him. Has nothing to do with who is "right."

Related Solutions

Data Serialization – Processing Business Logic Efficiently

A lot depends on your intention. Data serialization in this manner just to pass on to the business logic of a single application, seems wasteful, when you should be passing a native object from the ORM to the object encapsulating BL which will modify state and return the object to the ORM for persistence.

On the other hand, if you have multiple, distributed applications that handle different aspects of of the domain, then wrapping your DB in an API to provide serialized (JSON or XML) data is a good idea.

For instance: I have to deal with a rather insane vendor-supplied legacy database in which a major constraint is inability to modify the DB schema other than adding the occasional view. I have this DB (as well as a couple of our other 'enterprise' data stores) wrapped in a REST API. Most of our user-facing applications, as well as daemons that monitor the DB for certain events, communicate with the API. In this way I can have the following workflow:

OR/M classes each wrap a single table in the DB. One object == one record.
Decorator classes handle presentation, including composition of more complex objects from simple model objects.
Controller classes respond to requests with a JSON representation of the object appropriate to the client application.
Clent processes data, POSTs or PUTs JSON object back to the API
Controller requests to save object, which is decomposed back to model objects and persisted by the O/RM.

This adds significant complexity.

If you have to deal with heterogeneous data stores, distributed applications, etc., this is an excellent solution. But unless you have those requirements, the rule of thumb is You Ain't Gonna Need It.

Java Design Patterns – Strategy with Fields Acceptability

I would argue that each instance should remain stateless once it is constructed, i.e., it should not maintain extra state across invocations that changes based on the parameters. A classic example is a tax calculator.

interface TaxCalculator {
    /**
     * Calculates the tax for the given purchase price and shipping charges.
     * All values are in pennies to avoid rounding.
     *
     * @param subtotal total price of all items ordered
     * @param shipping cost of shipping the order
     * @return calculated tax
     */
    int calculate(int subtotal, int shipping);
}

class NoTax implements TaxCalculator {
    public int calculate(int subtotal, int shipping) {
        return 0;
    }
}

class FixedPercentOfSubtotal implements TaxCalculator {
    private final int ratePercent;

    public FixedPercentOfSubtotal(int ratePercent) {
        this.ratePercent = ratePercent;
    }

    public int calculate(int subtotal, int shipping) {
        return subtotal * ratePercent / 100;
    }
}

While FixedPercentOfSubtotal has a member (state), it's provided at construction time and never changes. You could store one instance per state, making them quasi-singletons.

Update

Neither the Wikipedia article nor this Strategy Pattern page make any stipulation that implementations should not maintain state across calls. It's less common because strategies are designed to be interchangeable and pluggable at runtime, but I wouldn't rule it out.

However, that you needed to add a new method to enable that one strategy implementation is a red flag. Other implementations may not need it. Will you define it in the interface anyway? It may make more sense to have the historical-tracking strategy implement RaceListener and add it to the race track instance. This would allow it to be shared among multiple users as a singleton.

Best Answer

Related Solutions

Data Serialization – Processing Business Logic Efficiently

Java Design Patterns – Strategy with Fields Acceptability

Related Topic