Наследование агрегация композиция

Наследование агрегация композиция

Подскажите, пожалуйста, в чем разница между черным и белыми ромбами при наследовании класса в диаграммах UML?

Незакрашенный ромб — отношение аггрегации. Агрегация — это отношение целое часть.

  • агрегат ( MyEntityClass ) может существовать как независимо от частей ( MyClass ), так и вместе с ними;
  • части могут существовать независимо от агрегата
  • агрегат является в некотором смысле неполным в случае отсутствия частей
  • части могут принадлежать одновременно нескольким агрегатам

Закрашенный ромб — композиция. Композиция — это строгая форма агрегации.

  • Одновременно части ( MyClass2 ) могут принадлежать только одному композиту ( MyEntityClass ) — совместное владение частями невозможно.
  • композит обладает исключительной ответственностью за все свои части; это значит что он отвечает за их создание и уничтожение
  • композит может высвобождать части, передавая ответственность за них другому объекту
  • в случае уничтожения композита он должен уничтожить все свои части или передать ответственность за них другому объекту.

Ключевое различие композиции и агрегации в том что в композиции у частей нет независимой жизни вне целого (композита) Более того в композиции каждая часть принадлежит максимум одному и только одному целому (композиту), тогда как при агрегации часть может совместно использоваться несколькими целыми(агрегатами).

Д. Арлоу, А. Нейштадт — «UML2 и унифицированный процесс»

Наследование агрегация композиция

Объясните по-человечески, желательно на примере, в чём заключается разница между композицией и наследованием? Читаю Философия Java Эккеля, застрял на этой теме, объясняется все вроде бы хорошо, но я не понял.

Как и всем разработчикам, мне часто приходилось читать и слышать утверждение, что «композиция всегда лучше наследования». Наверное, даже слишком часто. Однако я не склонен принимать что-либо на веру, поэтому давайте разберёмся, так ли это.

Итак, какие же преимущества есть у композиции перед наследованием?

  1. Нет конфликта имён, возможного при наследовании.
  2. Возможность смены агрегируемого объекта в runtime.
  3. Полная замена агрегируемого объекта в классах, производных от класса, включающего агрегируемый объект.

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

Если рассматривать, например, C#, не поддерживающий множественное наследование, но позволяющий наследовать от множества интерфейсов и создавать методы расширения для этих интерфейсов, то можно выделить ещё два плюса (речь в данном случае может идти только о поведениях (алгоритмах) в рамках паттерна «Стратегия»): 4. Агрегируемое поведение (алгоритм) может включать в себя другие объекты. Что в частности позволяет переиспользовать посредством агрегации другое поведение. 5. При агрегации есть возможность скрыть определённую часть реализации, а также исходные параметры, необходимые поведению, посредством передачи их через конструктор (при наследовании поведению придётся запрашивать их через методы/свойства собственного интерфейса).

Но как же минусы? Неужели их нет?

  1. Итак, если нам необходима возможность смены поведения извне, то композиция, по сравнению с наследованием, имеет принципиально другой тип отношений между объектом поведения и объектом, его использующим. Если при наследовании от абстрактного поведения мы имеем отношение 1:1, то при агрегации и возможности установки поведения извне мы получаем отношение 1:many. Т.е. один и тот же объект поведения может использоваться несколькими объектами-владельцами. Это порождает проблемы с общим для нескольких таких объектов-владельцев состоянием поведения.

Разрешить эту ситуацию можно, запретив установку поведения извне или доверив его, например, generic-методу: void SetBehavior() запретив тем самым создание поведения кем-либо, кроме объекта-владельца. Однако мы не можем запретить использовать поведение «где-то ещё». В языках без сборщика мусора (GC) это порождает понятные проблемы. Конечно, в таких языках можно неправомерно обратиться по ссылке и на сам объект-владелец, но, раздавая отделённые объекты поведения направо и налево, мы получаем в разы больше шансов получить exception.

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

