Программирование ver 4.0

а это что? new Runnable()

По сути это создание объекта безымянного класса, который реализует интерфейс Runnable.

в жаве не принято перед интерфейсом писать буковку I? типа IRunnable?

в жаве не принято перед интерфейсом писать буковку I? типа IRunnable?

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

а что это за конструкция такая, что метод замещается прямо в конструкторе?

так в джаве делаются анонимные делегаты

делегатов конечно нет, но есть вот такой вот синтаксис создания анонимных классов

 

в жаве не принято перед интерфейсом писать буковку I? типа IRunnable?

всегда так делаю, так как дотнетчик и очень понравилась эта конвенция

сагитировал уже троих фул-джаверов к такому же стилю )

в жаве не принято перед интерфейсом писать буковку I? типа IRunnable?

всегда так делаю, так как дотнетчик и очень понравилась эта конвенция

сагитировал уже троих фул-джаверов к такому же стилю )

Зачем нарушать искомый стиль Java?! :(

какая практическая польза от get и set в C#?

разве в джаве не проще? getSize(...) setSize(...)?

и чем оно проще?

гетсет в шарпе позволяет обращаться типа как напрямую к полю вместо очевидного обращения к методу

 

hui.Size = 30

>>>

hui.Size(30)

 

Write(hui.Size)

>>>

Write(hui.getSize())

Изменено 14 марта 2013 пользователем TheDeadSkin

и чем оно проще?

гетсет в шарпе позволяет обращаться типа как напрямую к полю вместо очевидного обращения к методу

 

hui.Size = 30

>>>

hui.Size(30)

 

Write(hui.Size)

>>>

Write(hui.getSize())

Таки да, намного проще, убедил

 

public class Hui

{

private int _size;

 

public int Size

{

get{ return _size; }

set{ _size = value; }

}

}

ну и что тут не так? типа в шарпе гетсет блок писать больше чем два метода?

какая практическая польза от get и set в C#?

разве в джаве не проще? getSize(...) setSize(...)?

ну конечно же var a = GetSize(); проще чем var a = Size;

 

и чем оно проще?

гетсет в шарпе позволяет обращаться типа как напрямую к полю вместо очевидного обращения к методу

 

hui.Size = 30

>>>

hui.Size(30)

 

Write(hui.Size)

>>>

Write(hui.getSize())

Таки да, намного проще, убедил

 

public class Hui

{

private int _size;

 

public int Size

{

get{ return _size; }

set{ _size = value; }

}

}

скорее как-то так public int Size { get; set; }

А что если так?

 

public class Hui

{

public int size;

}

Изменено 14 марта 2013 пользователем AbstractBaseFactoryBuilderManage

А что если так?

 

public class Hui

{

public int size;

}

ну это уже поле. оно всегда часть реализации. читай хардкод

А что если так?

 

public class Hui

{

public int size;

}

а завтра ты ограничиаешь диапазон значений размера члена от 1 до 100 и сам сосёшь 100-сантиметровый хуй, потому что у тебя не было инкапсуляции

А что если так?

 

public class Hui

{

public int size;

}

ну это уже поле. оно всегда часть реализации. читай хардкод

ну я часто делаю поля пабликами в DTO-объектах, очень удобно

особенно в джава-мире, где надо кучу геттеров и сеттеров генерить

в шарпе это не так необходимо

А что если так?

 

public class Hui

{

public int size;

}

а завтра ты ограничиаешь диапазон значений размера члена от 1 до 100 и сам сосёшь 100-сантиметровый хуй, потому что у тебя не было инкапсуляции

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

без абстрактной фарбрики фарбик не обойтись

А что если так?

 

public class Hui

{

public int size;

}

а завтра ты ограничиаешь диапазон значений размера члена от 1 до 100 и сам сосёшь 100-сантиметровый хуй, потому что у тебя не было инкапсуляции

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

ты утрируешь, вероятность изменения логики в определённой переменной значительно выше чем изменения логики в целом

вдруг тебе внезапно стало недопустимым иметь null или пустую строку в какой-то из строковых переменных

 

что делать? просто добавь воды логику в уже готовом методе

set;

=>

set { _penisName = string.IsNullOrEmpty(value) ? "Unknown Name" : value; }

 

а что делать, если инкапсуляция не предусмотрена? правильно, переписать все обращения к переменной

ну студия допустим-то умеет переименовывать переменные меняя во всём проекте команды любых к ней обращений, а если тебе в итоге нужно будет по-разному обращаться изнутри класса к этой переменной (минуя гетсет) и извне (через гетсет), там уже переименование не очень-то поможет

 

в общем в любом случае всё зависит от характера класса, но если в теории допустимы в будущем любые логические ограничения на работу с переменной (запретить установку значения, ограничить допустимые значения, возвращать переменную как-нибудь по-другому), то лучше писать гетсет наперёд

почему нельзя написать геттер и сеттер только когда он реально понадобится?

потому что у тебя необходимость в логике для переменной может появиться позже чем ты уже наебенишь к ней 500 обращений из самых разных кусков кода

.

 

потому что у тебя необходимость в логике для переменной может появиться позже чем ты уже наебенишь к ней 500 обращений из самых разных кусков кода

 

так для этого и есть set и get?

 

я про них и говорю, кто тебе мешает написать их когда у тебя обращение к переменной уже разбросано по коду?