protected visibility
in [OOP]
|
Prev: instanceof
Next: Hibernate Vs. SQL
From: Gabriel Claramunt on 6 Apr 2007 21:08 I'm refactoring an old code Java code and I found many protected attributes and methods. My first reaction was to avoid protected (something like "protected visibility cosnidered harmful"), but I couldn't think of a particular reason to do it. Having a protected attirbute feels like having a public attribute for the sublcasses with the known side effects, but protected methods? Should be avoided?
From: Phlip on 6 Apr 2007 23:46 Gabriel Claramunt wrote: > I'm refactoring an old code Java code and I found many protected > attributes and methods. > My first reaction was to avoid protected (something like "protected > visibility cosnidered harmful"), but I couldn't think of a particular > reason to do it. > Having a protected attirbute feels like having a public attribute for the > sublcasses with the known side effects, but protected methods? Should be > avoided? How are your unit tests? They are typically more important for encapsulation than minor details like variable access. Next, are you refactoring in the direction of delegation? Some "OO" code abuses inheritance where delegation would work simpler. And derived objects would have less excuses to "borrow" their base classes' private variables... -- Phlip http://flea.sourceforge.net/PiglegToo_1.html
From: Daniel T. on 7 Apr 2007 07:52 "Gabriel Claramunt" <gabclar(a)internet.com.uy> wrote: > I'm refactoring an old code Java code and I found many protected > attributes and methods. My first reaction was to avoid protected > (something like "protected visibility cosnidered harmful"), but I > couldn't think of a particular reason to do it. Having a protected > attirbute feels like having a public attribute for the sublcasses > with the known side effects, but protected methods? Should be > avoided? Every argument against making certain things public also applies to making them protected. If the method can safely be made protected, then it can also safely be made public.
From: H. S. Lahman on 7 Apr 2007 10:10 Responding to Claramunt... > I'm refactoring an old code Java code and I found many protected attributes > and methods. > My first reaction was to avoid protected (something like "protected > visibility cosnidered harmful"), but I couldn't think of a particular reason > to do it. > Having a protected attirbute feels like having a public attribute for the > sublcasses with the known side effects, but protected methods? Should be > avoided? I don't think 'protected' is inherently harmful as far as maintainability is concerned. In my view it is an example of providing a feature for a very specialized context that is so general that it can be used in contexts where its use was never intended. The notion of 'protected' is very useful in a testing context because the test harness can have access to private state variables. But a test harness lies outside the application flow of control and is not even part of the solution to the customer's problem. In addition, the test harness has a right to look at all state variables. The question to ask is: what does 'protected' facilitate /within/ the problem solution context? The answer is basically nothing. 'Protected' simply allows access to inherently private properties of an object for "special" clients. Public properties of an object define its roles in the problem solution so, barring explicit business requirements to the contrary, they should be accessible wherever they are needed in the solution. Private properties of an object are elements of its implementation and should always be hidden in the solution. IOW, it is in the nature of object definition that a property is either public or private, not sometimes private. In a given problem space there may be business rules and policies (i.e., functional requirements) that limit which objects can access certain public responsibilities that define an object. If so, those rules and policies should be an explicit part of the design (e.g., infrastructure for user privileges, feature licensing, etc.) at the OOA/D level rather than hidden as a language-dependent trick applied during OOP. So the real problem with 'protected' is that the design isn't portable. For example, if one captures the design in a formal OOA/D model prior to coding, that model should contain an explicit resolution of the business rules and policies that limit access. (Well-formed OOA/D models can be executed against the same functional requirements as the executable, albeit tediously in an elaboration environment.) That design resolution needs to be portable across 3GL environments. [I know, 'protected' is in UML. But it does not appear in any of the MDA profiles used for OOA modeling where functional requirements are resolved because those models must be platform independent. IMO, it doesn't even belong in OOD because it over specifies the OOP implementation and can only be implemented as-is in a few OOPLs. It is a carry-over from the Booch notation that was essentially Graphical C++.] ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: Gabriel Claramunt on 7 Apr 2007 19:03
"Unit tests? We don't need no stinkin' unit tests!" :-D Basically, there's no unit tests, and as we are changing the structure/interfaces also, writing unit tests for the old classes seems to have a low ROI. And yes, after I cleaned a lot of code, I was able to change inheritance to delegation (specially because it made more sense for the domain) |