Greg Hall

OOP has its uses, just like FP, but they are not the end all be all.

OOP can be useful in a library, for example, because you decide how to write the library. The people using your library don't care about the internal structure, they will likely never read the code. All they care about is how to use the library to do what they want.

But with custom software you don't really know where the software is going, the customer will change their mind as their business needs change. They don't know what they will ask for next year, so neither do you. That means any rigid structure based on todays needs will likely work against you shortly down the road.

ORMs have their use, but not always. They can be very complex, bloated with a lot of features you'll never use. If you have to connect to different databases (eg, Postgres and MySQL), then an ORM can save a lot of work. Mostly, you only need one database, and once you have a pattern for making queries yourself, it can just be copied and modified.

It's a trade-off either way:

- If the client generates an id, it pretty much has to be a UUID, as there really isn't much else that can be guaranteed unique from one random request of one random client amongst many. UUIDs aren't the best primary key to use, they're 16 bytes apiece, that makes for a larger index.
-If the server generates the id, then it can be something smaller like an 8 byte 64-bit integer that takes half the index space. But then it isn't idempotent.

Actually, thinking about this a bit more, most database creates and updates are not idempotent to begin with:

- Last modified date gets changed
- A version number is increased to prevent people from clobbering someone else's changes (optimistic locking)
- An audit log tracks field changes

This means if you replay the same request a second time, side effects like the above occur, making the second request not idempotent. It doesn't matter if the id is generated on the server if there are other side effects anyway.

The only way for updates to be idempotent is if a check is made that at least one data field has been modified, where a data field is a field the user enters, not the id, and not a side effect only field like last modified or version. While I'm sure somebody somewhere did this, I have never personally seen any app that does this check on an update.

So I think the best approach would be:

- Use PUT for create or update operations that are idempotent, that have no side effects, and no change of any field (whether or not it is visible to the user) is performed if the data fields are the same

- Use POST for create or update operations that are not idempotent for any reason

- Use POST for other stuff that is not CRUD

My point is simply that human nature doesn't lend itself towards good OOP design for a custom project for one customer, with a system that functions like you suggest.

I don't disagree with your ideas. Yes, Spring will have some dusty corners, every project does. We don't need perfection. Part of the problem is MDD (Masturbation Driven Development) - devs love new shiny tools and languages. They usually don't help much. But try telling people who insist on using 6 pieces of infrastructure that they can use only SQL, they will probably barf at your ideas.

You sound like you favor the KISS principle (Keep It Simple Stupid). That is, just use a simple code setup that doesn't use a ton of frameworks and tools. Write functions that operate on data from the outside (take one or more objects as parameters), and make these functions do one thing and test it works well.

I'm not suggesting not designing up front. I'm just saying that you only know the design today, you don't know how things will change later on - after all, the customer is running a business, and the needs of that business vary, not always in predictable ways.

OOP patterns tend to require a particular code structure for the problem they solve. If you write imperative code, you don't need to require a lot of structure, you can be more open-ended about it. I think the best way to be the lazy developer you describe is imperative code.

The problem isn't that you can't write good OOP code, it is simply that people on custom software teams just don't.
People who work on open source libraries like Spring do. If you compared the organization and quality of a code base like Spring against a random custom project that's a one-off for a single customer, chances are there is a vast difference between the two.

This is due to a difference in optics - if a widely used codebase like Spring was crappy, it would affect everybody using it, and they would likely abandon it. But if only one customer is using a crappy codebase, then only that one customer ever complains, and you only have to find a way to satisfy that one customer with yet another crappy workaround.

The motivation for open source libraries is helping an entire community. The motivation of a one-off project is todays JIRA ticket.

I'm writing about something I've seen many times over, and provided my analysis of it.

Do you disagree that the problem exists, my analysis of it, or both?

I'll also add to this that the phrase "A service that selects a proper URI on behalf of the client" could be interpreted as referring to a URI that the client cannot reasonably determine themselves, as it varies based on factors the client may not know.

If the proper URI is well known like just adding the generated id, such as using PUT <apiurl>/<type> after which you can retrieve with GET <apiurl>/<type>/id, then arguably you don't need the service to select a proper URI. Part of the point of REST is to have such well known semantics.

