4 ms·

How to model a door. class Door { void open() {...} void close() {...} } door.open(). But can a door open itself? Maybe Man pety

How to model a door. class Door { void open() {...} void close() {...} } door.open(). But can a door open itself? Maybe Man petya = ... petya.open(door); But can a door be opened if it's not installed? So walls should also come into play when we think about door and its methods. It's difficult to model the world with OOP (at least in its current state).

brabel 9y ago
A `Door` is not an agent, so no, it can't open itself (unless it's a game and your doors have agency). When you say a door can be opened, you are making the assumption that the door is installed in some sort of building. But then, the door is a component of that building, not just a stand-alone door. It can only be opened in that context. So I would suggest something like this: class Door(Material, Size) class Room(List<RoomConnection>, Size) enum DoorState { Closed, Open, Locked } class RoomConnection(Room, Room, Optional<(Door, DoorState)>, Size) To open the door, you don't need a method in any of these "data" classes, you just need to update the door state given there's a door in a room connection you're interested in. The room connection may or may not have a door, and that could change over time. If it does have a door, then the door must have a state (but not all doors have a state, only the ones that are in a Room Connection, possibly others). Notice that to update the room connection, you don't need mutable state locally... you just need a way to provide a new RoomConnection to code where opening a door may be possible (normally, you're given a RoomConnection as an input, and you might give a new one, basic FP style but OOP can also operate in that way). So, I don't think it's that hard if you know what you're doing. I don't want to even comment on the suggestion to have a `Man.open(Door)` method :) that's really not good.
- avodonosov 9y ago
  You still follow the naive OOP thinking and it remains ridiculous. For example, why Room?

brabel 9y ago

A `Door` is not an agent, so no, it can't open itself (unless it's a game and your doors have agency). When you say a door can be opened, you are making the assumption that the door is installed in some sort of building. But then, the door is a component of that building, not just a stand-alone door. It can only be opened in that context. So I would suggest something like this: class Door(Material, Size) class Room(List<RoomConnection>, Size) enum DoorState { Closed, Open, Locked } class RoomConnection(Room, Room, Optional<(Door, DoorState)>, Size) To open the door, you don't need a method in any of these "data" classes, you just need to update the door state given there's a door in a room connection you're interested in. The room connection may or may not have a door, and that could change over time. If it does have a door, then the door must have a state (but not all doors have a state, only the ones that are in a Room Connection, possibly others). Notice that to update the room connection, you don't need mutable state locally... you just need a way to provide a new RoomConnection to code where opening a door may be possible (normally, you're given a RoomConnection as an input, and you might give a new one, basic FP style but OOP can also operate in that way). So, I don't think it's that hard if you know what you're doing. I don't want to even comment on the suggestion to have a `Man.open(Door)` method :) that's really not good.

avodonosov 9y ago
You still follow the naive OOP thinking and it remains ridiculous. For example, why Room?