Там какая-либо причина состоит в том, чтобы написать краткий код в Java/C#/C ++?
Вы можете попробовать использовать Java Introspection API или более надежную библиотеку поверх этого API, такую как apache commons beanutils , или даже более мощную библиотеку отображения бинов, например Dozer, или что-то более новое. см.
Следующий пример, демонстрирующий базовую технику, только необработанный самоанализ и отражение с двумя совместимыми бобами POJO.
import java.beans.BeanInfo;
import java.beans.IntrospectionException;
import java.beans.Introspector;
import java.beans.PropertyDescriptor;
import java.io.Serializable;
import java.lang.reflect.InvocationTargetException;
import java.util.Arrays;
import java.util.Map;
import java.util.function.Function;
import java.util.stream.Collectors;
class Tranformation {
public static void main(String[] args) {
MyCar car = new MyCar();
car.setId("id01");
car.setName("Komodo");
car.setMadeIn("Jakarta");
CarDTO dto = toDto(CarDTO.class, car);
System.out.println(dto);
}
public D toDto(Class dtoClass, E entity) {
if (null == entity) {
throw new NullPointerException("Entity can not be null");
}
try {
final D ret = dtoClass.newInstance();
BeanInfo dtoBeanInfo = Introspector.getBeanInfo(dtoClass);
final Map mapping = Arrays.stream(dtoBeanInfo.getPropertyDescriptors())
.collect(Collectors.toMap(PropertyDescriptor::getName, Function.identity()));
final BeanInfo entityBeanInfo = Introspector.getBeanInfo(entity.getClass());
Arrays.stream(entityBeanInfo.getPropertyDescriptors()).forEach(src -> {
if (!"class".equals(src.getName())) {
PropertyDescriptor dst = mapping.get(src.getName());
if (null != dst) {
try {
dst.getWriteMethod().invoke(ret, src.getReadMethod().invoke(entity, null));
} catch (IllegalAccessException | IllegalArgumentException | InvocationTargetException e) {
throw new IllegalStateException(e);
}
}
}
});
return ret;
} catch (InstantiationException | IntrospectionException | IllegalAccessException e) {
throw new IllegalStateException(e);
}
}
public static class GenericDTO {
private String id;
private String name;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
public static class CarDTO extends GenericDTO {
private String madeIn;
public String getMadeIn() {
return madeIn;
}
public void setMadeIn(String madeIn) {
this.madeIn = madeIn;
}
@Override
public String toString() {
return String.format("CarDTO [id=%s, name=%s, madeIn=%s]", getId(), getName(), madeIn);
}
}
public static class AbstractEntity implements Serializable {
private static final long serialVersionUID = 70377433289079231L;
private String id;
private String name;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
public static class MyCar extends AbstractEntity {
private static final long serialVersionUID = 8702011501211036271L;
private String madeIn;
public String getMadeIn() {
return madeIn;
}
public void setMadeIn(String madeIn) {
this.madeIn = madeIn;
}
}
}
Выходы:
CarDTO [id=id01, name=Komodo, madeIn=Jakarta]
12 ответов
Код должен быть столь же кратким по мере необходимости и не больше.:)
Легкомысленные комментарии в стороне существуют несколько факторов, влияющих, насколько краткий (или иначе) это должно быть:
Продолжительность жизни.
- Часто дольше, чем Вы думают :)
Вероятность ошибок.
- Как, вероятно, зависит от многих вещей, но у исходного кодера есть большая часть для проигрывания в этом.
Компьютерное чтение (анализирующее) его.
- Не только компилятор, думайте intellisense и т.п..
Люди, читающие его
- иногда сырые данные, иногда с помощью программ как различные инструменты.
- иногда не тот же человек, который записал это.
Необходимые рабочие характеристики.
Все эти вещи объединяются для создания ряда иногда конкурирующий силы, которые могут хотеть более или менее многословие.
Балансировка их является ключом к эффективной разработке. То, которые более важны, полностью зависит от проблемы, которую Ваше программное обеспечение пытается решить.
Прежде всего позволяет, берут легкие биты:
Компьютеры.
Когда они читают Ваш код, они довольно способны к выполнению так независимо от многословия. Они могли бы быть немного медленнее, но это - что-то, что обычно трудно измерить (маловероятно, что Вы пойдете вне 1 или двух порядков величины многословия, чем минимальная теоретическая возможность). Существенные исключения - то, где Вы - (ab) использование чего-то как метапрограммирование через препроцессор, чтобы сделать большое расширение для Вас. Это может занять много времени при компиляции. Здесь необходимо решить, стоит ли этот компромисс того.
Люди.
Обычно они будут людьми с подобным контекстом Вам, и они будут читать источник в аналогичной ситуации к тому, когда Вы записали это. Этим это означает, что, если функция была в файле/классе/модуле по имени Foo затем, нет никакой потребности пойти, помещая Foo перед вещами, аспект Foo его должен быть довольно ясен из контекста. Это делает изменение этого аспекта легче в будущем.
Программисты, знакомые с идиомами языка/стиля программирования Вас, используют, будет довольно способно к пониманию нескольких конструкций, которые являются чрезвычайно краткими. Индексные переменные цикла звонили, 'я', например, являюсь столь кратким, как Вы можете добраться, но обычно являетесь не проблемой, пока Ваш цикл не становится большим.
Здесь Вы видите интересную дихотомию. Значение краткости часто пропорционально сложности блока кода, в рамках которого это находится. Поскольку этот блок становится более кратким, переменные в нем извлекают выгоду больше из того, чтобы быть уменьшенным. Написанием кода в функциях/классах с ограниченной ответственностью это становится легче и более полезным для хранения вещей краткими, поскольку существует меньше объема для беспорядка со стороны человека. Как это ни парадоксально это может привести к потребности в контексте, чтобы быть более явным, таким образом более длинный метод и имена классов.
Продолжительность жизни
Продолжительность жизни и вероятность фактора ошибок в то, как часто необходимо будет или прочитать код или отладку через него. Много отладчиков поддерживают точки останова в нескольких точках на строке (правильно определяющий, где существует два оператора), но некоторые не делают. Поэтому уход должен быть взят, если Вы намереваетесь к точке останова в нем много удостовериться, что можно поместить и управлять ими с минимальным усилием.
Если код имеет низкую вероятность ошибок, но длинная продолжительность жизни у Вас есть другая интересная ситуация. Вероятность кода, являющегося понятным, когда Вы приезжаете для изменения его, намного ниже (Вы будете иметь худшую память или даже не можете быть там больше). Этот код поэтому извлечет выгоду из того, чтобы быть немного менее кратким, чем нормальный.
Производительность
При случае Вам, возможно, придется пожертвовать компактным, но ясным представлением чего-то для удовлетворения цели производительности, возможно, Вы должны разрядный пакет, например, никогда хорошая вещь читать в коде, но неизбежный, если необходимо вписаться в определенное количество памяти. Случаи как они, надо надеяться, редки.
Общие понятия
Некоторые конструкции языка могут поощрить краткий код (автоматические свойства, анонимные внутренние классы, лямбды для именования только некоторые). Где эти понятия имеют смысл использовать, используют их рассудительно. Идея состоит в том, что они уменьшают шаблон и выставляют намерение.
Если Вы неоднократно делаете то же самое и имеете определенное количество дублирования кода, рассматривают общую функцию/класс/модуль, но помнят, что, если необходимо сделать общий код менее четким (говорят, что дополнительное, если оператор или неиспользуемые переменные в одном из путей выполнения кода) затем у Вас не может быть сетевой победы.
Вывод типа мощен, но помните, что компилятор иногда намного лучше в нем, чем человек. Если Вы говорите flibble x = new flibble() затем var x = new flibble() не фрагмент вообще (и поправляется, поскольку flibble становится больше). Сравните var flibble = SomeMethodWhoseReturnTypeIsNotClear(). Здравый смысл помогает здесь, если бы Вы никогда не должны были бы использовать intellisense для работы его, то, конечно, необходимо рассмотреть использование его.
Некоторый другой полезный (и краткий) эмпирические правила:
- Несколько действий с одной строкой часто смущают людей.
- Побочные эффекты часто смущают людей (++ x, или x ++ не имеют значения вообще концептуально если часть более широкого выражения, например),
- Добавление отступа помогает большинству людей вывести структуру намного больше, чем скобки
- Правила приоритета часто 'усваивают' люди, а не помнят как ряд правил. Это означает, что бесполезный (к компилятору) заключение в скобки может быть вредным для удобочитаемости, где идиома распространена, но полезна, где использование не является настолько общим.
- Логичный не часто отдельный символ. При использовании этого в, если оператор рассматривает, может ли он быть реструктурирован для не требования его. Это не может быть возможно (если получающиеся искривления к переменной/имени метода или упорядочиванию кода перевешивают удаление, оставляют его внутри),
Это зависит от Вашего определения 'кратких'.
Если Вы значите 'короткий и для точки', она тесно соответствует моему видению для хорошего кода.
Если Вы имеете в виду 'загадочный', то существует проблема.
Это зависит от того, под чем точно Вы подразумеваете "краткий". Мне, конечно, нравится писать краткий код, который выражает точно, чего я хочу достигнуть самым простым способом. Например, я люблю способ, которым LINQ позволяет мне выразить конвейер данных, а не "старый" способ записать циклы, чтобы преобразовать или отфильтровать наборы или найти самое большое значение и т.д. Это - просто дублирующий код, который должен быть в шаблонном методе где-нибудь.
С другой стороны, более короткий код не всегда более читаем, чем более длинный код. Условный оператор является предметом спора на этой передней стороне.:
Foo x = null;
if (condition)
{
x = y;
}
else
{
x = z;
}
более или менее читаемый, чем:
Foo x = condition ? y : z;
Ну, если "условие", "y" и "z" все довольно просто, победы условного оператора. Если бы необходимо пройти обручи для создания "y" и "z" отдельных выражений, где выполнение нескольких операторов было бы более читаемым, то, если/еще форма, вероятно, будет более читаемой.
Короче говоря, я пишу самый читаемый код, я могу. Это часто, но не всегда, краткий код.
@j_random_hacker (еще не может добавить комментарии к комментарию),
Это произошло со мной, что после 6 месяцев мне трудно дешифровать часть кода, который я написал. Так действительно эта часть имеет значение также
При запрете всех других проблем более короткий код лучше, так как Вы видите больше из него сразу.
Попытайтесь всегда написать код разъединения. Иногда код разъединения является кратким, но часто это не.
Почему? Поскольку через 6 месяцев необходимо будет понять то, чего Вы пытались достигнуть. Чем быстрее можно сделать это, тем лучше.
Я - огромный поклонник кода, который я могу прочитать. Я видел некоторый "краткий" код, который похож:
int af = yb;
while(af<ex){af++;af*=4;}
Легко видеть то, что делается программно, но ЧТО на самом деле делается с точки зрения значения, неясно. У меня очень были бы имена переменной, которые я могу считать позже, чем пытающийся сохранить пару символов кода и идущий с краткими именами. Хороший код не всегда означает самый короткий. Хороший код о хороших алгоритмах, хорошей документации, хорошей пригодности для обслуживания. Я не забочусь, какой длины код, если он имеет все те свойства, это - хороший код.
Помните, что код читается чаще, чем он записан, и помните о своих читателях при записи (читатель мог даже быть Вами). Не пишите код как Вы, предполагают, что читатель глуп, ни напишите код, который предполагает что, чем меньше из него там, тем лучше это.
Запишите 'короткий, и к точке' как Joel Coehoorn предлагает.
При записи фактического исходного кода, быть максимально устойчивым (не жертвуя производительностью). IE:
var result = GetResultFromFoo(GetOtherResult()).DoSomeCalculation(CallAnotherMethod());
могла быть забава записать, но удача, отлаживающая того сосунка. Нет никакого преимущества, просто сломайте его к этому;
var result = GetOthereEsult();
var fooResult = GetResultFromFoo(result);
var anotherMethodResult = CallAnotherMethod();
var finalResult = fooResult.DoSomeCalculation(anotherMethodResult);
Намного легче отладить.
Единственное время I видит причину написать максимально краткий код, то, если размер вопросов исходного кода (как в файле JavaScript это - поданные сотни времен секунда) или намеренно пытаясь запутать код, однако обычно существует программное обеспечение там, которое делает это для Вас. Так нижняя строка, IMO, нет действительно нет никогда большой части причины его.
Я нашел, что удобочитаемость человеку является самой важной функцией кода в конечном счете.
Удобочитаемость включает быть кратким, точным и clearminded. При смешивании вещей Вы смущаете своего читателя. Если Ваш код является четким читать, Вам не нужны много комментариев. При повреждении сложных вещей вместе в локальных, хорошо именованных переменных Вы помогаете читателю очень при неявном документировании того, что Вы делаете.
Правильно написанный код переживет Вас. Боритесь за совершенство :)
Принятие Вы используете термин "краткий" с "загадочной" коннотацией:
Если это не запутываемый конкурс кодирования, я не вижу никакой смысл в записи краткого кода на скомпилированном языке. Я, возможно, написал краткий код C++ только в моих собственных частных проектах. Никогда в коде, который кто-то еще собирается видеть.
Иначе краткий (в смысле "к точке") код лучше, чем подробный код.
Существует один механический недостаток к подробному коду и называющий в Java: Объем потребляемой памяти под определенным JVMs. Это может только быть проблемой восприятия вокруг процесса виртуальный размер и файлы банки с отображенной памятью, но это действительно существует. Большие файлы банки == большое (воспринятое) использование памяти.
Вероятно, необходимо взять вещи к экстремальным значениям для этого, чтобы быть измеримыми в отношении краткости, но это - интересный "реальный" эффект.
С точки зрения фактического совета, как другие сказали, напишите хороший код сначала и беспокойство об оптимизации позже.