В таком случае, нам придётся или передавать в такой код нетипизированный объект (как object или void*), или создавать дополнительный интерфейс для объекта-владельца (некий IBehaviorOwner), или хранить в поведении циклическую ссылку на объект-владелец. Понятно, что каждый из этих вариантов имеет свои минусы и ещё больше усложняет код. Более того, различные типы поведений могут зависеть друг от друга (и в это вполне допустимо, особенно если они находятся в некоем закрытом самодостаточном модуле).

  1. Ну и последний минус — это конечно же производительность. Если объектов-владельцев достаточно много, то создание и уничтожение вместо одного объекта двух или более может не остаться незамеченным.

Получается, что утверждение «композиция всегда лучше наследования» в ряде случаев спорно и не должно являться догмой. Особенно это касается языков, позволяющих множественное наследование и не имеющих GC. Если в какой-либо ситуации перечисленные выше плюсы не важны, и заранее известно, что при работе с определёнными типами у вас не будет возможности их использовать, стоит всё-таки рассмотреть вариант наследования.

Наследование агрегация композиция

Проектирую доменную область сервиса для тестирования. В различных тестированиях будут принимать участие различные категории участников: ученик школы, учитель школы и бывший ученик школы, который является бывшим учеником данной школы. Необходимо отметить, что бывший ученик школы при тестировании привязывается в целом к школе, класса у него нет (он ведь уже отучился).

В сети часто можно встреть утверждение, что необходимо по возможности использовать композицию нежели наследование. Но также есть другое утверждение, с которым я больше согласен и это: необходимо просто понять какая из двух связей существует is (наследование) или has (композиция/агрегация).

Вопрос в целом звучит так:

1. Правильно ли я сделал, в первую очередь с концептуальной точки зрение, что выбрал тут наследование, а не композицию?

А подвопрос такой:

1.1) Эти сущности будут проецироваться на таблицу реляционной базы данных и мне необходимы поля AddedDate — время добавления записи и DataSourceName — наименование источника данных (при добавлении через ЛК это будет название логина). Но с концептуальной точки зрения разве правильно звучит утверждение «Я участник тестирования и у меня есть свойство «ВремяДобавленияМеняВбазуДанных»»? Разве можно подобные свойства ставить на ряду с такими как Фамилия и Имя. Быть может тут какой-то паттерн необходим? Каких знаний в проектировании мне не хватает?

Смотрите еще:  Перевод купля и продажа

1) Если говорить о сигнальных английских глаголах связанных с отношениями между классами, то Composition — это has a . , а вот Aggregation — это part of . .

2) Надо отдавать себе отчет в том, что совет отдавать предпочтение композиции перед наследованием вполне себе оправдан из-за того, что зачастую программист начинает построение иерархической системы из классов, которая порой ничем не оправдана кроме как желанием поменьше написать повторяющихся названий свойств, например «. О! Id — создам-ка я класс Entity . » и так далее. В результате такого подхода возникает иерархическая система из классов, которая в принципе может быть не нужна в приложении, а может даже и очень сильно мешать в дальнейшем. К наследованию лучше прибегать в случае если вы начинаете проектирование с абстракций, т.е. начинаете программировать с интерфейсов и абстрактных классов, хотя в случае интерфейсов наследование называется реализацией, но вы меня понимаете.

3) Конкретно в вашем случае, на мой скромный взгляд, у вас есть сущности: Человек , Опыт и связанная с ним ТипОпыта — это буквально словарные названия (Ученик, Учитель и т.д.), которые хранятся в отдельной таблице БД. Сущность Опыт должна иметь соотв. свойства (ДатаНачала, ДатаОкончания, ТипОпыта, Стаж, ну и проч. что надо), таким образом по таблице Опыт в БД можно отследить весь учебный и трудовой путь нужного человека.

А вот это ваше наследование никуда не годится.

4) «. AddedDate — время добавления записи и DataSourceName — наименование источника данных. » такие вещи выносят в отдельные таблицы в БД с отношением «один-к-одному». Т.е. есть таблица «Человек» а к ней «прицепом» отдельная таблица «ЧеловекСекретное», в которой будут хранится логин, пароль и проч. служебная инфа.

Наследование агрегация композиция

Нередко случается, что решив разобраться с какой-то новой темой, понятием, инструментом программирования, я читаю одну за другой статьи на различных сайтах в интернете. И, если тема сложная, то эти статьи могут не на шаг не приблизить меня к понимаю. И вдруг встречается статья, которая моментально дает озарение и все паззлы складываются воедино. Трудно определить, что отличает такую статью от других. Правильно подобранные слова, оптимальная логика изложения или же просто более релевантный пример. Я не претендую на то, что моя статься окажется новым словом в C# или же лучшей обучающей статьей. Но, возможно для кого-то она станет именно той, которая позволит разобраться, запомнить и начать правильно применять те понятия, о которых пойдет речь.

В объектно-ориентированных языках программирования существует три способа организации взаимодействия между классами. Наследование — это когда класс-наследник имеет все поля и методы родительского класса, и, как правило, добавляет какой-то новый функционал или/и поля. Наследование описывается словом «является». Легковой автомобиль является автомобилем. Вполне естественно, если он будет его наследником.

Ассоциация – это когда один класс включает в себя другой класс в качестве одного из полей. Ассоциация описывается словом «имеет». Автомобиль имеет двигатель. Вполне естественно, что он не будет являться наследником двигателя (хотя такая архитектура тоже возможна в некоторых ситуациях).

Выделяют два частных случая ассоциации: композицию и агрегацию.

Композиция – это когда двигатель не существует отдельно от автомобиля. Он создается при создании автомобиля и полностью управляется автомобилем. В типичном примере, экземпляр двигателя будет создаваться в конструкторе автомобиля.

Агрегация – это когда экземпляр двигателя создается где-то в другом месте кода, и передается в конструктор автомобиля в качестве параметра.

Хотя ведутся дискуссии о преимуществах того или иного способа организации взаимодействия между классами, какого-либо абстрактного правила не существует. Разработчик выбирает тот или иной путь основываясь на элементарной логике (“является” или “имеет”), но также принимает во внимание возможности и ограничения, которые дают и накладывают эти способы. Для того, чтобы увидеть эти возможности и ограничения, я попытался написать пример. Достаточно простой, чтобы код оставался компактным, но и достаточно развитый, чтобы в рамках одной программы можно было применить все три способа. И, главное, я попытался сделать этот пример как можно менее абстрактным – все объекты и экземпляры понятны и осязаемы.

Напишем простенькую игру – танковый бой. Играют два танка. Они поочередно стреляют и проигрывает тот, здоровье которого упало до нуля. В игре будут различные типы снарядов и брони. Для того, чтобы нанести урон необходимо во-первых, попасть по танку противника, во-вторых, пробить его броню. Если броня не пробита, урон не наносится. Логика игры построена на принципе «камень-ножницы-бумага»: то есть броня одного типа хорошо противостоит снарядам определенного типа, но плохо держит другие снаряды. Кроме того, снаряды, которые хорошо пробивают броню, наносят малый «заброневой» урон, и, напротив, наиболее «летальные» снаряды имеют меньше шансов пробить броню.

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

Сделаем также конструктор для пушки:

Сделаем метод для получения калибра из других классов:

Помните, что для поражения цели должно произойти две вещи: попадание в цель и пробитие брони? Так вот, пушка будет отвечать за первую из них: попадание. Поэтому делаем булевый метод IsOnTarget, который принимает случайную величину (dice) и возвращает результат: попали или нет:

Целиком класс пушки выглядит следующим образом:

Теперь сделаем снаряды – это наиболее очевидный случай для применения наследования, но и агрегацию в нем тоже применим. Любой снаряд имеет свои особенности. Просто неких гипотетических снарядов не бывает. Поэтому класс делаем абстрактным. Делаем ему строковое поле «тип».

Снаряды делают для пушек. Для определенных пушек. Снаряд одного калибра не выстрелит из пушки другого калибра. Поэтому добавляем снаряду поле-ссылку на экземпляр пушки. Делаем конструктор.

