Здравствуйте, как поживаете?
Давайте поговорим сегодня о Законе Деметры. Это модель объектной ориентации, которая помогает нам снизить нашу связь, уменьшить влияние на обслуживание и повысить адаптивность наших систем.
Чем полезны эти «странные» слова? Если вам нужно выполнить какое-либо обслуживание в вашем приложении, это окажет меньшее влияние; ваши классы будут знать только те классы, которые должны знать, а изменения кода будут происходить быстрее и с меньшим воздействием на вашу систему.
Просто преимущества в законе Деметры, верно? Позвольте нам успокоиться; в конце этого поста мы увидим недостатки этого подхода.
Если вы хотите увидеть еще один пост об ОО, просто нажмите на ссылку: « Скажи, не спрашивай! »
Посмотрите на код ниже, что мы можем сделать, чтобы сделать его лучше?
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
|
package com;public class Main { public static void main(String[] args) { IAddress address = new Address(); address.setName("01"); address.setZipCode("000001"); IHouse house = new House(); house.setAddress(address); IPerson person = new Person(); person.setHouse(house); // Print the person zip code System.out.println(person.getHouse().getAddress().getZipCode()); }} |
Код выше будет работать как положено; мы кодируем интерфейс, наш код хорошо отформатирован и хорошо отформатирован. Что мы можем сделать, чтобы «обновить» наш код?
Закон Деметры гласит, что класс может знать не более одного дружеского класса. ЧТО? Давайте сделаем небольшие шаги и проанализируем код выше; обратите внимание, что наш класс Main хочет напечатать Person ZipCode, но для этого класс Main познакомится еще с двумя классами. Если вы не заметили, там есть связь.
Чтобы распечатать ZipCode, наш класс Main проходит через класс Person, House и, наконец, Address. Что это плохое приближение? Представьте, что если Annalist решит удалить наш класс Address из системы, а класс House будет отвечать за сохранение ZipCode.
В нашей треске очень легко измениться; но представьте себе, если бы у нас была огромная система с напечатанным ZipCode для более чем 100 строк кода. Вам придется изменить 100 строк кода в вашей системе.
Закон Деметры пришел, чтобы помочь нам с такой ситуацией, с небольшими изменениями в наших классах Личности и Дома; мы можем избежать этого огромного влияния, удаляя класс Address. Взгляните на наш новый код.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
|
package com;public class Main { public static void main(String[] args) { IAddress address = new Address(); address.setName("01"); address.setZipCode("000001"); IHouse house = new House(); house.setAddress(address); IPerson person = new Person(); person.setHouse(house); // Print the person zip code System.out.println(person.getZipCode()); }} |
|
01
02
03
04
05
06
07
08
09
10
11
|
package com;public interface IPerson { void setHouse(IHouse house); IHouse getHouse(); String getZipCode();} |
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
|
package com;public class Person implements IPerson { private IHouse house; @Override public void setHouse(IHouse house) { this.house = house; } @Override public IHouse getHouse() { return house; } @Override public String getZipCode() { return house.getZipCode(); }} |
|
01
02
03
04
05
06
07
08
09
10
11
|
package com;public interface IHouse { void setAddress(IAddress address); IAddress getAddress(); String getZipCode();} |
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
|
package com;public class House implements IHouse { private IAddress address; @Override public void setAddress(IAddress address) { this.address = address; } @Override public IAddress getAddress() { return address; } @Override public String getZipCode() { return address.getZipCode(); }} |
|
01
02
03
04
05
06
07
08
09
10
11
12
13
|
package com;public interface IAddress { void setName(String string); void setZipCode(String string); String getZipCode(); public abstract String getName();} |
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
package com;public class Address implements IAddress { private String name; private String zipCode; @Override public void setName(String name) { this.name = name; } @Override public void setZipCode(String zipCode) { this.zipCode = zipCode; } @Override public String getName() { return name; } @Override public String getZipCode() { return zipCode; }} |
Посмотрите на наш новый код, подумайте, где вам нужно будет измениться, если вам нужно удалить класс Address. Будет изменен только класс Home, остальная часть нашего кода останется прежней.
Это величайшее преимущество закона Деметры. Когда вам придется проводить техническое обслуживание, ваш проект будет иметь небольшое влияние. Новые функции будут легко адаптированы, более простые редакции кода и с небольшой стоимостью. В коде, который мы видели сегодня, будет затронут только один класс. Другие классы вашей системы останутся прежними, и ваша система будет иметь небольшую связь.
Недостатком этого подхода является влияние на производительность системы. У вас может быть низкая производительность, если вы используете этот подход в циклах, таких как «Пока, для,…». В этом случае вам нужно будет увидеть, какой код вашей системы не повлияет на производительность в соответствии с законом Деметры.
Я считаю, что даже с учетом этого недостатка производительности в некоторых фрагментах кода этот подход полезен и стоит использовать его в наших системах; Закон Деметры может использоваться почти во всех кодах нашей системы.
Я надеюсь, что этот пост может помочь вам
Если у вас есть какие-либо сомнения или вопросы, просто напишите их.
До скорой встречи! \ o_
Ссылка: Demeter Law от нашего партнера JCG Хеберта Коэльо в блоге uaiHebert .