Что такое & ldquo; чрезмерная инженерия & rdquo; применительно к программному обеспечению? [закрыто]
Когда вы объявляете ссылочную переменную (т. е. объект), вы действительно создаете указатель на объект. Рассмотрим следующий код, в котором вы объявляете переменную примитивного типа int:
int x;
x = 10;
В этом примере переменная x является int, и Java инициализирует ее для 0. Когда вы назначаете его 10 во второй строке, ваше значение 10 записывается в ячейку памяти, на которую указывает x.
Но когда вы пытаетесь объявить ссылочный тип, произойдет что-то другое. Возьмите следующий код:
Integer num;
num = new Integer(10);
Первая строка объявляет переменную с именем num, но она не содержит примитивного значения. Вместо этого он содержит указатель (потому что тип Integer является ссылочным типом). Поскольку вы еще не указали, что указать на Java, он устанавливает значение null, что означает «Я ничего не указываю».
Во второй строке ключевое слово new используется для создания экземпляра (или создания ) объекту типа Integer и переменной указателя num присваивается этот объект. Теперь вы можете ссылаться на объект, используя оператор разыменования . (точка).
Exception, о котором вы просили, возникает, когда вы объявляете переменную, но не создавали объект. Если вы попытаетесь разыменовать num. Перед созданием объекта вы получите NullPointerException. В самых тривиальных случаях компилятор поймает проблему и сообщит вам, что «num не может быть инициализирован», но иногда вы пишете код, который непосредственно не создает объект.
Например, вы можете имеют следующий метод:
public void doSomething(SomeObject obj) {
//do something to obj
}
В этом случае вы не создаете объект obj, скорее предполагая, что он был создан до вызова метода doSomething. К сожалению, этот метод можно вызвать следующим образом:
doSomething(null);
В этом случае obj имеет значение null. Если метод предназначен для того, чтобы что-то сделать для переданного объекта, целесообразно бросить NullPointerException, потому что это ошибка программиста, и программисту понадобится эта информация для целей отладки.
Альтернативно, там могут быть случаи, когда цель метода заключается не только в том, чтобы работать с переданным в объекте, и поэтому нулевой параметр может быть приемлемым. В этом случае вам нужно будет проверить нулевой параметр и вести себя по-другому. Вы также должны объяснить это в документации. Например, doSomething может быть записано как:
/**
* @param obj An optional foo for ____. May be null, in which case
* the result will be ____.
*/
public void doSomething(SomeObject obj) {
if(obj != null) {
//do something
} else {
//do something else
}
}
Наконец, Как определить исключение & amp; причина использования Трассировки стека
17 ответов
Чрезмерная инженерия означает разработку и проектирование приложения с большим количеством компонентов, чем это должно быть в действительности согласно списку требований.
Существует большая разница между чрезмерной разработкой и созданием расширяемого приложения, которое может быть обновлено по мере изменения требований. Если я могу привести пример, я отредактирую пост.
Я думаю, что лучшие ответы на ваш вопрос можно найти в , этот другой вопрос
Для меня сверхинжиниринг включает в себя все, что вам не нужно и что вы не знаете, что вам понадобится. Если вы ловите себя на мысли, что функция может быть полезной, если требования меняются определенным образом, то это может быть чрезмерная разработка. По сути, чрезмерная инженерия нарушает ЯГНИ .
Contrary to most answers, I do not believe that "presently unneeded functionality" is over-engineering; or it is the least problematic form.
Like you said, the worst kind of over-engineering is usually committed in the name of future-proofing and extensibility - and achieves the exact opposite:
- Empty layers of abstraction that are at best unnecessary and at worst restrict you to a narrow, inefficient use of the underlying API.
- Code littered with designated "extension points" such as protected methods or components acquired via abstract factories - which all turn out to be not quite what you actually need when you do have to extend the functionality.
- Making everything configurable to "avoid hard-coding", with the effect that there's more (complex, failure-prone) application logic in configuration files than in source code.
- Over-genericizing: instead of implementing the (technically uninteresting) functional spec, the developer builds a (technically interesting) "business rule engine" that "executes" the specs themselves as supplied by business users. The net result is an interpreter for a proprietary (scripting or domain-specific) language that is usually horribly designed, has no tool support and is so hard to use that no business user could ever work with it.
The truth is that the design that is most easily adapted to new and changing requirements (and is thus the most future-proof and extensible) is the design that is as simple as possible.
Излишнее проектирование - это просто создание продукта с большей функциональностью, качеством, универсальностью, расширяемостью, документацией или любым другим аспектом, чем требуется.
Конечно, у вас могут быть требования за пределами конкретный проект - например, если вы планируете создавать аналогичные приложения в будущем, тогда у вас могут быть дополнительные требования к расширяемости, зависящие от стоимости, которые вы добавляете к конкретным требованиям проекта.
Боюсь, что точное определение, вероятно, невозможно, поскольку оно сильно зависит от контекста. Например, гораздо проще перестроить веб-сайт, на котором изображены сверкающие пони, чем систему управления атомной электростанцией. Избыточность, чрезмерная проверка ошибок, хорошо оснащенные средства регистрации - все это чрезмерно сложно для приложения с блестящими пони, но не для системы управления атомной электростанцией. Я думаю, лучшее, что вы можете сделать, - это почувствовать, когда вы прикладываете слишком много накладных расходов к своим функциям для целей приложения.
Обратите внимание, что я бы разделил позолоту и чрезмерную инженерию. На мой взгляд, позолота создает функции, о которых не просили и которые никогда не будут использоваться. Чрезмерная инженерия - это больше о том, насколько "безопасность"
Это связано с моим спорным программным мнением «Самый простой подход - всегда лучший подход» .
Вопреки распространенному мнению, чрезмерная инженерия на самом деле является явлением, которое возникает, когда инженеры «высокомерие» и думают, что понимают пользователя.
Я сделал простую диаграмму, чтобы проиллюстрировать это:
Для меня это все, что могло бы добавить жирности коду. Мясо - это любой код, который будет выполнять работу в соответствии со спецификацией, а жир - это любой код, который раздувает код таким образом, что он просто добавляет больше сложности. Программист, возможно, ожидал будущего расширения функциональности; но все равно он жирный.!
Прелесть Agile-программирования в том, что его трудно переиграть, если вы все делаете правильно.
Цитата отсюда : "... Реализуйте вещи, когда они на самом деле вам нужны, и никогда, когда вы просто предвидите , что они вам нужны . "
Я думаю, что они такие же, как Золотое покрытие и удары Золотым молотком :)
В принципе, вы можете сесть и потратил слишком много времени, пытаясь создать идеальный дизайн, даже не написав код, чтобы проверить, как он работает. Любой гибкий метод скажет вам не делать весь свой дизайн заранее, а просто создавать фрагменты дизайна, реализовывать их, повторять их, перепроектировать, повторять и т. Д.
Мое приблизительное определение было бы «Обеспечение функциональности, которая не требуется для удовлетворения требований спецификации»
If you spend so much time thinking about the possible ramifications of a problem that you end up interfering with the solving of the problem itself, you may be over-engineering.
There's a fine balance between "best engineering practices" and "real world applicability". At some point you have to decide that even though a particular solution may not be as "pure" from an engineering standpoint as it could be, it will do the job.
For example:
If you are designing a user management system for one-time use at a high school reunion, you probably don't need to add support for incredibly long names, or funky character sets. Setting a reasonable maximum length and doing some basic sanitizing should be sufficient. On the other hand, if you're creating a system that will be deployed for hundreds of similar events, you might want to spend some more time on the problem.
It's all about the appropriate level of effort for the task at hand.
Гибкий ответ на этот вопрос: каждый фрагмент кода, который не способствует требуемой функциональности.
На Джоэле о программном обеспечении есть обсуждение, которое начинается с
создания обширных иерархий классов для предполагаемой будущей проблемы, которая еще не существует, является своего рода чрезмерная инженерия, и поэтому плохо.
И переходит к обсуждению с примерами.
В тех случаях, когда мы считали что-то чрезмерно спроектированным, всегда описывалось программное обеспечение, которое было разработано настолько универсальным, что упускало из виду главную задачу, для выполнения которой оно было изначально разработано. , и поэтому стал не только сложным в использовании, но и фундаментально неразумным.