[.NET лучше, чем Java] Что такое пакеты в Java?
// как распределять классы по пакетам?
Исключительно как тебе удобно.
// Пакеты в Java это что-то среднее между пространствами имен и сборками.
Какими нафиг сборками? Единицей функциональности в Java является .class-файл. Что тебе непонятно?
// Еще странно то, что нет модификатора, который разрешает доступ только наследникам. (protected элементы видны классам того же пакеты).
Что тебя так смущает? Можешь привести пример?
Исключительно как тебе удобно.
// Пакеты в Java это что-то среднее между пространствами имен и сборками.
Какими нафиг сборками? Единицей функциональности в Java является .class-файл. Что тебе непонятно?
// Еще странно то, что нет модификатора, который разрешает доступ только наследникам. (protected элементы видны классам того же пакеты).
Что тебя так смущает? Можешь привести пример?
>>Исключительно как тебе удобно.
о том и речь, что не удобно пакетами пользоваться
о том и речь, что не удобно пакетами пользоваться
>>Что тебя так смущает? Можешь привести пример?
то что нет protected как в .NET
то что нет protected как в .NET
А я говорю - удобно! 
Пример будет?
Пример будет?
а ещё в Java нет __published как MSVC++. Дальше-то? Приведи пример, где это важно.
полноценные примеры долго приводить.
Пример, на C#
Трахаться в одежде не удобно. В C# компилятор выдаст ошибку, в Java нет.
Пример, на C#
public abstract class Человек
{
public void Поебаться
{
//снять одежду
СовершитьПоловойАкт;
}
protected abstract void СовершитьПоловойАкт;
}
public class Мужчина: Человек
{
protected override void СовершитьПоловойАкт
{
//вставить член
}
}
public class Женщина: Человек
{
protected override void СовершитьПоловойАкт
{
//принять член
}
}
public class Test
{
public static void Main
{
new Мужчина.СовершитьПоловойАкт;
}
}
Трахаться в одежде не удобно. В C# компилятор выдаст ошибку, в Java нет.
а в C++ еще есть friend.
и... что?
и... что?
да причем тут С++, сравниваются современные платформы для быстрой разработки бизнес приложений
имхо плохой пример привел. валяй то, что хочешь получить.
Ваще какую то хуйню написал
Неудобно,зато можно же =)
Неудобно,зато можно же =)
Я ничего не понял из твоего примера, кроме того, что "ты хочешь поговорить об этом" .
Вот тебе пример того, что твой пример не слишком удачный. Сейчас люди при желании меняют пол. Как ты, интересно, будешь выполнять эту операцию в своей программе? Т. е. был Man, а стал Woman, при этом оставаясь в основном тем же самым Human.
.Вот тебе пример того, что твой пример не слишком удачный. Сейчас люди при желании меняют пол. Как ты, интересно, будешь выполнять эту операцию в своей программе? Т. е. был Man, а стал Woman, при этом оставаясь в основном тем же самым Human.
Вот тебе пример того, что твой пример не слишком удачный. Сейчас люди при желании меняют пол. Как ты, интересно, будешь выполнять эту операцию в своей программе? Т. е. был Man, а стал Woman, при этом оставаясь в основном тем же самым Human.шаблон State:
public class Человек
{
Пол пол;
public Пол Пол
{
get
{
return пол;
}
set
{
пол = value;
}
}
public void Поебаться
{
this.Пол.Поебаться;
}
}
public abstract class Пол
{
public void Поебаться
{
//снять одежду
СовершитьПоловойАкт;
}
protected abstract void СовершитьПоловойАкт;
}
public class МужскойПол: Пол
{
public static readonly Пол Instance = new МужскойПол;
private МужскойПол
{
}
protected override void СовершитьПоловойАкт
{
//вставить член
}
}
public class ЖенскийПол: Пол
{
public static readonly Пол Instance = new ЖенскийПол;
private ЖенскийПол
{
}
protected override void СовершитьПоловойАкт
{
//принять член
}
}
public class Test
{
public static void Main
{
Человек человек;
//смена пола
человек.Пол = ЖенскийПол.Instance;
}
}
замена названия класса в IDE делается в течении нескольких секунд
Вот из-за таких как ты люди и смотрят косо на ООП. Слов много, толку мало. Неужели нельзя было написать нечто вроде:
public class Human {
public enum Gender { Male, Female }
public boolean makeLove(Human partner) {
...
return success;
}
}И вообще, какой тезис ты отстаиваешь, можно наконец узнать?Вот из-за таких как ты люди и смотрят косо на ООП.это твои первые шаги в ООП?
В догонку. Раз уж ты привёл столь подробный код, можно тебя спросить, почему метод СовершитьПоловойАкт не принимает никаких аргументов?
почему метод СовершитьПоловойАкт не принимает никаких аргументов?потому что
полноценные примеры долго приводить.я написал о том, что думал в тот момент
. О голубых я тогда не думал.> Неужели нельзя было написать нечто вроде:
> public class Human { public enum Gender { Male, Female }
В большинстве случаев, неудачное решение, т.к. у Male и Female обычно разные поля:
например, у Female - есть размер бюста, а у Male-а есть длина члена.
> public class Human { public enum Gender { Male, Female }
В большинстве случаев, неудачное решение, т.к. у Male и Female обычно разные поля:
например, у Female - есть размер бюста, а у Male-а есть длина члена.
Спасибо, в курсе. Я только хотел сказать, что так и не увидел за горой кода смысл поста. К чему всё это?... Я уже спрашивал про тезис, но безуспешно.
у тебя в теле метода будут операторы условного перехода (и даже вложенные).
Теперь требуется добавить еще десяток методов.
СходитьВТуалет;
НайтиРаботу;
СделатьПокупки;
НайтиПоловогоПартнера;
СделатьПодарок;
Отдохнуть;
.....
Реализация каждого метода своя для каждого пола. В каждом методе у тебя будет всё тот же условный оператор?
А если надо будет добавить еще один пол, переписывать все методы?
Теперь требуется добавить еще десяток методов.
СходитьВТуалет;
НайтиРаботу;
СделатьПокупки;
НайтиПоловогоПартнера;
СделатьПодарок;
Отдохнуть;
.....
Реализация каждого метода своя для каждого пола. В каждом методе у тебя будет всё тот же условный оператор?
А если надо будет добавить еще один пол, переписывать все методы?
ты же сам просил
Можешь привести пример?а теперь пишешь, что
не увидел за горой кода смысл поста
смысл поста:
Что такое пакет?
Что такое пакет?
Разве нельзя считать пакет аналогом сборки?
Это не очень удобно, т.к. тогда получится, что в сборке все классы в одном неймспейсе.
Можно считать его маленькой сборкой из одного неймспейса
Но, в общем, я согласен с автором треда, имхо по этой части C# удобнее.
Можно считать его маленькой сборкой из одного неймспейса
Но, в общем, я согласен с автором треда, имхо по этой части C# удобнее.
Я могу предположить, что при изменении пола - я этим ещё не баловался , так что не в курсе - часть привычек (твоих методов) остаётся. Отсюда вывод - надо давать реальный кейс, а не флудить на ходу бесполезным кодом.
, так что не в курсе - часть привычек (твоих методов) остаётся. Отсюда вывод - надо давать реальный кейс, а не флудить на ходу бесполезным кодом.ага, давай просто флудить 
без кода
без кодаЕсли ты хотел узнать, что такое пакет, мог бы почитать http://java.sun.com/docs/books/jls/second_edition/html/packages.doc.htmla> , а не разводить здесь ещё один тупой holy-war-тред.
По-моему, вполне нормально заявить: "Я имел дело вот с такой ситуацией: [ситуация]. Согласитесь, эти пакеты кого угодно в гроб загонят."
А у тебя говорится, что вообще в принципе пакеты это не кул, потому что например мне в них трахаться неудобно. Что тут скажешь... Бери пакетики поменьше, идеально - презервативы...
А у тебя говорится, что вообще в принципе пакеты это не кул, потому что например мне в них трахаться неудобно. Что тут скажешь... Бери пакетики поменьше, идеально - презервативы...
Я имел дело вот с такой ситуацией: [ситуация]. Согласитесь, эти пакеты кого угодно в гроб загонят."тк описать коротко ситуацию сложно. Пакеты, неймспейсы, сборки как раз и служат для организации кода, т.е. они важны, когда много кода. Поэтому я спрашивал "теоретическую основу" пакетов, т.е. какую идею в них вкладывали разработчики.
В первом же абзаце по твоей ссылке написано
Programs are organized as sets of packages. Each package has its own set of names for types, which helps to prevent name conflicts. A top level type is accessible (§6.6) outside the package that declares it only if the type is declared public.т.е. зачем то на пакеты наложили двойную нагрузку:
1. чтобы не было конфликта имен
2 введен уровень доступа
Зачем было смешивать не понятно.
Ничего не понимаю. Давай так: а как это - не смешивать эти пункты?
это как в .NET
а вообще, прикольно, это наверное у всех инерция мышления. У меня старший коллега тоже c Java начинал, и тоже всё время путается. internal называет доступ на уровне пространства имен. Может и я чё не догоняю, потому что с C# начинал?
// а вообще, прикольно, это наверное у всех инерция мышления. У меня старший коллега тоже c Java начинал...
Да, прикольно. А откуда инфа, что я с Java начинал?
Да, прикольно. А откуда инфа, что я с Java начинал?
В общем, получился ещё странный наезд на Java. Мол, она не кул, потому что в ней нет свойства X. Что это за свойство X, и чем его отсутствие отравляет жизнь, осталось за рамками дискуссии.
Остаётся посоветовать программировать на C#/C++/Oberon/ML, чувствовать себя кул и не мучать себя и других попытками наладить взаимопонимание с ламерской Java.
Остаётся посоветовать программировать на C#/C++/Oberon/ML, чувствовать себя кул и не мучать себя и других попытками наладить взаимопонимание с ламерской Java.
т.е. зачем то на пакеты наложили двойную нагрузку:А зачем на классы накладывать двойную нагрузку? И данные, и поведение одновременно?
1. чтобы не было конфликта имен
2 введен уровень доступа
Зачем было смешивать не понятно.
>> то что нет protected как в .NET
Аааа! В жаве нет протектед! Кто придумывал этот языг?
Объясняю ДЖЮниту на пальтсах:
У тебя есть класс. У класса есть внутренняя структура и внешний интерфейс. К внутренней структуре должен быть доступ только у класса и его потомков - чтобы тот, кто хочет использовать этот класс _снаружи_ не пытался понять, зачем нужны функции Раздеццо и НадетьПрезерватив, в то время как ему их _вообще_ не следует использовать. И в то же время класс ДвухуийМужчина, унаследовавшийся от, мог бы их переопределить, вызывать в любом порядке етс.
На плюсах/шарпе/дельфи это делается при помощи модификатора протектед очень быстро и просто. На джаве мне пришлось бы заводить настоящий интерфейс и фабрику. "Конечно, можно удалять гланды и через задний проход"(с).
Аааа! В жаве нет протектед! Кто придумывал этот языг?
Объясняю ДЖЮниту на пальтсах:
У тебя есть класс. У класса есть внутренняя структура и внешний интерфейс. К внутренней структуре должен быть доступ только у класса и его потомков - чтобы тот, кто хочет использовать этот класс _снаружи_ не пытался понять, зачем нужны функции Раздеццо и НадетьПрезерватив, в то время как ему их _вообще_ не следует использовать. И в то же время класс ДвухуийМужчина, унаследовавшийся от, мог бы их переопределить, вызывать в любом порядке етс.
На плюсах/шарпе/дельфи это делается при помощи модификатора протектед очень быстро и просто. На джаве мне пришлось бы заводить настоящий интерфейс и фабрику. "Конечно, можно удалять гланды и через задний проход"(с).
Аааа! В жаве нет протектед!Он есть. "И незачем так орать." (С)
не знает Java
Но все равно protected не совсем такой, как в C++ и C#.
Вообще, по-моему, очень гнилая тема для обсуждения. Ну, мне, по крайней мере, не удалось найти аргументов в пользу подхода в C# или Java
Но все равно protected не совсем такой, как в C++ и C#.
Вообще, по-моему, очень гнилая тема для обсуждения. Ну, мне, по крайней мере, не удалось найти аргументов в пользу подхода в C# или Java
Ок, мне уже сказали.
А почему джюнит об этом не знает?
А почему джюнит об этом не знает?
Не могу знать-с. Не имею чести быть знакомым . Вообще судя по тому, что он тут читал Эккеля "Thinking in Java", про protected он знает.
Не имею чести быть знакомым . Вообще судя по тому, что он тут читал Эккеля "Thinking in Java", про protected он знает.Спасибо за доверие . Наличие protected в Java зафиксировано самим -ом в последнем предложении первого поста:
. Наличие protected в Java зафиксировано самим -ом в последнем предложении первого поста:Еще странно то, что нет модификатора, который разрешает доступ только наследникам. (protected [тот, что в Java] элементы видны классам того же пакеты).
Спасибо, что объяснил про назначение protected . На самом деле я когда вижу в исходниках слово private, мне часто уже хочется сказать авторам всё, что я о них думаю. Хотя у них тоже были причины запретить использовать свой интересный код, который в этом случае приходится повторно использовать методом Copy-Paste.
---
Это ещё ладно, бывают люди, которые считают, что в Java нет невиртуальных функций...
. На самом деле я когда вижу в исходниках слово private, мне часто уже хочется сказать авторам всё, что я о них думаю. Хотя у них тоже были причины запретить использовать свой интересный код, который в этом случае приходится повторно использовать методом Copy-Paste.---
Это ещё ладно, бывают люди, которые считают, что в Java нет невиртуальных функций...
Это не то же самое.
Private-код скорее всего работал с данными, к которым у тебя не должно быть доступа.
Или, например, в следующей версии их кода может не оказаться этого метода.
Private-код скорее всего работал с данными, к которым у тебя не должно быть доступа.
Или, например, в следующей версии их кода может не оказаться этого метода.
Спасибо, я в курсе, но такая злоба берёт когда даже при всём богатстве Eclipse SDK API (ИМХО, он сопоставим с API целой операционной системы понимаешь, что это только вершина айсберга. Много вкусностей запрятано в пакеты *.internal.*, а в тех, что доступны, много всего интересного в private-методах. И ты хочешь проорать автору: "Ну почему, почему ты не сделал его public?! Или хотя бы protected, чтобы я мог отнаследовать?! Зависимости ведь минимальные... жадина!"
Cчитаю, что internal очень полезная штука, особенно когда пишешь свой API, который начинается с интерфейсов и соответственно всякие методы и алгоритмы будут оперировать в терминах интерфейсов. Часто нужно будет алгоритма производить различные действия над объектом в зависимости от реализации интерфейса. Удобно добавить для этого метод в интерфейс, который будет перегружаться различными реализациями. Но этот метод служебный, страшный и так далее, короче не хочется пугать чела, который будет смотреть на базовые интерфейсы, где основные функции будут теряться среди служебных.
В Джава вроде есть internal -- когда не ставится никакой модификатор видимости. Но вот только пользы от этого мало, т.к. обычно внутри пакета классы группируются в подпакеты исходя из логических соображений. Поэтому часто структуры и алгоритмы будут в разных пакетах. Наверно подход в Джава чем-то проще, чем в дотНЕТ, но тем самым в определенной степени и хуже. Вроде в дотНЕТ даже обещают friend assemblies добавить..
В Джава вроде есть internal -- когда не ставится никакой модификатор видимости. Но вот только пользы от этого мало, т.к. обычно внутри пакета классы группируются в подпакеты исходя из логических соображений. Поэтому часто структуры и алгоритмы будут в разных пакетах. Наверно подход в Джава чем-то проще, чем в дотНЕТ, но тем самым в определенной степени и хуже. Вроде в дотНЕТ даже обещают friend assemblies добавить..
Оставить комментарий
6yrop
как распределять классы по пакетам?В .NET всё понятно. Есть пространства имен, которые используются только для формирования имени класса. Есть сборки, которые используются для "физического" хранения классов. Сборка представляет собой единицу функциональности. Можно скрывать элементы внутри сборки, используя модификатор internal.
Пакеты в Java это что-то среднее между пространствами имен и сборками. Чем же руководствоваться при распределении классов по пакетам?
Еще странно то, что нет модификатора, который разрешает доступ только наследникам. (protected элементы видны классам того же пакеты).