The RFC does not say how to identify a resource, in terms of what range of values to use.

There is nothing wrong with using the empty value to identity a new resource, and a non-empty value to identify an existing resource.

So if you figure most use cases leave the back end to generate ids, then just don't provide a value to PUT, and let the back end generate an id. You would have to return at least the generated id in the PUT response body.

And again, the RFC says PUT should be create or update, and it says POST can also create. It is up to you to decide whether you want to use only PUT for create, only POST, or a combination of both depending on the circumstance.

I said about POST that "all versions say if a resource is created that 201 Created SHOULD be returned.". That implies that POST can indicate that a new resource is created. Just because that is possible does not mean you have to use it that way.

Your sentence regarding PUT does not mean you know the id - only that you know the resource. You know my first and last name, but not my Canadian Social Insurance Number, Nova Scotia medical id, or any other government identifier. The only identifier you know is my dzone id, which is only guaranteed to be unique within dzone.

There is no reason why the client should know any id when putting. A site like dzone could generate an id for a new user instead of asking for one during sign up. The generated id could be displayed in a short readable form like a git commit hash.

I didn't say all kinds of software on all field situations, that's your willful misinterpretation. I said custom software someone else is paying you to make. So, for example, I'm not saying anything about:

- Kernel development

- A product you develop and convince people to buy, like MS Excel

- Interfacing with hardware devices

- Real time software like in a factory where robots build stuff

- AI

- Military applications

The same problem can also occur in other places, like the view. I've seen the same problem in JSP and Angular code. I've seen the same problem with executing SQL queries.

Inheritance is still a pattern:

- There are implications about fields, methods, final/sealed, static, hashcode, equals, interfaces, generics, bounds, etc depending on the language

- There are many ways to use inheritance, a lot of people advocate composition instead as more manageable

- It does nothing whatsoever to aid in preventing tangled code where changing something affects more than one part of the system. It also does nothing to aid in making it obvious that this piece of code affects multiple unrelated parts of the system.

You can always refactor, but it is a matter of effort. Often, code is so tangled that a refactor is just as hard as a rewrite. That's what I'm trying to solve here, is keeping code manageable over time. By having separate code for each object, it is easy to maintain, because you're not tying yourself to a pattern you only know is a good pattern to use today.

I'm not convinced you understand how repeating yourself makes code easier to maintain over time.

Well, if you actually read it, then you would know I did not say anything about identifying patterns after the code is written. I have identified issues with code bases that became spaghetti code of some sort, and analyzed what led to it, to try and avoid the same thing happening again. That is a very different thing.

I advocate for repeating yourself instead of not, because the quest to reuse code across what are really unrelated objects and use cases tends towards creating unnecessary relationships between screens. Imperative also offers a way to help reduce this. There's no magic bullet, I did not suggest I have one, nor do I suggest this is the only solution.

Are you seriously going to tell me with a straight face you have never seen problems in code bases like the ones I have described in 23 years? You've never seen an over use of not repeating yourself? You've never seen OOP anti-patterns? Of course, there are other problems one can have with code, I'm specifically speaking towards common problems I keep seeing across companies and projects in 18 years.

That does not have to do with OOP. You can tie unrelated screens with functional or imperative programming. The reason this occurs, is a lack of separation of things that diverge over time in the false belief they will always have a lot in common. The reality is if you don't know what changes will come in the future, then you don't know which objects will always have something in common, you only what objects happen to have something in common right now.

That is an interesting article. But it does not agree or disagree with my contention that OOP is inherently up front design.

Like I said, if you write a bunch of code using some specific pattern, and you realize later that pattern is now hampering you, that is a very difficult decision to change. You can't expect to just casually change that in an afternoon of coding.

And yes, crappy code can obviously be written in any paradigm or language, I never said it couldn't, nor did I suggest that OOP has some special level of crappiness.

So what you done to protect against random changes that can be very hard to implement in the face of a particular chosen architecture, based on what was known at the outset?

You say off to OOP where you don't know all the requirements. Ok, how are you doing that? Can you given an example of something you did in the past where you had no trouble with some new requirement that at first blush seems to fly in the face of the design? Can you give an example where you had great difficulty with a new requirement?

I never said OOP is bad period, only that it is not always the best choice. The same can be said of imperative, stack, functional, proofs systems, or any other paradigm.