Здесь мы применили агрегацию. Где-то будет создана пушка. Потом к этой пушке будут создаваться снаряды, которые имеют указатель на пушку.

Конкретные типы снарядов будут наследниками абстрактного снаряда. Наследники могут просто наследовать методы родителя, но могут и быть переопределены, то есть работать не так, как родительский метод. Но мы точно знаем, что любой снаряд должен иметь ряд методов. Любой снаряд должен наносить урон. Метод GetDamage просто возвращает калибр, умноженный на три. В общем случае, урон снаряда зависит от калибра. Но этот метод будет переопределяться в дочерних классах (помним, что снаряды, которые хорошо пробивают броню, как правило наносят меньший «заброневой» урон. Чтобы иметь возможность переопределить метод в дочернем классе, используем слово virtual.

Смотрите еще:  Транспортный налог в хабаровске в 2019 году

Любой снаряд должен пробивать (или по крайней мере пытаться пробить) броню. В общем случае способность пробивать броню также зависит от калибра (ну, и еще от многого – начальной скорости, например, но мы не будем усложнять). Поэтому, метод возвращает калибр. То есть, грубо говоря, снаряд может пробить броню, равную по толщине своему калибру. Этот метод не будет переопределяться в дочерних классах.

Кроме того, для удобной отладки и организации консольного вывода, имеет смысл добавить метод ToString, который просто позволит нам увидеть, что это за снаряд и какого калибра:

Теперь сделаем разные типы снарядов, которые будут наследовать абстрактный снаряд: фугасный, кумулятивный, подкалиберный. Фугасный наносит самый большой урон, кумулятивный – меньше, подкалиберный – еще меньше. Дочерние классы не имеют полей и вызывают конструктор базового снаряда, передавая ему пушку, и строковый тип. В дочернем классе переопределяется метод GetDamage() – вносятся коэффициенты, которые увеличат или уменьшат урон по сравнению с дефолтным.

Фугасный (дефолтный урон):

Кумулятивный (дефолтный урон х 0.6):

Подкалиберный (дефолтный урон х 0.3):

Обратите внимание, что в переопределенном методе GetDamage вызывается и метод базового класса. То есть, переопределив метод, мы также сохраняем возможность обратиться к дефолтному методу, использовав ключевое слово base).

Итак, для снарядов мы применили и агрегацию (пушка в базовом классе), и наследование.
Создадим теперь броню для танка. Здесь применим только наследование. Любая броня имеет толщину. Поэтому абстрактный класс брони будет иметь поле thickness, и строковое поле type, которое будет определятся при создании дочерних классов.

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

А пробита они или нет – зависит от того, какой прилетел снаряд: в дефолтном случае какого калибра. Поэтому метод принимает экземпляр снаряда и возвращает булевый результат: пробита или нет. Создадим несколько типов брони – наследников абстрактной брони. Приведу код лишь одного типа – логика примерно такая же, как и в снарядах. Гомогенная броня хорошо держит фугасный снаряд, но плохо – подкалиберный. Поэтому, если прилетел подкалиберный снаряд, который имеет высокую бронепробиваемость, то в вычислениях наша броня как-бы становится тоньше. И так далее: каждый вид брони имеет свой набор коэфициентов устойчивости к тому или иному снаряду.

Здесь мы используем одно из чудес, которые дает полиморфизм. Метод принимает любой снаряд. В сигнатуре указан базовый класс, а не дочерние. Но внутри метода, мы можем увидеть, что за снаряд прилетел – какого типа. И в зависимости от этого, реализуем ту или иную логику. Если бы мы не применили наследование для снарядов, а сделали просто три уникальных класса типов снарядов, то проверку пробития брони пришлось бы организовывать иначе. Нам пришлось бы писать столько перегруженных методов, сколько типов снарядов у нас в игре, и вызывать один из них в зависимости от того, какой снаряд прилетел. Это тоже было бы довольно изящно, но не относится к теме данной статьи.

