Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Outside of some 1-2 decades old frameworks, can you show me a singular example for any of your ObjectFactories? Because I really think that the field as a whole moved a bit away from such deep object hierarchies and even in OOP circles will try to use as few levels as possible.

Also, don’t forget that complexity can be divided into two categories: essential and accidental complexity. The former can’t be decreased at all. We should strive to minimize the latter of course, but we often forget about the first.

Just to be a bit more relevant - system boot is a very complex task, so the first type of complexity will be plentyful. It is basically a service/hardware dependency-graph. Sure, you can hard-code singular cases (previous init systems basically did that) but hardware and services are sufficiently different to not make it that feasible, and every single hard coded version can be buggy.

A declarative approach is much saner and it is no accident that basically every OS in wide use switched to that.



It's definitely gotten better but there's still questionable overabstraction in certain standard libraries and/or popular frameworks (such as Spring).

For example, in Java, to create a Trust Manager for certificates, you have to first call a factory method to get a TrustManagerFactory, before I can even get a TrustManager: https://docs.oracle.com/javase/7/docs/api/javax/net/ssl/Trus...

That's just really weird and confusing design.


I'm not familiar with Java or their concept of trust managers, but I don't really see a major problem with it. It doesn't seem like there is anything confusing. I might not know why they did that, but I don't think I'd have trouble understanding code that uses it.

I'm guessing someone probably thought that a lot of the common use cases would be best done with a factory pattern, and they didn't want you to have to implement it all yourself.

It seems like a very strong form of One and Only One Obvious Way to Do It, extending so far as to have an opinion about what pattern to use.

Or, maybe there's just some other API that needs a factory for something, and so they have to directly expose it, and they don't want there to be more than one way to get one.

I would have to actually be familiar with Java to have a real opinion on it, but on the surface it seems kinda nice. It feels like the kind of thing that might help prevent hacky or quick and dirty code from being written in the first place, and possibly save time refactoring.


You don't think it's weird that there is a static factory method that you have to call in order to get a factory that you have to call in order to get the real thing? IMHO, that's exactly the kind of thing that Java gets rightly ridiculed for.

They could have had just a factory method on the TrustManager class itself.


Also, it is an old, deprecated part of the Java standard library, which lives by different design patterns. Since the public API can’t really change without breaking backwards compatibility, some form of abstraction is required so that later on they can modify the private API well.


If this is deprecated, what is the more "modern" way of getting a trust manager?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: