I'll bite. why do you mongoloids shit on this book?

Statically typed functional languages are still going to present issues for you. Dynamically typed languages alleviate solve some of the issues solved in the book.

It was written before people knew any better and the knowledge in there stiffles actual software development.

Dynamic OO languages predate the book. They only sidestep many of the issues in the book by delaying the problems until runtime where they may be easier to solve, but also more error prone. You also lose solid virtual interfaces, which are one of the key components of enterprise OO patterns.

Jow Forums chilling a non funtional proframming or a non C book?
Wtf

Because after a week of assembly
you will understand that there is no such thing as objects, and neither does it offer any benefits

Design patterns are self-help books for programmers.

Attached: ctoc.jpg (495x276, 8K)

retarded

The book is OK. I believe they even mention that design patterns are ways to get around language's limitations. e.g. the command pattern is redundant if you have first class functions and closures. If you use it for that purpose, then you'll have no problem.
But if you instead use design patterns just because, as many novices do, then understanding a program is harder and may not even be reasonably doable without firing up the debugger. It's similar to when someone decides to divide a program in "N-layers" and you end with layers upon layers of mappers of Entity to DTO to service response to ViewModel DTO and back again, but in a more "micro" level.
And the latter is way too common.

Contrariwise, you could work on my team, where our lead who built most of the existing system has now departed and who eschewed such patterns as being cargo cult programming, and now we're left with a big ball of mud that is difficult to test and difficult to integrate with CI/CD and difficult to extend.

norvig.com/design-patterns/design-patterns.pdf

news.ycombinator.com/item?id=8735187

>i'll bite. why do you mongoloids shit on this book?
Bought this book.... it was entirely worthless. It bored me out of my mind. I regret wasting my money.

haskell good
oop bad

Should have written it in C.

Design patterns are gay. I like OOP but some people take it way too far.

C is imperative procedural. It's possible to implement object-oriented programming in it but it's not a core feature.

I shit on people, not on the book.
The problem I see is that design patterns usually turn into a form of cargo cult.
>this pattern, that pattern, anti pattern
They were derived by people who had a good head on their shoulders as an understanding of patterns which naturally occured in good code, as a consequence of the technological limitations of the OO paradigm.

How did functional concepts deprecate e.g. the Observer pattern?

Design patterns and OO, like Democracy, arent solutions to people being idiots. This is mostly an expectation management issue more than anything..

It is perhaps one of the most misunderstood books in our field, as exemplified by a lot of the comments here.
It is full of examples how some common problems might be solved in an object-oriented way and it stated this very clearly.
Never does the book encourage using such patterns where they don't simplify the code. It also encourage readers to identify patterns in their own code to improve their understanding of their own work.
Some of the patterns found their way into standard libraries and language designs and are widely accepted. Others are seen with horror because they were overused ever since.
Again, there is no claim to correctness in this book. It was meant as a rough draft to introduce a new concept. The book itself was too successful while no fruitful discussion ensued.
I'm glad I read it: it teaches a few nice techniques to recognize and solve problems. And say what you will, the proposed solutions make sense in the context of the stated problems.
Me? I'm a Lisp guy.

A lot of programmers said that OP's book is obsolete and pic related is better. What do you guys think of it?

Attached: HF_DesignPatterns.jpg (432x500, 48K)

>see cover
>must_be_fake.png
>google the title
>itsreal.gif
>mfw

Attached: no_way.jpg (800x486, 37K)

1. It is the most boring book in the history of
he universe. Pedantry taken to the stratosphere.

2. Over half the patterns are just repetitive code memes used to overcome the limitations of brain damaged (non-Lisp) languages.

Attached: lisp.jpg (740x220, 59K)

read this

3. OOP is brain damage

To be more precise it is one paradigm of programming, useful in certain contexts but typically over-used even when it just adds pointless code bloat.

if you work, or plan to work in ENTERPRISE programming, it's good to know there are template solutions to specific architectural problems, which you *will* encounter sooner or later. what you *don't* do is the academic way of force-applying solutions to problems that either don't exist or you forcefully make up just to apply the patterns

if anyone shits on the book, it's because they're going the academic route, and then bitch how it doesn't work as planned