Теперь у нас все готово для создания танка. В танке не будет наследования, но будет композиция и агрегация. Разумеется, у танка будет название. У танка будет пушка (агрегация). Для нашей игры сделаем допущение, что танк может «переодевать» броню перед каждым ходом – выбрать тот или иной тип брони. Для этого, у танка будет список типов брони. У танка будет боеукладка – список снарядов, который будет наполнен снарядами, созданными в конструкторе танка (композиция!). У танка будет здоровье (уменьшается при попадании в него), и, у танка будет текущая выбранная броня и текущий выбранный снаряд.

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

Теперь конструктор танка выглядит вот таким образом:

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

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

Как я упомянул в начале, в этом примере я старался максимально уйти от абстрактных понятий, которые нужно все время держать в голове. Поэтому каждый экземпляр снаряда у нас равен физическому снаряду, который положили в боеукладку перед боем. Следовательно, снаряды могут закончится в самый неподходящий момент!

Здесь – поподробнее. Во-первых, есть проверка заряжена ли пушка. Во-вторых, снаряд, который вылетел из ствола, уже не существует для данного танка, его уже нет ни в пушке, ни в боеукладке. Но физически он еще существует – летит по направлению к цели. И если попадет, будет участвовать в вычислении пробития брони и урона цели. Поэтому, мы сохраняем этот снаряд в новой переменной: Ammo firedAmmo. Поскольку на следующей же строке данный снаряд перестанет существовать для данного танка, придется использовать интерфейс IClonable для базового класса снаряда:

Этот интерфейс требует реализации метода Clone(). Вот она:

Теперь все супер реалистично: при выстреле генерируется dice, пушка рассчитывает попадание своим методом IsOnTarget, и, если попадание есть, то метод Shoot вернет экземпляр снаряда, а если промах – то вернет null.

Последний метод танка – его поведение при попадании вражеского снаряда:

Снова полиморфизм во всей красе. К нам прилетает снаряд. Любой. Исходя из выбранной брони и типа снаряда, вычисляется пробита броня или нет. Если пробита, то вызывается метод конкретного типа снаряда GetDamage().

Смотрите еще:  Доверенность от директора на представление интересов образец

Все готово. Остается только написать консольный (или неконсольный) вывод, в котором будет обеспечен пользовательский интерфейс и в цикле реализованы поочередные ходы игроков.

Подведем итоги. Мы написали программу, в которой использовали наследование, композицию и агрегацию, надеюсь, поняли и запомнили различия. Активно задействовали возможности полиморфизма, во-первых, когда любые экземпляры дочерних классов можно сложить в список, имеющий тип данных родительского, а во-вторых, создавая методы, которые принимают в качестве параметра родительский экземпляр, но внутри которых вызываются методы дочернего. По ходу текста я упоминал возможные альтернативные реализации – замену наследования на агрегацию, и, универсального рецепта тут нет. В нашей реализации наследование дало нам легкость добавления новых деталей в игру. Например, чтобы добавить новый тип снаряда нам нужно лишь:

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

Аналогично, чтобы добавить еще одну разновидность брони, требуется лишь описать эту разновидность и добавить пункт в пользовательский интерфейс. Модифицировать другие классы или методы не требуется.

Ниже – приведена диаграмма наших классов.

В финальном коде игры все «магические числа», которые использовались в тексте, вынесены в отдельный статический класс Config. К публичным полям статического класса мы можем обратиться из любого фрагмента нашего кода и его экземпляр не нужно (и невозможно) создавать. Вот так он выглядит:

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

Наследование агрегация композиция

Работаю с Selenium, хочу что бы класс Parser наследовал объект driver класса родителя Client.

Дело в том что в такой конструкции создается новый объект driver.(новое окно в хроме на деле). А я хочу использовать именно тот уже созданный до этого объект. Например рабочий вариант кода такой:

Но мне нужно передавать разные прокси при создании объекта класса Client, а так же это просто не красиво и не правильно. Пожалуйста поясните за наследование в этом конкретном случае и как мне решить проблему грамотно. Спасибо!