Perhaps you can explain what OOP has to do with unlimited scaling, or what kind of scaling you're talking about.

OOP may have taken over in the past, but it is not always the choice now. Some are choosing functional, some imperative, some a mixture of multiple paradigms.

I am familiar with patterns. As I said, the problem is that you don't know how the system will evolve up front when random changes are requested as the project progresses. As a result, choosing OOP patterns has the obvious problem of which pattern solves this problem. If you think you know OOP patterns better, then explain which one is designed for this problem. Explain what you have done to avoid this from happening.

Typical dismissive attitude of a dev who has not written a single article on the site, only makes negative comments as his sole contribution.

Yes, that is correct.

I'm just going to add that I don't really care about the size of each service, I'm more interested in memory consumption and benefits of having multiple services for maintaining code over time.

I would call it many services, not micro services. The point being that if, for example, you choose to use Spring and JPA you only have one copy of those frameworks for the whole app, not copies for each service. Since they take up over 200MB together, a single copy is fine, but 50 copies for 50 services is not.

If that's true, then the usage of micro is incorrect, and some other word should have been used.

But I don't think most people would agree with what you said - I think most people see microservices as basically a way to have more separate pieces of code instead of one large monolith, which intrinsically means the pieces are smaller. The whole point is to try to avoid the spaghetti code mess of one large codebase. Some would argue if a single service becomes a mess, it can be replaced more easily since it is smaller.

It's also a bit silly to stop reading just because you disagree with one point.

Well, there isn't really one answer. What I started using consisted of:

- JSP for generating HTML server side

- Java code for backend

- A framework called Struts I don't think anyone uses anymore to deal with requests from browser in Java code

- Ant as a build tool, long since replaced by Maven

Maven is genuinely a better build tool than Ant. Ant was XML as code, with strange steps. Maven works best with Java code, but can be used for C/C++ code if you want, and probably other languages.

Server side rendering is far less complex than a single page app. That means less work to maintain it, like anything else less complex.

I would be happy to do the following

- Use server side rendering. Could be Java JSP, Go html/template, every popular language has something like these examples.

- Pick a simple front end library that produces a nice looking UI, such as Shoelace or Tabler. I'm sure they could both be used with Angular or React if you really needed to at some point.

- Use PostgreSQL for the database. Out of the box, it can do graph and hierarchical queries, full text searches. It has many extensions, allowing it be a good one ring to rule them all for most custom apps built by software companies for customers.

- Have one repo with top level dirs for each service

- Deploy one container with all services in it. You're not Netflix, you can redeploy your one container off hours.

- Use a simple method of handling REST, like Go net/http or Java HttpHandler. It's not hard to write your own code that deals with verbs, cookies, URL paths, and query parameters. You can just make some utility functions for most cases.

- Crucially - only add more infrastructure (EG, Redis or ElasticSearch, etc) if you genuinely need it - eg, you tried materialized views, indexes, tablespaces, query optimizations, partitions, read replicas, and it still isn't good enough. Your database is still too slow, then ok, go ahead and use Redis as you have what it is designed to solve - a slow database. Start with just your SQL database, and use other tools only when they are really needed. Once added, these other tools will never go away, and you pay a permanent operational tax on their existence - fixing bugs with your usage, updates for security vulnerabilities, migrating to new versions, training for incoming team members, money costs like cloud expenses, etc.

Now someone else might have a different stack that is similarly simple, and that would be fine. This is a moving target, as frameworks and libraries keep falling out of favour, then they don't really get updated anymore in some cases, and new libraries pop up that might be genuinely better in some way that actually affects team performance.

There probably isn't. People have been happily not doing this for over 25 years of Java. I guess the stock answer would be, the same use case as C++.

Interestingly, the C++ community said long ago to only derive from one class that actually has behaviour, and the others should just be the equivalent of a Java interface - they only define methods that have to be implemented.

I just like sometimes to do something like this for fun.

I like the approach being taken of compiling generic code to ordinary code so people can try it with real problems. I'm going to give this a try with my streams library and see if it helps, what works/doesn't. Should be interesting.
Thanks for the update, I wasn't following this proposal.

There are ways to deal with that kind of stuff in Go.

