The sister began to complain

Business background

Sister’s game is a battle type of game, which has a player’s concept, players can attack, this business is the starting point for sister to scratch her head

First demand

Product Manager: Players have many attributes, such as height, gender blalalala, players can attack other players.

YY sister writing programs is also very quick, a day to finish the program, but also abstracted out a Palyer base class, can be called a senior programmer essential skills.

Abstract class Player {public string Name {get; set; } //. //. //. //. } class PersonPlayer: Player {public void Attack() {//to do something return; }}Copy the code

Secondary demand

Product Manager: IN the game, I need to increase the number of robot players to increase the number of online players. Robot properties are the same as real players, but the attacks are not quite the same

This requirement modification is still difficult to YY sister, a few days later the code changed, added a robot player class, using OO inheritance. Give the player abstract class a thumbs up here

Class RobotPlayer: Player {public override void Attack() {public override void Attack() {class RobotPlayer: Player {public override void Attack() { }}Copy the code

Third demand

Product Manager: I’m going to create a bunch of player-like monsters that don’t have the attributes of real players, but have the same aggressive behavior as real players

At this time YY girl finally realized that attack is a kind of behavior, need to abstract the interface.

// interface IAttack {void Attack(); } class PersonPlayer :Player, class PersonPlayer :Player, IAttack { public void Attack() { //to do something return; }} class RobotPlayer :Player, IAttack {public void Attack() {// to do something return; Class MonsterPlayer: IAttack {public void Attack() {// to do something return; }}Copy the code

This brings us to the familiar interface oriented programming, and yes, it’s the right thing to do. This is also a principle of design: programs depend on interfaces, not implementations. Here to continue to praise YY. And by the way, for the most part, a lot of you stopped there

Fourth demand

Product Manager: NOW I need to design the player’s attack mode, currently there are ranged attack, close range attack, close range attack three categories, other requirements blalalala.

It is said that at the moment YY girl’s heart is the state of 10,000 alpacas floating by. How do we design it this time? This is the main part of the story. Now we need to take a moment to think, why do we use interface oriented programming, meet this requirement, the program still need to change a lot of things?

Design principle: Identify areas of the application that may change in the future and isolate them without mixing them with code that doesn’t change.

Such concepts are simple and are the soul behind every design pattern. So far, the interface of Attack is constantly changing in the design, and the behavior of Attack should be more accurate. There is nothing wrong with the concept of interface oriented, but most people do not understand the meaning of interface at the language level and the design level. The real interface oriented programming is more oriented to the behavior of programming in the architecture. Another Angle can also be seen as using the principle of OO polymorphism.

Here, we can more systematically define the Attack behavior as a kind of behavior, and the specific behavior realization can be described as a cluster of algorithms. Think about it, Attack doesn’t just apply to player types. Someday the product manager will add a XX object with Attack behavior. Ideally, I just need to make this XX object have Attack behavior without changing any of the previous code. Are you now a little bit more comfortable with the definition of this behavior?

On the other hand, so far the code of YY girls has been implemented in the way of inheritance, what is the problem? If you want to change the Player’s Attack behavior dynamically while the application is running, it will be difficult to do so.

Here comes another design concept: in general, one is probably better than the other. ** The specific concept is: more combination, less inheritance. Inheritance usually applies to features of the thing itself, such as: the player base class has the name property, and the inheritance class can inherit this property without any problems. However, combination is mostly used in the design of behaviors. Because of this behavior type, I may appear in multiple things, and more elastic design can be achieved by combination.

Behavior oriented programming (10 lines are worth a thousand words. Net Core code)

Encapsulate behavior in a cluster
// interface IAttack {void Attack(); } class RemoteAttack: IAttack {public void Attack() {// RemoteAttack}} Public void Attack() {public void Attack()}Copy the code
Things contain combinations of actions
Class PersonPlayer: Player {// The Player can have the action of attack attack; public PersonPlayer(IAttack _attack) { attack = _attack; } public void Attack() {public void Attack() {public void Attack(); return; } public void ChangeAttack(IAttack _attack) {attack = _attack; }}Copy the code

Write in the last

Interface is a kind of specification and constraint, higher level abstraction is more like a kind of behavior, interface oriented programming is just a kind of format embodiment of the code layer, the real interface oriented design is closer to behavior oriented programming

More interesting articles

  • Distributed large concurrent series
  • Architectural Design Series
  • Series of interesting algorithms and data structures
  • Design Pattern series