Timeline for Can we really use immutability in OOP without losing all key OOP features?
Current License: CC BY-SA 3.0
31 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 26, 2017 at 20:12 | comment | added | lishaak | @TheCatWhisperer Do you have a link to some article or webpage which shares this viewpoint? | |
| Jun 26, 2017 at 14:19 | comment | added | TheCatWhisperer | Good OOP should look much more "functional" than you imagine anyway. Everyone's perspective of OOP has been warped by C++, Java, and C#'s procedural heritage. | |
| Jun 9, 2017 at 5:46 | history | tweeted | twitter.com/StackSoftEng/status/873053775782494209 | ||
| Jun 4, 2017 at 19:04 | comment | added | lishaak |
@DocBrown You say that my chess is a poor design. I am intersted in how would you design the board and pieces to stay immutable and also by able to generate moves. How would your MoveGenerator work without checking the runtime type of the piece? Or would you just abandon a piece class hierarchy and make pieces only instances of one class called just Piece?
|
|
| Jun 3, 2017 at 10:20 | comment | added | Doc Brown | ... in that example, the pieces (modeled as an inheritance hierarchy) only provide the basic rule validation methods based on their position and type, but do not provide any move generation logic using information about other pieces or the board or former moves (which is necessary to implement the chess rules in full). I am sure it is pretty simple in that model to convert the "piece" class to an immutable object, but I miss to see how that changes the general structure of the OO model at all. | |
| Jun 3, 2017 at 10:10 | comment | added | Doc Brown | great opposition to your ideas? Don't think so , but IMHO a contrived example of a badly modeled chess board is not a good way to "prove" your thoughts about immutability. The correct place for such a discussion would is chat, but today I lack the time to go into such a discussion. What a "good" model of a chess board is, is surely very opinionated, but you find already some good examples on the web like this one ... | |
| Jun 2, 2017 at 22:38 | comment | added | Jörg W Mittag | @Euphoric: Idiomatic Scala is OO and functional. There are corners where people opt for a more Abstract Data Type oriented style over objects, and there are corners where the occasional side-effect is accepted, but by and large, they go well together. Some features that are often thought to be incompatible with OO actually work quite well. E.g. Pattern Matching can be made compatible with Encapsulation by moving the responsibility for being matched on into the match target (or a separate extractor object, which, being separate has no access to private implementation details). | |
| Jun 2, 2017 at 19:08 | comment | added | Euphoric | I wonder if any people saying OOP and immutability can go together ever tried using complete immutability in modern OOP language. I just can't imagine it. | |
| Jun 2, 2017 at 17:56 | answer | added | 9000 | timeline score: 2 | |
| Jun 2, 2017 at 16:48 | comment | added | lishaak | @DocBrown I feel you provide a great opposition to my ideas and I have many comments. They will divert this discussion from the main topic, though. I feel excited to somehow somewhere setup an elaborate discussion on the design of this simple chess example so it is as clean and educational as possible. However, I am not sure where to setup such a discussion and if more people will be interested. | |
| Jun 2, 2017 at 16:21 | history | edited | user22815 | CC BY-SA 3.0 |
Removed extraneous text.
|
| Jun 2, 2017 at 15:52 | comment | added | Doc Brown | @lishaak: this has nothing to do with immutability. The example is too simple to show any benefits of inheritance (though I guess a piece, immutable or not, is still a candidate for an inheritance hierarchy). A piece object will definitely have some methods as well as the chess board, but only methods which do not make them violate the SRP. However, immutability would not be my first choice for the chessboard itself using OO modeling (though I can imagine this as a possible design alternative). | |
| Jun 2, 2017 at 15:35 | answer | added | candied_orange | timeline score: 28 | |
| Jun 2, 2017 at 15:05 | comment | added | lishaak |
@DocBrown I like your idea. On the other hand, it proves my original point. In your design, the board and pieces are just data and MoveGenerator is just a polymorphic function which generates moves according the the type of pieces. No objects needed, no inheritance, no methods, no encapsulation and other OOP stuff, just functions transforming data. You may very well object that it happened just in this case. Thus, my question is, isn't this always the case when you take immutability and good design rules to their maximum? Won't you eventually always end with with purely functional design?
|
|
| Jun 2, 2017 at 14:35 | comment | added | Doc Brown | ... Note this is mostly independent from your question, and if your chessboard is immutable or not. To your question when to use immutability or not, I wrote my "rules of thumb" down here in this former answer to a different question. | |
| Jun 2, 2017 at 14:33 | comment | added | Doc Brown |
@lishaak: I don't see a compelling reason why a piece should know more than its position and its type. The rules of the game and which moves are valid and which are not can be modeled outside the pieces and the board, which will I guess result in a better design. In the real world, it is not the piece or the board which follows the rules, instead the players follow (or don't follow) the rules. So I find it much more natural to have a separate object like a ChessEngine or a MoveGenerator for controlling or generating the valid moves.
|
|
| Jun 2, 2017 at 14:25 | comment | added | Walfrat | Questions : does you object are always immutable, or do you allow and initialisation phase where you can "configure them" adding observer, adding listener ? And : what kind of application are we talking about ? I mean, if you do a snake, you will have some trouble with everything immutable. For a stateless (no user session) crud application, that could make sense. | |
| Jun 2, 2017 at 14:24 | comment | added | lishaak | @DocBrown Interesting! The design I proposed seems most logical not only to me but also to my collegeus. How would you implement board and pieces in a better OO way? | |
| Jun 2, 2017 at 13:26 | history | edited | lishaak | CC BY-SA 3.0 |
added 475 characters in body
|
| Jun 2, 2017 at 13:23 | comment | added | Timothy Truckle | OOP is more than inheritance. Also: we usually deal with two kinds of classes: DTOs/ValueObjects which should be immutable by any chance, and business objects which hold business logic working on the DTOs. These BusinessObjects do not need to be immutable but all of the OOP principls apply to them... | |
| Jun 2, 2017 at 11:52 | comment | added | Mason Wheeler | @lishaak You "struggle to explain the problem with inheritance in simple terms" because it's not a problem; poor design is a problem. Inheritance is the very essence of OOP, the sine qua non if you will. A lot of the so-called "problems with inheritance" are actually problems with languages not having an explicit override syntax, and they're a lot less problematic in better-designed languages. Without virtual methods and polymorphism, you don't have OOP; you have procedural programming with funny object syntax. So it's no wonder you're not seeing the benefits of OO if you're avoiding it! | |
| Jun 2, 2017 at 11:35 | comment | added | Doc Brown | "From the OOP point of view, a piece is responsible for generating valid moves from its position on the board." - definitely not, designing a piece like that would most probably hurt SRP. | |
| Jun 2, 2017 at 11:15 | review | Close votes | |||
| Jun 9, 2017 at 3:06 | |||||
| Jun 2, 2017 at 11:00 | comment | added | lishaak | Yes, many times it is convenient for an immutable object to have a method (the board may return the number of white piece for example) but many times the method would be better off just as a polymorphic function (if you want to save the board to a file, you do not want the function part of the object since there might be many possible ways to save a board as XML or JSON etc) | |
| Jun 2, 2017 at 10:56 | comment | added | gnat | Possible duplicate of Complete immutability and Object Oriented Programming | |
| Jun 2, 2017 at 10:55 | comment | added | lishaak | @MartinBa I struggle to explain the problem with inheritance in simple terms. Sometime inheritance is beneficial but many times it is not which many OOP gurus say anyway even without regards for immutability. So let's say that using inheritance as little as possible is just a good OOP design. | |
| Jun 2, 2017 at 10:49 | history | edited | lishaak | CC BY-SA 3.0 |
added 1150 characters in body
|
| Jun 2, 2017 at 10:27 | comment | added | Stop harming Monica | Your objects don't have methods? | |
| Jun 2, 2017 at 10:15 | comment | added | Martin Ba | I like the base question, but I have a hard time with the details. E.g. why does inheritance stop to make sense when you max out immutability? | |
| Jun 2, 2017 at 10:13 | history | edited | Martin Ba | CC BY-SA 3.0 |
typos
|
| Jun 2, 2017 at 10:08 | history | asked | lishaak | CC BY-SA 3.0 |