Private methods, constructors or classes are against EO principles

[fabriciofx]

Private methods, constructors or classes are against EO principles. Please, check this comment and @yegor256 opinion about them. So, let's change the code to create package or public classes and only public methods.

[0crat]

@llorllale/z please, pay attention to this issue

[llorllale]

@fabriciofx can you balance this against the rule of three?

[fabriciofx]

@llorllale I don't have anything against code duplication. I've against methods, constructors and classes private . Look that Rule of Three is basicaly against create new abstractions to avoid duplication, but when you create a private method, constructor or class you already created the abstraction, but put them hidden to others.

[llorllale]

@fabriciofx

when you create a private method, constructor or class you already created the abstraction

In most cases I don't think we (conciously) have. For example, can you extract any meaningful abstraction from WriterAsOutputStream.next()? Perhaps you can't but still want to press ahead and eliminate this private method. How will this affect the readability of WriterAsOutputStream.write(byte[], in, in)?

[fabriciofx]

@llorllale I think the WriterAsOutputStream.next() should be a new class. Something related to a buffer. And it can be very interesting, because many classes in cactoos use buffers, ins't it?

[llorllale]

@fabriciofx please elaborate on how this Buffer type would look.

[victornoel]

@fabriciofx is still of concern and if yes, can you list what are the problematic method, constructor or class?

IMHO private methods, constructors and inner classes can make sense as they are part of the encapsulated object. It can make sense to make them public IF you find a good reason to do so, not beforehand.

See this articles about the danger of thinking in term of reuse as a first principle and the danger of having the wrong abstractions: https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction

[fabriciofx]

@victornoel well, due to respect, including to Sandi Metz, I disagree. But I agree to close this issue, if you want.

[victornoel]

@fabriciofx before closing it, maybe we can look at the problematic class, methods, constructors and see if it makes sense to do something, but I would like to be clear about the job to be done before putting that in scope

[fabriciofx]

@victornoel I think what Sandi Metz said about abstraction is about an abstraction which is used to build class around you project, like interfaces do. If it's the point, I agree with her. But my point is: when you make a private class or method they already a kind of abstraction too. So, if you're creating a new abstraction, why not put it in a public class and use it in your class or method? The advantage is you can allow for others users reuse (or not) this class too. Bu you can think: "ah, but this class or method doesn't make any sense outside this other class". How we can sure about that? We don't know! Just let's do it public and let the user decide if it wants use or not.

[victornoel]

@fabriciofx still, until you don't put a rough list of what you think should be changed, I don't know if I can put this in scope, we can argue about theory for a long time, but looking at real use case we will know what to do :)