Почему делает каждый класс в.NET, наследовались Объекту?
Ну, моя компания не пошла с TDD или Поблочным тестированием. Честно говоря, мы не уверены, как сделать это. Мы можем, очевидно, сделать это для глупых функций как CapitalizeString (), и т.д., но мы не знаем, как сделать это для очень сложных систем со сложными объектами. Кроме того, у большинства людей, у которых взяли интервью, есть или нулевой опыт или ограниченный опыт. Кажется, что Поблочное тестирование является большим от ТАК толпа, но не особенно большим в доступном workpool.
TDD является отдельной темой. Мы нравственно настроены против TDD. Мы не кодеры ковбоя, но мы действительно полагаем, что это останавливает рост креативности и гибкости в проекте. Кроме того, имея кодер, который записал, функция поблочного тестирования не имеет никакого смысла. Когда я делаю что-то, я кодирую ко всем пограничным случаям, о которых я могу думать. То, в чем я нуждаюсь, является другим мозгом для поиска вещей, которые я, возможно, пропустил. У нас нет этого. Команды являются малочисленными и автономными.
Короче говоря, мы не верим в TDD, но мы хотели бы к Модульному тесту. У нас просто нет опыта сделать так, и мы не можем найти его легко.
9 ответов
Некоторые причины, по которым многие / большинство из них:
Для предоставления общих элементов, таких как Equals, Finalize, GetHashCode, ToString ....
Чтобы помочь с боксом ....
Потому что это в спецификации :
8.9.9 Наследование типа объекта
С единственное исключение System.Object, которое не наследуется ни от одного другого объекта type, все типы объектов должны либо явно или неявно заявлять поддержка (т.е. наследование от) ровно один другой тип объекта. В График отношения наследования должен сформировать однокорневое дерево с System.Object в основании; т.е. все типы объектов в конечном итоге наследуются от тип System.Object.
Этот подход к проектированию дает несколько преимуществ .
Вопрос предполагает ложь. Им не нужен общий базовый тип. Этот выбор был сделан не по необходимости. Это было сделано из желания предоставить покупателю максимальную выгоду.
При разработке системы типов или чего-либо еще в этом отношении иногда вы достигаете точки принятия решения - вы должны решить, X или нет. Обычный базовый тип или нет общего базового типа. Когда это происходит, вы взвешиваете затраты и выгоды от X, чтобы определить чистую стоимость, а затем вы взвешиваете затраты и выгоды от не-X, чтобы определить чистую стоимость, и выбираете тот, который был более ценным. Выгоды от наличия общего базового типа перевешивают затраты, а чистая прибыль, полученная таким образом, больше, чем чистая выгода от отсутствия общего базового типа. Поэтому мы выбрали общий базовый тип.
Это довольно расплывчатый ответ. Если вы хотите получить более конкретный ответ, попробуйте задать более конкретный вопрос.
Я думаю, в основном для того, чтобы иметь тип для ссылки на любой объект. Аргумент типа объект может быть примитивным типом, структурой, ссылочным типом, чем угодно. Важно иметь такой тип.
Кроме того, есть несколько общих членов, которые реализуются каждым типом, например Equals, ToString, GetHashCode. Это действительно может быть общий интерфейс, но тогда вы не унаследуете реализацию по умолчанию.
Каждый объект в .NET имеет общие свойства и методы. Однако затем они делятся на две категории: типы значений и ссылочные типы. Типы значений (например, int) хранятся в стеке, ссылочные типы (например, ваш пользовательский класс) хранятся в куче. Типы ссылок хранят ссылку на фактические данные (которые находятся в куче). Типы значений напрямую содержат свои данные.
Вы можете прочитать больше на MSDN:
Java и C # применили к этому другой подход. В основном это связано с производительностью.
Если вы представляете, что каждый объект может иметь значение NULL, тогда это должен быть указатель на значение, которое можно заменить указателем на NULL. Теперь это означает, что для каждого объекта вам нужен по крайней мере указатель и кусок памяти для хранения значения.
В Java существует концепция примитивного значения, которое НЕ является объектом. У него нет указателя, и он не допускает значения NULL. Это ломает парадигму ООП, но с точки зрения производительности имеет смысл.
C # (или, точнее, CLR + BCL) попытался найти хороший компромисс, производные ReferenceType и ValueType. Все, что унаследовано от ValueType, обрабатывается как примитивы для среды CLR, без ссылки на объект. Однако это значение по-прежнему можно рассматривать как объект с помощью бокса, позволяя вам иметь преимущества в производительности примитивных типов, но позволяя рассматривать все как объект.
Настоящее ключевое различие между этими вещами заключается в семантике передачи параметров методам. Если все является объектом, то вы передаете ссылки на объект, т.е. объект можно изменить, передав его методу. Примитивы и типы значений C # передаются по значению, поэтому они эффективно копируются в вызов метода, а исходное значение не изменяется.
Это стандартная история разработки. Попытайтесь сначала сделать это правильно, а затем посмотрите, сможете ли вы оптимизировать его позже, когда увидите узкие места. Семантика передачи по значению также позволяет предотвратить ошибки кодирования из-за изменчивости. (например, передача класса и структуры в C #)
Настоящее ключевое различие между этими вещами заключается в семантике передачи параметров методам. Если все является объектом, то вы передаете ссылки на объект, т.е. объект можно изменить, передав его методу. Примитивы и типы значений C # передаются по значению, поэтому они эффективно копируются в вызов метода, а исходное значение не изменяется.
Это стандартная история разработки. Попытайтесь сначала сделать это правильно, а затем посмотрите, сможете ли вы оптимизировать его позже, когда увидите узкие места. Семантика передачи по значению также позволяет предотвратить ошибки кодирования из-за изменчивости. (например, передача класса и структуры в C #)
Настоящее ключевое различие между этими вещами заключается в семантике передачи параметров методам. Если все является объектом, то вы передаете ссылки на объект, то есть объект можно изменить, передав его методу. Примитивы и типы значений C # передаются по значению, поэтому они эффективно копируются в вызов метода, а исходное значение не изменяется.
Это стандартная история разработки. Попробуйте сначала сделать это правильно, а затем посмотрите, сможете ли вы оптимизировать его позже, когда увидите узкие места. Семантика передачи по значению также позволяет предотвратить ошибки кодирования из-за изменчивости. (например, передача класса и структуры в C #)
e объект можно изменить, передав его методу. Примитивы и типы значений C # передаются по значению, поэтому они эффективно копируются в вызов метода, а исходное значение не изменяется.Это стандартная история разработки. Попытайтесь сначала сделать это правильно, а затем посмотрите, сможете ли вы оптимизировать его позже, когда увидите узкие места. Семантика передачи по значению также позволяет предотвратить ошибки кодирования из-за изменчивости. (например, передача класса и структуры в C #)
e объект можно изменить, передав его методу. Примитивы и типы значений C # передаются по значению, поэтому они эффективно копируются в вызов метода, а исходное значение не изменяется.Это стандартная история разработки. Попытайтесь сначала сделать это правильно, а затем посмотрите, сможете ли вы оптимизировать его позже, когда увидите узкие места. Семантика передачи по значению также позволяет предотвратить ошибки кодирования из-за изменчивости. (например, передача класса и структуры в C #)
Семантика передачи по значению также позволяет предотвратить ошибки кодирования из-за изменчивости. (например, передача класса и структуры в C #) Семантика передачи по значению также позволяет предотвратить ошибки кодирования из-за изменчивости. (например, передача класса и структуры в C #)В качестве дополнения к другим «ответам» структура - это тип значения, который также наследуется от объекта.
Возможно, Ответ заключается в том, что предполагается, что мы программируем объектно-ориентированный стиль / парадигму? Мяч - это объект. Меч - это объект. Сотрудник - это объект. Заказ на поставку - это объект.
Некоторые компании разрабатывают свои приложения .NET (или Java, или Ruby, или PHP) так, чтобы они унаследовали от общего базового класса, чтобы все они могли обрабатываться одинаково в их системе. Если я правильно помню из своих старых дней Java ... все EJB-компоненты используют один и тот же базовый класс, поэтому ими можно управлять и идентифицировать единообразно.