-
![[image]](https://www.balancer.ru/cache/images/forums/logos/1358/128x128-crop/1358631-programming_oop_wallpaper_red_by_hexeno.png)
Нужны ли public конструкторы?
Теги:
Сергей-4030
Собственно, сабж. Чем дальше тем больше мне кажется, что public конструкторы нужны очень и очень редко. Просто исчезающе редко. Ошибаюсь? 
инфо
инструменты
Balancer
Вопроса не понял 
Если про возможность вызова class_name::class_name(..) - то нафиг ненужны. Если про доступ к конструктору извне класса вообще - то как же без него?
Если про возможность вызова class_name::class_name(..) - то нафиг ненужны. Если про доступ к конструктору извне класса вообще - то как же без него?
Balancer> Вопроса не понял Если про возможность вызова class_name::class_name(..) - то нафиг ненужны. Если про доступ к конструктору извне класса вообще - то как же без него?
Именно про доступ извне класса. Т.е. нужны ли конструкции такого вида?
Some thing = new Some(parameters);
ЗЫ Имеется в виду - вне класса, конечно. Методы класса, разумеется, должны иметь доступ к конструктору.
Если про возможность вызова class_name::class_name(..) - то нафиг ненужны. Если про доступ к конструктору извне класса вообще - то как же без него?Именно про доступ извне класса. Т.е. нужны ли конструкции такого вида?
Some thing = new Some(parameters);
ЗЫ Имеется в виду - вне класса, конечно. Методы класса, разумеется, должны иметь доступ к конструктору.
>Т.е. нужны ли конструкции такого вида?
>Some thing = new Some(parameters);
А что в качестве альтернативы?
Some thing = new Some();
thins->setSome(parameter);
?
Бред У меня сейчас по работе почти все объекты идентифицируются одним параметром - своим идентификатором. И нафига мне лишние сущности?
...
Хотя, с другой стороны, как раз в моём случае программы не сильно пострадают, т.к. объкты всё равно возвращаются объект-лоадером:
Some thing = object_load('Some', parameter);
>Some thing = new Some(parameters);
А что в качестве альтернативы?
Some thing = new Some();
thins->setSome(parameter);
?
Бред
У меня сейчас по работе почти все объекты идентифицируются одним параметром - своим идентификатором. И нафига мне лишние сущности? ...
Хотя, с другой стороны, как раз в моём случае программы не сильно пострадают, т.к. объкты всё равно возвращаются объект-лоадером:
Some thing = object_load('Some', parameter);
>>Т.е. нужны ли конструкции такого вида?
>>Some thing = new Some(parameters);
Balancer> А что в качестве альтернативы?
В качестве альтернативы - фабрики объектов. Плюс подхода - контроль создания нового объекта.
Something creature = Forest.createGreyWolf();
>>Some thing = new Some(parameters);
Balancer> А что в качестве альтернативы?
В качестве альтернативы - фабрики объектов. Плюс подхода - контроль создания нового объекта.
Something creature = Forest.createGreyWolf();
Сергей-4030> В качестве альтернативы - фабрики объектов.
Хотя я, как писал, сейчас в 99% случаев такой механизм и использую, тем не менее не согласен. Если у тебя фабрика объектов - то пофиг. Но если где-то прямая загрузка класса, то лишняя сущность. Вообще, это уже, считай, вообще отказ от конструкторов. Зачем тебе конструктор, если ты метод init(params) можешь вызвать?
Хотя я, как писал, сейчас в 99% случаев такой механизм и использую, тем не менее не согласен. Если у тебя фабрика объектов - то пофиг. Но если где-то прямая загрузка класса, то лишняя сущность. Вообще, это уже, считай, вообще отказ от конструкторов. Зачем тебе конструктор, если ты метод init(params) можешь вызвать?
Murkt
Сабж - достаточно спорный вопрос. Зависит от языка и наклонностей. Хотя, в целях тестирования кода — думаю, всё-таки нужны.
Сергей-4030>> В качестве альтернативы - фабрики объектов.
Balancer> Хотя я, как писал, сейчас в 99% случаев такой механизм и использую, тем не менее не согласен. Если у тебя фабрика объектов - то пофиг. Но если где-то прямая загрузка класса, то лишняя сущность. Вообще, это уже, считай, вообще отказ от конструкторов. Зачем тебе конструктор, если ты метод init(params) можешь вызвать?
Нет, я так не думаю. Это еще один механизм скрытия данных. Иначе получается смешно - контролировать видимость отдельного метода мы можем, а контролировать видимость создания объекта - не можем. Создание объекта - это операция, которая должна быть доступна только тому, кто очень хорошо знает, что делает.
Balancer> Хотя я, как писал, сейчас в 99% случаев такой механизм и использую, тем не менее не согласен. Если у тебя фабрика объектов - то пофиг. Но если где-то прямая загрузка класса, то лишняя сущность. Вообще, это уже, считай, вообще отказ от конструкторов. Зачем тебе конструктор, если ты метод init(params) можешь вызвать?
Нет, я так не думаю. Это еще один механизм скрытия данных. Иначе получается смешно - контролировать видимость отдельного метода мы можем, а контролировать видимость создания объекта - не можем. Создание объекта - это операция, которая должна быть доступна только тому, кто очень хорошо знает, что делает.
Сергей-4030> Создание объекта - это операция, которая должна быть доступна только тому, кто очень хорошо знает, что делает.
Хмм... a = new BigInteger(155)
Хмм... a = new BigInteger(155)
Сергей-4030>> Создание объекта - это операция, которая должна быть доступна только тому, кто очень хорошо знает, что делает.
Murkt> Хмм... a = new BigInteger(155)
Это - редкое исключение. Впрочем, даже здесь лучше будет
a = BigInteger.number(155);
Чем это будет хуже? Я не вижу пока. Более того, даже так должно быть:
JustInteger i=Number.integer(155);
где JustInteger - интерфейс. Это почти всегда лучше, исключения - какие-нибудь оптимизации, иногда сильнорасчетные задачи.
Murkt> Хмм... a = new BigInteger(155)
Это - редкое исключение. Впрочем, даже здесь лучше будет
a = BigInteger.number(155);
Чем это будет хуже? Я не вижу пока. Более того, даже так должно быть:
JustInteger i=Number.integer(155);
где JustInteger - интерфейс. Это почти всегда лучше, исключения - какие-нибудь оптимизации, иногда сильнорасчетные задачи.
Сергей-4030>>> Создание объекта - это операция, которая должна быть доступна только тому, кто очень хорошо знает, что делает.
Murkt>> Хмм... a = new BigInteger(155)
Сергей-4030> Это - редкое исключение. Впрочем, даже здесь лучше будет
Сергей-4030> a = BigInteger.number(155);
Чем будет лучше? Я серьёзно спрашиваю - не вижу никаких преимуществ, в принципе варианты равнозначны.
Сергей-4030> JustInteger i=Number.integer(155);
Сергей-4030> где JustInteger - интерфейс. Это почти всегда лучше, исключения - какие-нибудь оптимизации, иногда сильнорасчетные задачи.
Да, этот вариант для Джавы будет лучше.
Murkt>> Хмм... a = new BigInteger(155)
Сергей-4030> Это - редкое исключение. Впрочем, даже здесь лучше будет
Сергей-4030> a = BigInteger.number(155);
Чем будет лучше? Я серьёзно спрашиваю - не вижу никаких преимуществ, в принципе варианты равнозначны.
Сергей-4030> JustInteger i=Number.integer(155);
Сергей-4030> где JustInteger - интерфейс. Это почти всегда лучше, исключения - какие-нибудь оптимизации, иногда сильнорасчетные задачи.
Да, этот вариант для Джавы будет лучше.
Сергей-4030>>>> Создание объекта - это операция, которая должна быть доступна только тому, кто очень хорошо знает, что делает.
Murkt> Murkt>> Хмм... a = new BigInteger(155)
Сергей-4030>> Это - редкое исключение. Впрочем, даже здесь лучше будет
Сергей-4030>> a = BigInteger.number(155);
Murkt> Чем будет лучше? Я серьёзно спрашиваю - не вижу никаких преимуществ, в принципе варианты равнозначны.
Контролем создания объекта. Изоляцией объекта от имплементации. В контексте программы BigInteger.number() не завязан на имплементацию любого класса. Т.е. сто мильонов вызовов new BigInteger() при надобности, скажем, иметь разные имплементации BigInteger для разных платформ значат сто мильонов изменений исходников. В BigInteger.number() изменения минимальны. Конечно, в данном случае, когда класс immutable и места в памяти занимает совсем немного - почти одно и то же. Но даже здесь преимущества factory имеются (хотя их и совсем мало). А вот преимуществ конструктора просто нет, за исключением одного вызова функции.
Murkt> Murkt>> Хмм... a = new BigInteger(155)
Сергей-4030>> Это - редкое исключение. Впрочем, даже здесь лучше будет
Сергей-4030>> a = BigInteger.number(155);
Murkt> Чем будет лучше? Я серьёзно спрашиваю - не вижу никаких преимуществ, в принципе варианты равнозначны.
Контролем создания объекта. Изоляцией объекта от имплементации. В контексте программы BigInteger.number() не завязан на имплементацию любого класса. Т.е. сто мильонов вызовов new BigInteger() при надобности, скажем, иметь разные имплементации BigInteger для разных платформ значат сто мильонов изменений исходников. В BigInteger.number() изменения минимальны. Конечно, в данном случае, когда класс immutable и места в памяти занимает совсем немного - почти одно и то же. Но даже здесь преимущества factory имеются (хотя их и совсем мало). А вот преимуществ конструктора просто нет, за исключением одного вызова функции.
Сергей-4030>>>>> Создание объекта - это операция, которая должна быть доступна только тому, кто очень хорошо знает, что делает.
Murkt>> Murkt>> Хмм... a = new BigInteger(155)
Сергей-4030> Сергей-4030>> Это - редкое исключение. Впрочем, даже здесь лучше будет
Сергей-4030> Сергей-4030>> a = BigInteger.number(155);
Murkt>> Чем будет лучше? Я серьёзно спрашиваю - не вижу никаких преимуществ, в принципе варианты равнозначны.
Сергей-4030> Контролем создания объекта.
Блин, точно. Я уже привык, что у меня этот контроль и так всегда есть.
Murkt>> Murkt>> Хмм... a = new BigInteger(155)
Сергей-4030> Сергей-4030>> Это - редкое исключение. Впрочем, даже здесь лучше будет
Сергей-4030> Сергей-4030>> a = BigInteger.number(155);
Murkt>> Чем будет лучше? Я серьёзно спрашиваю - не вижу никаких преимуществ, в принципе варианты равнозначны.
Сергей-4030> Контролем создания объекта.
Блин, точно. Я уже привык, что у меня этот контроль и так всегда есть.
Я так понимаю, что вопрос навеян Джавой. Отстутствие локальных переменных не встроенных простых типов-классов иногда позволяет так говорить. ИМХО, фабриками всё не решить.
Отстутствие локальных переменных не встроенных простых типов-классов иногда позволяет так говорить. ИМХО, фабриками всё не решить.
Вообще какая разница - создавать объект вызовом метода фабрики или делать то же самое из его конструктора? Который в принципе тоже может вернуть более продвинутый объект, чем заказывали...
Dem_anywhere> Вообще какая разница - создавать объект вызовом метода фабрики или делать то же самое из его конструктора? Который в принципе тоже может вернуть более продвинутый объект, чем заказывали...
Это где? В Java - нельзя. В С++ тоже. Такое делали "много раньше", когда фактически эмулировали объекты в обычном C. И this инициализировали вручную. Но теперь такого больше нет.
Это где? В Java - нельзя. В С++ тоже. Такое делали "много раньше", когда фактически эмулировали объекты в обычном C. И this инициализировали вручную. Но теперь такого больше нет.
Mishka> Я так понимаю, что вопрос навеян Джавой. Отстутствие локальных переменных не встроенных простых типов-классов иногда позволяет так говорить. ИМХО, фабриками всё не решить.
А где отличие от C++? Единственный минус фабрик, который я вижу: один лишний вызов функции. Это может быть проблемой иногда, как в С++ так и в Джаве, но обычно это не проблема. Конечно, и лишнее создание объекта часто не проблема. Но контролировать создание объекта как минимум не хуже, а в случаях, когда создание объекта - процесс очень затратный, так просто много лучше.
Отстутствие локальных переменных не встроенных простых типов-классов иногда позволяет так говорить. ИМХО, фабриками всё не решить.А где отличие от C++? Единственный минус фабрик, который я вижу: один лишний вызов функции. Это может быть проблемой иногда, как в С++ так и в Джаве, но обычно это не проблема. Конечно, и лишнее создание объекта часто не проблема. Но контролировать создание объекта как минимум не хуже, а в случаях, когда создание объекта - процесс очень затратный, так просто много лучше.
Сергей-4030> А где отличие от C++? Единственный минус фабрик, который я вижу: один лишний вызов функции. Это может быть проблемой иногда, как в С++ так и в Джаве, но обычно это не проблема. Конечно, и лишнее создание объекта часто не проблема. Но контролировать создание объекта как минимум не хуже, а в случаях, когда создание объекта - процесс очень затратный, так просто много лучше.
Отличие С++ в количестве временных объектов, возникающих в реальных приложениях.
Отличие С++ в количестве временных объектов, возникающих в реальных приложениях.
Сергей-4030>> А где отличие от C++? Единственный минус фабрик, который я вижу: один лишний вызов функции. Это может быть проблемой иногда, как в С++ так и в Джаве, но обычно это не проблема. Конечно, и лишнее создание объекта часто не проблема. Но контролировать создание объекта как минимум не хуже, а в случаях, когда создание объекта - процесс очень затратный, так просто много лучше.
Kernel3> Отличие С++ в количестве временных объектов, возникающих в реальных приложениях.
И в чем же именно это отличие?
Цифры?
Kernel3> Отличие С++ в количестве временных объектов, возникающих в реальных приложениях.
И в чем же именно это отличие?
Цифры?
Kernel3>> Отличие С++ в количестве временных объектов, возникающих в реальных приложениях.
Сергей-4030> И в чем же именно это отличие? Цифры?
Какие цыфры? Количество объектов? Вечером дам пример кода со своей предыдущей работы - сами прикинете. Пока же просто напишу своё ХО, что явное создание объектов во всех случаях делает само использование такого абстрактного механизма, как ООП, практически бессмысленным.
Сергей-4030> И в чем же именно это отличие?
Цифры? Какие цыфры? Количество объектов? Вечером дам пример кода со своей предыдущей работы - сами прикинете. Пока же просто напишу своё ХО, что явное создание объектов во всех случаях делает само использование такого абстрактного механизма, как ООП, практически бессмысленным.
Kernel3>>> Отличие С++ в количестве временных объектов, возникающих в реальных приложениях.
Сергей-4030>> И в чем же именно это отличие? Цифры?
Kernel3> Какие цыфры? Количество объектов? Вечером дам пример кода со своей предыдущей работы - сами прикинете. Пока же просто напишу своё ХО, что явное создание объектов во всех случаях делает само использование такого абстрактного механизма, как ООП, практически бессмысленным.
Чего?! Вы точно поняли, про что топик?
Сергей-4030>> И в чем же именно это отличие?
Цифры? Kernel3> Какие цыфры? Количество объектов? Вечером дам пример кода со своей предыдущей работы - сами прикинете. Пока же просто напишу своё ХО, что явное создание объектов во всех случаях делает само использование такого абстрактного механизма, как ООП, практически бессмысленным.
Чего?!
Вы точно поняли, про что топик?
Kernel3>> Какие цыфры? Количество объектов? Вечером дам пример кода со своей предыдущей работы - сами прикинете. Пока же просто напишу своё ХО, что явное создание объектов во всех случаях делает само использование такого абстрактного механизма, как ООП, практически бессмысленным.
Сергей-4030> Чего?! Вы точно поняли, про что топик?
Да нет, конечно, я случайно зашёл. Куда уж нам до сурьёзных людей с сурьёзными мыслями, боящихся перегрузки операторов и публичных конструкторов.
Сергей-4030> Чего?!
Вы точно поняли, про что топик? Да нет, конечно, я случайно зашёл. Куда уж нам до сурьёзных людей с сурьёзными мыслями, боящихся перегрузки операторов и публичных конструкторов.
Kernel3>>> Какие цыфры? Количество объектов? Вечером дам пример кода со своей предыдущей работы - сами прикинете. Пока же просто напишу своё ХО, что явное создание объектов во всех случаях делает само использование такого абстрактного механизма, как ООП, практически бессмысленным.
Сергей-4030>> Чего?! Вы точно поняли, про что топик?
Kernel3> Да нет, конечно, я случайно зашёл. Куда уж нам до сурьёзных людей с сурьёзными мыслями, боящихся перегрузки операторов и публичных конструкторов.
Я не пытаюсь вас обидеть, мне просто непонятно, как из наличия factories можно сделать такие глобальные выводы про бессмысленность ООП. Вы бы расшифровали, в чем именно проблема. Я на самом деле не понимаю.
Сергей-4030>> Чего?!
Вы точно поняли, про что топик? Kernel3> Да нет, конечно, я случайно зашёл. Куда уж нам до сурьёзных людей с сурьёзными мыслями, боящихся перегрузки операторов и публичных конструкторов.
Я не пытаюсь вас обидеть, мне просто непонятно, как из наличия factories можно сделать такие глобальные выводы про бессмысленность ООП. Вы бы расшифровали, в чем именно проблема. Я на самом деле не понимаю.
Kernel3> Да нет, конечно, я случайно зашёл. Куда уж нам до сурьёзных людей с сурьёзными мыслями, боящихся перегрузки операторов и публичных конструкторов.
Да-да. А еще мы, серьезные люди, боимся гоуту и вообще - программирования спагетти. По своей ограниченности. Гоуту - в массы, долой предрассудки!
Да-да.
А еще мы, серьезные люди, боимся гоуту и вообще - программирования спагетти. По своей ограниченности. Гоуту - в массы, долой предрассудки!
Сергей-4030> Я не пытаюсь вас обидеть, мне просто непонятно, как из наличия factories можно сделать такие глобальные выводы про бессмысленность ООП. Вы бы расшифровали, в чем именно проблема. Я на самом деле не понимаю.
Надеюсь, станет понятнее после примера кода. Грубо говоря, если вместо 5 строчек кода придётся каждый раз писать 20, то непонятно, а на хрена, собственно, нужно всё это абстрагирование. Бо на голых Сях получится примерно то же самое.
Надеюсь, станет понятнее после примера кода. Грубо говоря, если вместо 5 строчек кода придётся каждый раз писать 20, то непонятно, а на хрена, собственно, нужно всё это абстрагирование. Бо на голых Сях получится примерно то же самое.
Copyright © Balancer 1997..2022
Создано 09.12.2007
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Создано 09.12.2007
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
