Инкапсуляция в возрасте платформ

Я не соглашаюсь с Вашим заключением. Существует много хороших способов инкапсулировать в c# со всеми вышеупомянутыми технологиями, поддержать хорошие методы кодирования программного обеспечения. Я также сказал бы, что это зависит, на чьей технологической демонстрации Вы смотрите на, но в конце это сводится к сокращению пространства состояний Ваших объектов так, чтобы можно было удостовериться, что они содержат свои инварианты в любом случае.

Возьмите объектные реляционные платформы; большинство из них позволяет Вам указывать, как они собираются гидратировать объекты; NHibernate, например, позволяет Вам, так скажите access="property" или access="field.camelcase" и подобный. Это позволяет Вам инкапсулировать свои свойства.

Внедрение зависимости работает над другими типами, которые Вы имеете, главным образом те, которые не являются объектами, даже при том, что можно объединить AOP+ORM+IOC некоторыми очень хорошими способами улучшить положение этих дел. МОК часто используется от слоев выше Ваших доменных объектов, если Вы создаете управляемое данными приложение, которое я предполагаю, что Вы, так как Вы говорите о ORMs.

Они ("они" являющийся приложением и доменными сервисами и другими внутренними классами к программе) выставляют свои зависимости, но на самом деле могут инкапсулироваться и тестироваться в еще лучшей изоляции, чем ранее начиная с парадигм design-by-contract/design-by-interface, который Вы часто используете при насмешке зависимостей в основанном на насмешке тестировании (в сочетании с МОК), переместит Вас к классу поскольку компонент "семантика". Я имею в виду: каждый класс при создании с помощью вышеупомянутого будет лучше инкапсулироваться.

Обновленный для urig: Это сохраняется и для выставляющий конкретные зависимости и для выставляющий интерфейсы. Сначала об интерфейсах: То, на что я намекал выше, было то, что сервисы и другие классы приложений, которые имеют зависимости, могут с ООП зависеть от контрактов/интерфейсов, а не определенных реализаций. В C/C++ и более старых языках там не были интерфейсные и абстрактные классы, может только пойти до сих пор. Интерфейсы позволяют Вам связывать различные экземпляры во время выполнения с тем же интерфейсом, не имея необходимость волноваться об утечке внутреннего состояния, которое является тем, от чего Вы пытаетесь убежать при абстракции и инкапсуляции. С абстрактными классами можно все еще обеспечить реализацию класса, просто что Вы не можете инстанцировать ее, но наследники все еще должны знать об инвариантах в Вашей реализации, и это может смешать работоспособное состояние.

Во-вторых, о реальных классах как свойства: необходимо быть осторожными о том, какие типы типов ;) Вы выставляете как свойства. Скажите, что у Вас есть Список в Вашем экземпляре; затем не выставляйте IList как свойство; это, вероятно, протечет, и Вы не можете гарантировать, что потребители интерфейса не добавляют вещи или удаляют вещи, от которых Вы зависите; вместо этого выставьте что-то как IEnumerable и возвратите копию Списка, или еще лучше, сделайте это как метод: общедоступный IEnumerable MyCollection {добирается {возвращают _List. Перечисление (); }} и Вы на 100% несомненно сможете получить и производительность и инкапсуляцию. Никто не может добавить или удалить к этому IEnumerable, и Вы все еще не должны выполнять дорогостоящую копию массива. Соответствующий вспомогательный метод:

static class Ext {
    public static IEnumerable<T> Enum<T>(this IEnumerable<T> inner) {
        foreach (var item in inner) yield return item;
    }
}

Таким образом, в то время как Вы не можете вложить 100%-ю инкапсуляцию, говорят, что перегруженное создание равняется операторам/методу, можно быть рядом с открытыми интерфейсами.

Можно также использовать новые функции.Net 4.0, основывался на Spec# для проверки контрактов, я говорил о вышеупомянутом.

Сериализация всегда будет там и была в течение долгого времени. Ранее, перед интернет-областью это использовалось для того, чтобы сохранить Ваш граф объектов на диск для более позднего извлечения, теперь это используется в веб-сервисах в семантике копии и когда передающие данные к, например, браузер. Это не обязательно повреждает инкапсуляцию при помещении нескольких [Несериализированных] атрибутов или эквивалентов на корректных полях.

Объектные инициализаторы не являются тем же как конструкторами, они - просто способ свернуть несколько строк кода. Значения/экземпляры в {} не будут присвоены, пока все Ваши конструкторы не работали, так же в принципе это все равно как не использует объектные инициализаторы.

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