An iterator doesn't have to be a class in Go, it just can just be a function like "func iter() (X, bool)", where X is the type to iterate. Either it returns (X, true) because there is another X to iterate, or (zero value, false) because there are no more Xs to iterate. Yes, you'd have to keep writing them, but it's only a single function of usually < 10 lines of code.

Usually a generic abstraction doesn't refer to the generic type in every single method return value. If an abstraction has 20 methods, maybe only 4 of them return the generic type. Then only those 4 need to be tied to a specific type using embedded structs.

Not sure what you mean by "using template methods of a concretion that may have more methods than the abstraction. on a language that doesn't even have typing system".

As for dynamic typing errors at runtime, that's where the localisation comes in that I mentioned:

1. Write struct GenericFoo that uses type "interface{}" for its methods so it can handle any type in Go.
2. For each specific type X, write GenericFooX that embeds a GenericFoo.
3. For each method of GenericFoo that returns "interface{}", replace it in GenericFooX to return type X instead. Internally, the method type asserts "interface{}" to X.
4. If you want, also replace methods that accept "interface{}" in GenericFoo so they accept X in GenericFooX. This isn't really required, since Go allows any value to be passed to a function that accepts "interface{}".

Another option is code generation - use some kind of generator to produce GenericFooX structs with correct signatures for the specific types you want.

It basically depends on how much work you're talking about - if it's not a lot of work, use copy/paste to create GenericFooX structs. If there are lots of methods and it's a lot of work, use a code generator.

I think sometimes we're spoiled by runtime code generation in managed languages that allow it. Go only has, to my knowledge, reflect.MakeFunc, which won't help much with generics. What Go does have is "go generate", which you might find useful for generating code for GenericFooX structs.

Try https://blog.golang.org/generate as a starting point.

Why do you think just because I don't think generics are an important feature that I have limited experience in Java? Limited compared to what? I've worked on Java projects at companies for about 12 years, and personally for many more.

I wouldn't presume to know someone's experience in anything based on a single posting they authored online, just because I disagree with what they say.

I never said there was no use for generics. Instead of putting whatever words you feel like in my mouth just to sound superior, why don't you try making a real argument? Once that isn't cynical, snide, dismissive, or arrogant. Assuming that is, that you actually know how. Is this how you talk to your coworkers? You must be real popular.

That's all well and good for my own personal projects, but oddly enough the projects I have worked on at the companies I worked for were not MY projects. The fact not a single one of them had any significant use of generics aside from collections also wasn't MY choice.

For my current company I needed to write a parser in Go for a somewhat strange document format that was never intended to read by computers. I didn't find parsing it in Go any worse than any other general purpose language. I personally prefer recursive descent parsing.

The reason Go has no MaxInt is that int is 32 bits or 64 bits depending on the platform. You should be able to determine at runtime which size it is by using an expression like "i := math.MaxInt32 + 1". On a 32-bit platform the result should be 0, on 64-bits it should be 2147483648.

This is getting somewhat off topic, but I don't think interfaces are a very good paradigm for functional programming. I definitely prefer having functions as first class data types as in Go.
Java only has "functional interfaces" due to tacking functional on top of OOP. And it only has the silliness of all these primitive/object parameters due to generics only using objects.
That is the one thing I wish Java had done differently, having generics also working with primitives.

Some of those problems could probably have been solved in some other way.

As an example, I find one trap people fall into is the progression of a data structure:
- I need to keep track of some strings, I'll use a List.
- Oh, now I need to associate each string with an int, I'll use a Map.
- Actually, I need a pair of ints per string, ...

Each change requires modifying various for loops in various methods, some method signatures, etc. A better idea would be to abstract all access to the data structure into a separate class, with semantically meaningful method names like "addPreferredCustomerToInvoice".
If the abstraction needs to modify the underlying list/maps, etc, no code outside the abstraction is affected. This is one form of the localisation I was talking about.

I hadn't thought of that. I wish some of these surveys were more in depth. In fact, almost any survey I read about online seems lacking in depth.
I'm sure all of those opinions you mentioned exist in the 21 percent, and other opinions we haven't thought of.