Вы неверно поняли зачем нужно наследование. То, как вы хотите его использовать, это не ООП. Client и Parser это разные бизнес сущности, не следует одно наследовать от другого. Client — это интерфейс браузера, Parser — непосредственно объект, который пользуется этим интерфейсом, чтобы получить какую-то информацию из браузера.

Логичнее сделать так:

Если хотите использовать наследование, то можно реализовать базовый класс Client , и от него наследовать клиенты для конкретных браузеров: ClientChrome , ClientFirefox . В базовом можно хранить реализацию прокси (так как эта штука универсальная), а в дочерних создавать уже драйвера

Наследование агрегация композиция

Агрегация и композиция. C#

Агрегация и композиция

В предыдущей статье я рассказывал о том, как можно заменить наследование используя композицию, если главное что Вам нужно — это избежать повторного написания некого кода. К примеру, Вам доступен какой-то класс (причем, его разработчиком можете быть даже не Вы), функциональность которого Вы хотите расширить. Вы можете написать класс-наследник (если исходный класс не помечен как sealed, о том что такое sealed-классы, я рассказывал в этой статье), получив при этом ряд «побочек», или воспользоваться принципом композиции. Но не одной композицией можно решать подобные проблемы. Есть еще так называемая агрегация. И в этой статье, я хочу вкратце рассказать о том, что же такое агрегация и в чем её отличие от композиции.

И так, скажу сразу, что агрегация и композиция очень близкие понятия! В обоих случаях есть объемлющий объект (объект-контейнер, если хотите) и объект-содержимое (этого контейнера). Объект-содержимое, как привило является полем объекта-контейнера. Но в тоже время, между композицией и агрегацией есть одно важное отличие: при использовании композиции, объект-содержимое не может существовать без своего контейнера, а случае агрегации, такое вполне возможно. Да еще и при использовании агрегации, объект-содержимое может принадлежать даже нескольким контейнерам (но тут нужно быть осторожным) или у одного объекта-контейнера, в течении «жизни», может быть разное содержимое (причем, агрегация позволяет использовать даже содержимое разных типов одном у тому же контейнеру).

На самом деле, можно сказать, что композиция — это частный, более строгий, вариант агрегации.

А теперь, я покажу как на практике выглядит агрегирование (использование композиции я показывал в предыдущей статье, ссылку на которую приводил выше):

Как можно заметить, в отличии от композиции, в данном примере, мы не создаем объект типа «Sender» внутри класса «SenderM». Такой объект будет создаваться за пределами класса, а конструктор типа «SenderM» будет принимать ссылку на этот объект. Вот в этом и есть главное отличие агрегирования от композиции.

Как видите, использовать такие классы тоже несложно…

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Похожие статьи:

  • Оформить в кредит стиральную машину Рассрочка 0% на покупку стиральной машины Стиральная машина относится к классу необходимой бытовой техники, которая должна быть в каждой квартире. Однако не каждый имеет возможность […]
  • Нотариус до 19-00 москва Нотариус города Москвы Лысякова Ольга Сергеевна Добро пожаловать на официальный сайт нотариуса города Москвы Лысяковой Ольги Сергеевны! Благодарю всех, кто решил воспользоваться […]
  • Как оформить отзыв претензии Как правильно отозвать претензию? В некоторых случаях требуется отзыв претензии, осуществляется он в любое время, но только лицом, написавшим претензию. Для этого необходимо написать […]
  • Налог с имущества 5 лет Сколько нужно владеть недвижимостью, чтобы продать ее без налога? Если жилье приобретено до 1 января 2016 года (любым способом), то применяются "старые правила" (действовавшие до последних […]
  • Банк грозится подать в суд за невыплату кредита Если Сбербанк подал в суд за неуплату кредита Каждый заемщик стремится скорее погасить обязательства, но иногда под властью обстоятельств это становится невозможным. Столкнувшись с […]
  • Договор дарения автомобиля между близкими родственниками образец Как оформить дарственную на машину Договор дарения — популярный способов передать право собственности на автомобиль. В статье рассмотрим, как правильно оформляется дарственная на машину и […]
Перспектива. 2019. Все права защищены.