Attached: 1394301146040.jpg (600x603, 52K)

seething poo in loo

>Smalltalk
>not pure OO

What land do you live in?

[spoiler]It does suck that it lacks CLOS style multi-methods though and needs stuff like traits to make up for that.[/spoiler]

and after a week of programming anything more complex than fizzbuzz and collaborating with other people you will understand the need for abstraction

Academic programmers bitch about what not working as planned, their careers or OOP?

lol

the introduction is really good (composition over inheritance and program to interfaces) but realistically, i don't think the rest is all that useful and you'll just forget it.

Some things are unavoidable unless your language supports it (I f*cking hate the visitor pattern, but there's no choice if you want type safety)

desu, I think avoiding global state as much as possible (e.g. no statics), minimising code written, not using exceptions and nulls and keeping things as declarative as possible get you 99% of the way there.

>Academic programmers
>OOP

I will never understand how this started. OOP was always something highly pragmatic, but it somehow got taken over by whiteshirts assuming that inheritance hierarchies "model the real world".

Well OOP doesn't necessarily model "the real world" but if you have an idea of any object in the real world you can model it with OOP. OOP kinda changes programming from a bottom-up approach where you start with the nitty-gritty and build more general structures to a top-down approach where you lay out the general idea first and then home in on the details. This may have some undesirable consequences but I think they're outweighed by the benefits.

CS academia has effectively been a meme for the past ~30 years. Now it's just falling for the meme of the month all the time, even at top colleges.
The only valuable academic resources when it comes to CS are older ones.

What's a whiteshirt?

Not him but I worked in place where there were more programs made in assembly language than ones made in java. The entire middleware made to allow communication between the users' interfaces and the mainframe's programs was made in assembly language. Most of the programs being called were in cobol tho.

Don't just avoid global state, avoid any state as much as possible. And if you absolutely need state, encapsulate it and let the rest of your program not depend upon it.

Clojure master race

Whats wrong with exceptions?

Nothing when done correctly -- your CPU have exception vectors in case someone tries something retarded (divide by zero, using instructions that doesn't exists...)

yeah, but it's just an interesting outlier. OOP is still a better choice for the vast majority of software and will allow to ship software in accordance with the typical client requirements infinitely faster. they were written in assembly, because it was probably the best choice for a specific use case, based on performance requirements, available APIs, etc. imagine writting in assembly the whole e-commerce backend, done by many teams, usually having more junior than senior programmers, and dealing with changing requirements throughout the months.

This is kinda the point. Object Oriented has been bastardized to imply class, interface, abstract, virtual, etc. What is originally intended by OO was considering the problem domain in terms of discrete, abstract entities which participate within it. None of this means you have to write actual classes to solve the problem.

>OOP is still a better choice for the vast majority of software and will allow to ship software in accordance with the typical client requirements infinitely faster.
Wrong. Modular programming and V project lifecycle were made for this purpose. OOP is pointless as it adds up layers of abstraction that aren't needed to make a program easier to achieve and maintain. Most of the things you do in OOP can be done faster in a procedural, or even spaghetti language. Despite being fed the exact same shit you're saying at university, I can tell how overly complicated it would be to write any of the programs I made in COBOL during the years I worked as a mainframe programmer but in an OOP language. Funny how you bring the e-commerce backend application as an exemple 'cause that's exactly the kind of this that'd be easier to make in COBOL than in java or anything. What really matters are how well defined the specifications are. Changing requirements will alway cause the result to be a nasty piece of software that no one would like to touch.

t. fizzbuzz programmer

obviously you haven't programmed anything serious, ever

>>/reddit/

I WORK as a programmer for fucking banks and insurance companies you dumbfuck.

>Serious programming
github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

OOP is a brain parasite that makes programming complicated. Layers upon layers of understanding with no understanding.
There wouldn't be a need for so many programmers if there wasn't garbage like OOP.

Saying dumb shit while employed/experienced just makes you look even more retarded, user.

>dumb shit
t. pro-agile java-programming pajeet

Because most of them are just workarounds for missing language features in C++/Java. Even more recent versions of said languages effectively make some patterns obsolete (the Strategy pattern can almost always be replaced by first class functions).
Possibly the worst monstrosity is Visitor, which becomes completely unnecessary with multimethods.
And before someone here makes assumptions, no, I don't think OOP is bad in principle, which is what this thread has been derailed into anyway. The way most popular languages such as C++/Java implement it definitely is, though.
The problem with "design patterns" is that they turn the programmer into a human compiler.
Programming languages should be powerful and flexible enough to let you directly express your solutions and reuse them in similar problems without having to build "recipes" to follow all the time. It's as if you had a "pattern" for function calls, having to pass arguments in certain registers and store results in others... oh wait, language implementations already let me not bother with such pointless busywork every single time.
This also highlights an important problem in current software development trends, in that they tend to be too language-specific (this is a class, inherits here, uses a method there...), when, on sufficiently large projects, having a good deal of language/technology-agnostic design is crucial.
The very concept of "design patterns" fails precisely because they aren't actually *design* patterns, in that they aren't helping you design the final product (the program), they just attempt to fix a tool (the programming language).

yeah, i bet you "program" logos and icons

no. you're stupid

Every 'pattern' should be solved by the programming language itself. That there exists common design patterns for oop code is proof that the paradigm is poorly suited for many problems.
Here's a book on how to use the language. And here's a book on how to work around the inherent design failures of the language.

you don't have a clue what you're talking about

How can you even call that a come back?
Here have your (you), even tho you don't even deserve it with such a pitiful attempt.

Attached: sakura_stare.jpg (1440x1080, 117K)

I create classes for passing many variables into functions. It helps the Idea with autocomplete and it keeps the number of variables passed to a minimum. Come at me.

s/idea/IDE.

Why use a class when a collection will do?

you are mixing up the language with the architecture. no one forces you to design everything in OO manner, link data with behavior, etc, in fact I think it's unmaintainable for larger projects (it suits some things, like GUI, or containers though), and e.g. using stateless services is much superior. it's just that OOP languages have certain features, like polimorphism and incapsulation that make things like dependency injection and modularity much easier
>Funny how you bring the e-commerce backend application as an exemple 'cause that's exactly the kind of this that'd be easier to make in COBOL than in java or anything. What really matters are how well defined the specifications are.
this is total bullshit, especially considering that OOP isn't even enforced in java - you don't have to create an object to invoke a method, there are primitives, etc.

yegor256.com/2016/02/03/design-patterns-and-anti-patterns.html

>it's just that OOP languages have certain features, like polimorphism and incapsulation that make things like dependency injection and modularity much easier
I don't see how these features could make modularity easier. Things like polymorphism could even make impact analysis when maintaining an application.
>this is total bullshit
On the contrary, cobol is PERFECT for this kind of use. I already wrote a few backend cobol transactions that were called by the web interfaces used by the employees at banks, those are usually quite simple most of the time, they share the same modules as some batch programs, so writing these doesn't take a lot of time.

You just suck at programming. I do FPGA verification. I very carefully ensure data generation is easily configurable without requiring the tester to know specifics about the hardware. There are sequencers that pull data from the generators and apply it to an interface. This ensures a separation of data and stateful operations. And all of those operations work independent of the overall state of the hardware device under test (DUT). All of the sequencers are themselves sequenced. This sequencer is what cares about the overall state of the DUT. So giving a shit about state is encapsulated in one object, all other actors are stateless, and all data is separate from behavior. Very rarely do I have to deviate because we write good clean firmware.

>>
my problem with them is that they are untyped. Someone can add a throw to their method, which changes the way all the calling methods need to catch. This means potentially changing lots of functions further up. It also is hard to know when it's safe to wrap things in try/catches, which leads to everyone putting try/catch over everything. Really, I think it should be the compilers job to enforce when you need to handle them.

My other problem is that people abuse them, and catch them in usual, non exceptional cases, which is really slow.

haha. I agree with you, but that's a battle to fight much later. I'm just focusing on the basics here lol.

It just means that the way exceptions are implemented badly in java. Exceptions should be like interrupt routines (that's how they're handled at CPU level, it's just a ). Also the fact that they're not typed shouldn't be an issue for the kind of job you'd expect from this kind of routine.

okay, im not sure about those kinds of exceptions, im just talking about java,c#,c++ style exceptions.