0

This is the scenario in which I have to apply some creational pattern.

Build a fleet of 10 cars with the following features. Five cars should have all the features and five should be built without the lidar and ultrasonic sensors:

  1. Radar sensors dotted around the car monitor the position of vehicles nearby.
  2. Video cameras detect traffic lights, read road signs and keep track of other vehicles, while also looking out for pedestrians and other obstacles.
  3. Lidar sensors help to detect the edges of roads and identify lane markings by bouncing pulses of light off the car’s surroundings.
  4. Ultrasonic sensors in the wheels can detect the position of curbs and other vehicles when parking.
  5. Finally, a central computer analyses all of the data from the various sensors to manipulate the steering, acceleration and braking.

My initial guess is that it should follow abstract factory method. Following is the initial design but I am not sure whether this is correct or not.

Car factory interface
carCreatefactory implements Car factory
Products:
Sensors
Radar sensor implements Sensors
Lidar Sensor implements Sensors
Ultrasonic sensor implements Sensor

Camera
Video Camera implements Camera

Computer
Central Computer implements Computer

Client:
Fleet

I am confused about the central computer since it doesn't really seem to fit. Secondly, in this design a car can have only one sensor and not all. Would this pattern fit by changing some logic? Or a different patter should be used?

Christophe
  • 74,672
  • 10
  • 115
  • 187
user3102085
  • 113
  • 1
  • 1
    If I want to learn how to build a car, I would ask a car manufacturer, not a software engineer. – Doc Brown Nov 18 '17 at 09:41
  • 1
    ... so I guess what you are really after is an OO model for cars with these parts? Start with designing a car class before asking about creational patterns. – Doc Brown Nov 18 '17 at 14:50
  • Possible duplicate of [Choosing the right Design Pattern](https://softwareengineering.stackexchange.com/questions/227868/choosing-the-right-design-pattern) – Doc Brown Nov 21 '17 at 10:48

1 Answers1

2

Candidate creational patterns

Build a fleet of 10 cars with the following features. Five cars should have all the features and five should be built without the lidar and ultrasonic sensors

Singleton is of course excluded.

Prototype is not really a candidate, because it would require that you have already 1 car with all the features and one car without the radar, in order to clone them.

Factory method could be considered, if the car creation interface is always the same. But can it really be with all these features ? And what if I have a new car model with some more features ?

Abstract factory could be a candidate. Car models could be different families of abstract products. Car with and without radar could be different products, or could be the same product created with different parameters in the constructor.

Builder could be a candidate. A car would be a complex objet with a construction process that could be abstracted from the concrete car representation.

And the winner is... ?

Let's read again and take care of the details:

Build a fleet of 10 cars with the following features. Five cars should have all the features and five should be built without the lidar and ultrasonic sensors.

Would this be all, I'd have opted for the abstract factory as you, each feature being a boolean parameter in the factory call.

But your text gives you the detail of the features and their dependency:

  1. Radar sensors ... around the car ...
  2. Video cameras ...
  3. Lidar sensors ... pulses of light ...
  4. Ultrasonic sensors in the wheels ...
  5. ... a central computer ... data from the various sensors ... manipulate the steering, acceleration and braking.

This suggest that you have to make sure that the parts in your Car know each other according to these requirements. Eg the computer object of a specific car object knows each of the sensor objects of that car so that it can send them queries.

Taking this into consideration, it appears that the winner is the builder pattern. It's the only pattern designed to cope with a complex construction process and assembly of parts.

Community
  • 1
Christophe
  • 74,672
  • 10
  • 115
  • 187
  • Answer is fine, but think you excluded Prototype a bit too glibly. Depending where you are in the process, you never have a prototype of anything, right? OP could create either an "everything" car or "basic minimal car" and work from there. – user949300 Nov 18 '17 at 21:53
  • 1
    @user949300 fair point. But I think that if you'd use a prototype for the car you'd need a prototype for its components as well. The issue will then be for the relation between the computer and the sensors: if you clone the components separately, the cloned sensors will not know the cloned computer and vice versa. – Christophe Nov 18 '17 at 21:59
  • This answer is a perfect example of how **not** to apply patterns. – Doc Brown Nov 21 '17 at 06:57
  • @DocBrown Now enlighten us on how to apply them, in a separate answer. I'm always curious to learn more... – Christophe Nov 21 '17 at 07:51
  • @Christophe: I think it is a bad idea to apply any pattern here at all, especially in absence of a car class. See, for example, https://softwareengineering.stackexchange.com/questions/257885/when-writing-object-oriented-code-should-i-always-be-following-a-design-pattern/262993#262993 – Doc Brown Nov 21 '17 at 10:21
  • ... or here: [Choosing the right Design Pattern](https://softwareengineering.stackexchange.com/questions/227868/choosing-the-right-design-pattern) Here, the OP (and your answer as well) try exactly what the top answer for that other question warns against: to throw some arbitrary patterns at a problem, without writing enough code to see if there is any need for using a standard design pattern. – Doc Brown Nov 21 '17 at 10:48
  • @DocBrown sorry, but both answers are completely unrelated to this question. IMHO You don't need a class to find the right pattern. You need to know the requirements and the intents (which are all known here). and then, if there's an appropriate **design** pattern (here there is), you can continue your design and benefit from a more maintainable code than reinventing the wheel by yourself. Here the builder allows to abstract the building process of a car and its interrelated components, from any specific car or component class. That's the joy of design ;-) – Christophe Nov 21 '17 at 13:43
  • @Christophe: I agree that one can do this from an academic point of view, for learning purposes. However, this is exactly the way to overengineering in real world programming, and the top answer of the second answer warns explicitly against this route, that this is not a way to working, maintainable software. So it is IMHO very much related to this question (and your answer). – Doc Brown Nov 21 '17 at 16:01