I never said generics are bad, only that we don't really need them.
They require significant additional complexity in the compiler, anything that complex tends towards a few really strange compiler error messages until you know what they mean, sometimes you might still have to do some strange casting, etc.
Personally, I don't think Java's generics is a bad implementation,I just never felt like wow, this is amazing and solves a real problem I have.

Yes, there are some good usage of generics, I never suggested there isn't.
That doesn't mean every language needs it as a feature, or that it is critically important.

Using Java generics as an example is no worse than using C++ templates or any other example of generic programming. It's no different than comparing engines of different car manufacturers, it's hardly a wild apples to gun barrels comparison.
Regardless of which implementation you compare against, the points are valid - the compiler gets significantly more complex, there are some hard to understand rules, and you don't really have to have it.

If you passed a type that contains interface{} to a bunch of methods on multiple structs, then you'd probably be right,

But you don't have to do that, you can keep it localised as I mentioned. That's why for years of Java it didn't bother me. Try it!

Did you ever try using Thymeleaf to preprocess it's own files? EG, you have input templates that use the include tag to include common stuff like css, company logo, privacy policy link, etc. The build tells Thymeleaf to process the file without using separate logic, and with no beans. The output is a template that has the common elements copied into it. The output template can then be used at runtime with separate logic and beans. This allows both a living prototype and the ability to separate out common elements so that one change can affect many templates. It should work, never tried it.

I can honestly say I have always hated JSF, and dread using it. I freely admit it's not entirely JSF's fault, I found that people loved to abuse JSF in ever increasingly inventive fashions, the result was always a spaghetti ball of garbage. I've usually seen the same thing with JSP projects.

I would prefer to use Thymeleaf, as it makes it easy to produce HTML because you simply write it as HTML with a separate file to say how to replace hard-coded data in the template with real data. You can have a "living prototype" that can be viewed at anytime without any server.

Tools are not my decision, they're the decison of every company I have worked for, made usually by someone who is no longer there by the time I arrive :)

And if it was up to me, I would choose the tools people are actually using, not my personal preference, because it is in the company's best interest to have projects using tools any random hire should be familiar with.

And that's my point - tools limit you, so much so that using FP primarily in Java means writing your own tools. I'm sure there are other languages where the opposite is true.

And yes, you're right that you can achieve a balance of FP and OOP in Java.

I find what's usually lacking in these debates is practical reality, such as:

- Libraries like JPA and Spring MVC that require mutable objects with an empty constructor and setter methods.

- The need side for effects somewhere along the line (eg I/O operations)

All such considerations can simply be summed up with one statement: you're not going to write everything yourself. Depending on others code inherently means you can't control how they chose to write their library/framework that you depend on, which limits how you program.

Not sure I get part of my post what your comment on strong typing relates to. I'm a great fan of using reflection for all its worth, hence my suggestion of mapping a URL to a method of a class. It also eliminates the refactoring that invariably leads to a URL of /customer that displays an address.

And I'm way more unusual than you can possibly imagine :)

Well said :) But is any other language really any better? If so, does it have all the stuff Java has for PDFs, spreadsheets, database, networking, etc ad nauseum? If not, can it work reasonably well in the JVM directly or through ScriptManager? I've been asking myself if this is the way forward, something else in the JVM that can access all those libraries.

It largely feels to me like a "damned if you do, damned if you don't" proposition to use a language like Java, same for OOP.

In the end, I'm happy if the project is well structured with maintainable code. Unfortunately, that seems rare.

And how about a 25-page spec!

You should know you an still address those issues without a 570 page spec :) SQL injection? Come on, that's free - just use PreparedStatements, which people tend to use anyway. Character encoding? Just use UTF-8. I've never needed to translate encodings for any application yet in over 10 years, though I'm sure some people have. Filtering can be done with J2EE filters.

I'm aware of those points you mention, they are are not complicated. They can all be taken care of without tens of megabytes of code and hundreds of pages of specs.

I doubt the need for the giant tools we use all the time in Java far more than OOP. Why do I need a 570 page spec just to translate between rows of an SQL database and Java objects? Why do I need a 486 page spec just to deliver a String of HTML to a user's browser?

I'd far rather see a less-is-more approach where simple things are done simply. It only takes some simple string manipulation to translate a URL into a Java classname and method name to execute for that URL. A small bit of code can translate between forms and Java objects. I don't really care if it uses OOP or FP.