Timeline for Is encapsulation still one of the elephants OOP stands on?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 21, 2017 at 16:57 | comment | added | Rogério | There is a great article by Martin Fowler which (IMO) debunks this idea that real objects should not have getters. | |
| Oct 21, 2017 at 16:54 | comment | added | Rogério | Some things in this answer are perfectly fine, but that Document example is just awful. For one, in real-world application development, code that would display a document's title would usually not get written in a programming language, but in some template language (Java's JSP or JSF facelet, ASP.NET page, Jasper Reports XML, etc.). But even in, say, a Swing/JavaFX client, it would be perfectly fine and a lot more natural to just expose the getter to be called from some UI component's event handler. Also, think about PrintableDocument: where would the document title come from? | |
| Oct 13, 2017 at 12:50 | comment | added | T. Sar | Furthermore, you're not only breaking Single Responsibility the moment you add new responsibility to an object (printing itself), but you also removed the ability for it to be mocked out by subclassing it, so you won't be able to test it as easily, you removed the flexibility of someone to chose what printer to use, thus making the code more coupled and less extensible... really - your example would be way, way better if it was backwards. The one using the getter is way better than the one using inheritance. | |
| Oct 13, 2017 at 12:42 | comment | added | T. Sar | The bottom line: Getters and Setters aren't evil or breaking OOP - People that don't understand how to use them are. You example case is a textbook example of people missing the whole point how DI works. The example you "corrected" was already DI-enabled, decoupled, could be mocked easily... Really - remember the whole "Prefer Composition over Inheritance" thing? One of the OO pillars? You just threw it by the window by the way you refactored the code. This wouldn't fly in any serious code review. | |
| Oct 13, 2017 at 12:41 | comment | added | T. Sar | A proper OO approach to this, if we were going to a "Pure OO" approach, would use something that implements an abstract PrinterService class requesting, via a message, what the hell should be printed - using a GetPrintablePart of sorts. The thing that implements the PrinterService could be any sort of printer - print to a PDF, to the screen, to the TXT... Your solution makes it impossible to swap out the printing logic for something else, ending up more coupled and less maintanable than your "wrong" example. | |
| Oct 13, 2017 at 12:36 | comment | added | T. Sar | Eh, still not convinced. Your example is okay but just denote a different style of coding, not the "true right one" - which doesn't exist. Keep in mind most languages are multiparadigm nowadays and rarely are pure OO ou pure procedural. Sticking yourself so hard to "pure OO concepts". As an example - you can't use DI on your example because you coupled the printing logic to a subclass. Printing shouldn't be part of a document - a printableDocument would expose its printable part (via a getter) to a PrinterService. | |
| Oct 11, 2017 at 0:39 | comment | added | Kat | "Getters/setters as bad as plain public fields" -- that's not true, at least in many languages. You typically cannot override plain field access, but can override getters/setters. That gives versatility to child classes. It also makes it easy to change the behavior of classes. eg, you might start with a getter/setter backed by a private field and later move to a different field or calculating the value from other values. Neither can be done with plain fields. Some languages do allow fields to have what's essentially automatic getters and setters, but Java is not such a language. | |
| S Oct 10, 2017 at 18:24 | history | mod moved comments to chat | |||
| S Oct 10, 2017 at 18:24 | comment | added | maple_shaft♦ | Comments are not for extended discussion; this conversation has been moved to chat. | |
| S Oct 9, 2017 at 13:13 | history | suggested | Pierre Arlaud | CC BY-SA 3.0 | Grammar fix |
| Oct 9, 2017 at 8:07 | review | Suggested edits | |||
| S Oct 9, 2017 at 13:13 | |||||
| Oct 6, 2017 at 5:09 | history | edited | Izbassar Tolegen | CC BY-SA 3.0 | added additional details. |
| Oct 5, 2017 at 12:35 | history | migrated | from stackoverflow.com (revisions) | ||
| Oct 5, 2017 at 11:56 | history | answered | Izbassar Tolegen | CC BY-SA 3.0 |