-1

When I started programming in Java, I was taught to always use the API and not reinvent the wheel by writing an own implementation of an already existent concept in it. The general way of programming I learned was, if I need something:

  1. Check whether it's in the standard API. If so, use that.
  2. If only a part of it is implemented, extend that class.
  3. If nothing like that exists, write an own implementation.

Now I get the point of improving readability and that it's easier to understand a class when it's uses only the standard API's concepts. Though, for the 2nd case, eventually, it became really hard to stick to that because classes in Java usually have a lot of general or extra functionality and I don't even need most of it for my purposes..

This has driven me to a point at which I am too tired of programming because, to me, it looks like I'm wasting most of my time trying to guess whats the best way to reimplement the methods of the class I'm extending in a way that

  • fits to my needs for this "extension",
  • sticks to it's rules defined by the standard API and
  • works out with it

and in the end have a class I'm only using two methods of.

So my question is if it's really that bad to not always use the standard ways and to sometimes reinvent the wheel that way. I'm probably making a big thing out of nothing here but, over time, this really became a big thing for me and limits me in my possibilities. I'm a real nit-picker when it comes to programming..

I hope I'm not the only one experiencing that.

EDIT: Okay I see I will have to give an example.

I'm the type of person worried about memory usage when storing integers in a HashSet. So I'm creating a new class IntSet.java extending AbstractSet and trying to make it work with primitive ints. Now I have no access to it's underlying variables. So I can't actually do anything without defining new variables that would allocate more memory than I'm trying to safe with the class, meaning I have to write an own implementation of it which would then "reinvent the wheel".

Another example: IntBuffers. What if I need everything an IntBuffer offers (like a mark, a position and a limit) on an array but want to combine it with growing and shrinking functionality. I would then have to rewrite the whole class because the constructors of it are private.

  • Why does extra functionality matter? You don't think that if a class has more functionality than you need, that you need to "make your own version" of it, do you? – Kayaman Feb 07 '17 at 13:51
  • This question is a bit vague to give a precise answer for it. Could you come up with some concrete example? – pcjuzer Feb 07 '17 at 13:54
  • I think you are making a big thing out of nothing. But it would help if you could give a specific example. It would also reduce the chance of the question being closed as "too broad". – biziclop Feb 07 '17 at 13:55
  • Yes it is bad. There are so many wheels already invented... Perhaps you need functionality of Apache Common BeanUtils, will you spend your time(and money) to write your own? Long time back I had to do it, and I will never do it again. :-) – Vadim Feb 07 '17 at 14:17
  • 1
    Item 2 in your list is incorrect. As Patrick has pointed out, you should favor composition over inheritance. In other words, create a new class which may or may not use HashSet internally to achieve its implementation. Create a new class which may or may not use IntBuffer internall to achieve its implementation. – VGR Feb 07 '17 at 14:55

1 Answers1

1

I think that inheritance is pushed a lot more in an educational context. But when you try to inherit from many classes in the Java API they are either marked final or have so many private members that it's difficult to really modify them. There are exceptions of course like AbstractList.

What it boils down to is that implementing interfaces or using other design patterns such as composition / adapter / decorator are often more suited than inheritance for maintaining large disparate codebases.

See: Composition vs. Inheritance discussion.

Community
  • 1
  • 1
Patrick Parker
  • 4,863
  • 4
  • 19
  • 51