当前位置:网站首页>The responsibility and responsibility of the object

The responsibility and responsibility of the object

2021-05-04 15:47:29 Jiedao jdon

The main difference between objects and data is that objects have behavior , Behavior can be seen as responsibility (responsibilities Hereinafter referred to as responsibilities ) A kind of , Understanding responsibility is the key to achieving good OO The key to design .“Understanding responsibilities is key to good object-oriented design”—Martin Fowler .

Object design : role 、 Responsibility and collaboration "(Object Design: Roles, Responsibilities, and Collaborations) The book gives a complete description of the object's responsibilities .

Objects used to be seen as manipulated data , That's why the pattern of blood loss anemia , It's another way to look at objects as data structures or collections , The object is autonomous , Object is a robot like concept .

The revolutionary influence of duty

stay DDD Domain driven design , Usually, many people mistakenly map real entities to domain entities in software , This is a fallacy , In reality, entities are not one-on-one reflected in software , This involves an abstract process . We have to understand : In the software field, an entity object can usually play multiple real entity roles .

In the software field, objects can play different roles according to different scenarios , The method of object can be seen as the representation of different responsibilities of these roles , Make a comparison : You are a father at home , In the unit is a leader , If we set up two entities, fathers and leaders are not appropriate , Without abstract analysis , In fact, there is only one domain model entity , Namely “ you ”, Just in different scenes , You play different roles , Different roles are reflected in different rights, responsibilities and behaviors of roles , The responsibilities of a father are different from those of a leader .

The same domain object plays different roles through different methods, which brings a problem in implementation , And that gives rise to a kind of DCI framework , When we model , It's impossible to cram all of its role behaviors into entity objects , Instead, responsibilities should be dynamically assigned according to different scenarios , therefore , Tradition OO Language is like Java .NET And so on , Yes, of course AOP Of MIXIN In a disguised way to achieve , But not very elegant ,Qi4J The so-called combination oriented concept is actually like this , and Jdonframework From EDA In the aspect of event driven, it is tactful to drive the response of different responsibilities through event messages , The latest functional oriented languages such as Scala This aspect is elegant and direct .

The concept of responsibility gives OO The world has brought about great revolutionary changes , So we have to look at requirements from the perspective of responsibility driven ,DDD When analyzing the case of freight transportation in the book , And not from the perspective of duty , For example, it creates a special record object for transportation history , If you look at the concept of responsibility , The object of transport should know its own history , It's its job , therefore , Transportation history acquisition should be a method of transportation entity object , Instead of creating objects for them alone .

DDD Many aspects of a book still have the shadow of data extraction , This is due to its historical limitations , In order to get rid of the shadow of pure data object in blood loss mode , The responsibility of the target has risen to an unprecedented level .

How to discover responsibilities

If we change the traditional concept of regarding objects as dead and still entities , Think of solid objects as living , It's easy for you to find out their behavior and responsibilities , The object of the real world may be to do something or represent some information or things , But real people don't make decisions . Objects in software are alive , Be able to make decisions based on the responsibilities assigned to them , It's like an intelligent robot .

Responsibility comes from how your software works . From software HOW. It takes inspiration to find and assign responsibilities , It's a creative activity , It's a fun activity full of exploration, adventure and novelty , Look for responsibilities in requirements from the following aspects :

1. Message sending from sequence diagram in use case analysis .

2. structure invention、 Constraint expression 、 Strategy 、 Algorithm 、 specifications Specification And description Description Can be a duty .

3. What the system wants to do or manage

4. Think of a physical object as an actor ( Personification ), What should a character know knows something、 Will do those things do sth., Be able to control or decide what .

concise , The main thing to judge responsibility is : Does it know know These things , Does it make these things , Or make some judgments and decisions .

Assignment of duties

Assign responsibilities to objects , Make the object visible .

Distribute according to the principle of high cohesion .

Use “ Without this responsibility , What will happen ”.

If you find that the responsibilities are too broad , Cannot be assigned to a single object , Then divide the responsibilities , These small responsibilities combine into larger responsibilities .

The principle of cohesion : and DDD The concept of high aggregation in is similar to , Focus on the inside of the class ; Whether or not a class fully achieves its goal of responsibility ? Whether the methods in the class are all for the implementation of this responsibility ? High aggregation represents robustness Reusability and comprehensibility .

summary

Once domain objects have rich behaviors , Become a rich model , Or hyperemia model , It's actually a Actor,Actor You can communicate with each other through collaborative messages , and Scala Different from multithreading mechanism Actor The underlying implementation of the model better supports such a rich model , That's why Scala One of the reasons why it started to be very popular .

Use responsibility to analyze requirements , Build rich objects , Similar to the personification in literature , Design imagination should be given to the objective things that are still and can't speak in reality , Of course , Can't live , It's just right , The biggest problem right now is that it's not enough .

[ The quilt banq On 2010-02-03 10:58 A modified ]

版权声明
本文为[Jiedao jdon]所创,转载请带上原文链接,感谢
https://chowdera.com/2021/05/20210504154434506b.html

随机推荐