2017-02-07 6 views
-1

Когда я начал программировать на Java, меня научили всегда использовать API, а не изобретать колесо, написав собственную реализацию уже существующей концепции. Общий способ программирования, который я узнал, был, если мне что-то нужно:Считается ли плохо использовать API?

  1. Проверьте, находится ли он в стандартном API. Если это так, используйте это.
  2. Если реализована только часть его, расширьте этот класс.
  3. Если ничего подобного не существует, напишите собственную реализацию.

Теперь я получаю возможность улучшить читаемость и что легче понять класс, когда он использует только стандартные концепции API. Хотя для второго случая, в конце концов, стало очень трудно придерживаться этого, потому что классы на Java обычно имеют большую общую или дополнительную функциональность, и мне даже не нужна большая часть его для моих целей.

Это привело меня к тому моменту, когда я слишком устал от программирования, потому что для меня это похоже на то, что я трачу большую часть своего времени, пытаясь угадать, какой лучший способ переопределить методы класса, который я распространяю в так, что

  • подходит к моим потребностям для этого «расширения»,
  • палочками это правила, определенные с помощью стандартного API и
  • работает с ним

и в конце есть класс Я использую только два метода.

Так что мой вопрос в том, действительно ли так плохо, что не всегда используют стандартные способы и иногда изобретать колесо таким образом. Я, вероятно, делаю большую вещь из ничего здесь, но со временем это действительно стало для меня большой проблемой и ограничило мои возможности. Я занимаюсь разработкой nit-picker.

Надеюсь, я не единственный, кто это переживает.

EDIT: Хорошо, я вижу, что должен привести пример.

Я тип человека, который беспокоится об использовании памяти при хранении целых чисел в HashSet. Поэтому я создаю новый класс IntSet.java, расширяющий AbstractSet и пытаясь заставить его работать с примитивными ints. Теперь у меня нет доступа к его основным переменным. Поэтому я не могу ничего сделать, не определяя новые переменные, которые будут выделять больше памяти, чем я пытаюсь защитить класс, то есть я должен написать собственную реализацию, которая затем «изобретает колесо».

Другой пример: IntBuffers. Что делать, если мне нужно все, что предлагает IntBuffer (например, метка, позиция и предел) в массиве, но хотите объединить его с растущей и сокращающейся функциональностью. Затем мне пришлось бы переписать весь класс, потому что его конструкторы являются частными.

+0

Почему важна дополнительная функциональность? Вы не думаете, что если класс обладает большей функциональностью, чем вам нужно, вам нужно «сделать свою собственную версию», не так ли? – Kayaman

+0

Этот вопрос немного расплывчатый, чтобы дать для него точный ответ. Не могли бы вы привести какой-то конкретный пример? – pcjuzer

+0

Я думаю, что вы делаете большую вещь из ничего. Но это поможет, если вы можете дать конкретный пример. Это также уменьшит вероятность того, что вопрос будет закрыт как «слишком широкий». – biziclop

ответ

1

Я думаю, что наследование в гораздо более образованном контексте толкнуто. Но когда вы пытаетесь наследовать многие классы в Java API, они либо отмечены как final, либо имеют так много частных членов, что их очень сложно изменить. Есть исключения, конечно, как AbstractList.

В чем заключается то, что реализация интерфейсов или использование других шаблонов проектирования, таких как композиция/адаптер/декоратор, часто более подходят, чем наследование, для поддержки больших разрозненных кодовых баз.

См. Composition vs. Inheritance discussion.