Wanneer ouder- en kindmethoden botsen!  TL;DR: Vermijd het gebruik van privémethoden in bovenliggende klassen met namen die ook door onderliggende klassen gebruikt kunnen worden.  Problemen  De minst verrassende schending van het principe  Onverwacht gedrag en  defecten  Verborgen afhankelijkheden  Beperkte uitbreidbaarheid  Code dubbelzinnigheid  Schending van het open/gesloten principe   Misleidend ontwerp  Oplossingen  Vermijd  hiërarchieën  Privémethoden hernoemen  Zorg voor een duidelijke naamgeving  Vermijd overlappende namen  Vermijd  beschermde methoden  Subclassificeer voor   , niet om  essentiële relaties code te hergebruiken  Context  Wanneer u dezelfde methodenaam gebruikt in bovenliggende en onderliggende klassen, ontstaat er verwarring.  Een privémethode in de bovenliggende klasse kan niet worden overschreven, zelfs niet als er een openbare methode met dezelfde naam in de onderliggende klasse bestaat.  Dit is een probleem dat de meeste statische talen in hun ontwerp hebben. Deze ontkoppeling leidt tot bugs en maakt uw code moeilijk te onderhouden.  Voorbeeldcode  Fout   <? class ParentClass { private function greet() { // This method is private return "Hello from ParentClass"; } public function callGreet() { return $this->greet(); } } class ChildClass extends ParentClass { public function greet() { // Overriding a concrete method is a code smell // Compilers SHOULD warn you return "Hello from ChildClass"; } } $child = new ChildClass(); echo $child->callGreet(); // When callGreet() is invoked on the $child object, // it executes the following: // It calls $this->greet(), // which refers to the greet() method of ParentClass // because the original method is private // and cannot be overridden or accessed from ChildClass. // The unexpected output is 'Hello from ParentClass'  Rechts   <? class ParentClass { protected function greet() { // notice the 'protected qualifier' return "Hello from ParentClass"; } public function callGreet() { return $this->greet(); } } class ChildClass extends ParentClass { public function greet() { return "Hello from ChildClass"; } } $child = new ChildClass(); echo $child->callGreet(); // The output is "Hello from ChildClass" // This is the standard (and wrong) solution // Also fixed by most AIs   <? abstract class ParentClass { // Declare greet() as an abstract method // Following the template-method design pattern abstract protected function greet(); public function callGreet() { return $this->greet(); } } class ChildClass extends ParentClass { protected function greet() { return "Hello from ChildClass"; } } class OtherChild extends ParentClass { protected function greet() { return "Hello from OtherChild"; } } $child = new ChildClass(); echo $child->callGreet(); // Output: Hello from ChildClass $otherChild = new OtherChild(); echo $otherChild->callGreet(); // Output: Hello from OtherChild  Detectie    Semi-automatisch [x]  U kunt deze geur detecteren door te zoeken naar private methoden in bovenliggende klassen en te controleren of onderliggende klassen methoden met dezelfde naam definiëren. U moet ook bovenliggende methoden testen die private methoden aanroepen.  Labels  Hiërarchie  Niveau    Gemiddeld [x]  Waarom de bijectie belangrijk is  Duidelijke en voorspelbare code moet de hiërarchie uit de   weerspiegelen die het modelleert. echte wereld  Wanneer u privémethoden met overlappende namen gebruikt, ontstaat er een   tussen het model en de implementatie. bijectiekloof  Deze kloof verwart ontwikkelaars, vergroot het aantal defecten en schendt de principes van schone code.  AI-generatie  AI-generatoren creëren deze geur vaak wanneer ze standaard ouder-kindrelaties genereren.  Het kan zijn dat ze de toegangsniveaus niet controleren en geen rekening houden met de gevolgen van overerving.  AI-detectie  AI-hulpmiddelen kunnen deze geur verhelpen met duidelijke instructies.  U kunt de AI vragen om te controleren op overlappende methodenamen en refactoringhiërarchieën.   Probeer ze eens!  Onthoud: AI-assistenten maken veel fouten  Zonder de juiste instructies  Met specifieke instructies   ChatGPT   ChatGPT   Claude   Claude   Verwarring   Verwarring   Tweede piloot   Tweede piloot   Tweeling   Tweeling  Conclusie  Bij het ontwerpen van bovenliggende en onderliggende klassen moet u methoden gebruiken die overerving en toegankelijkheid duidelijk definiëren.  Vermijd private methoden die overlappen met child-methoden. Dit houdt uw code leesbaar, uitbreidbaar en afgestemd op clean code-principes.  Met talen als   kunt u bovenliggende methoden overschrijven, ongeacht hun naam, terwijl   strikte toegangslevels afdwingt. Python Java    gedraagt zich vergelijkbaar met   . Deze verschillen betekenen dat u de specifieke regels van de taal waarmee u werkt moet begrijpen om onverwacht gedrag te voorkomen. C# Java  Betrekkingen   https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxviii   https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xii   https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-iii-t7h3zkv   https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-xxv   https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-viii-8mn3352   Disclaimer: Code Smells zijn mijn   . mening   Credits: Foto door   op  Matt Artz Unsplash  Overerving is goed, maar je moet nooit vergeten dat het een nauwe koppeling met zich meebrengt.   Robert C. Martin   https://hackernoon.com/400-thought-provoking-software-engineering-quotes?embedable=true   Dit artikel is onderdeel van de CodeSmell-serie op HackerNoon.   https://hackernoon.com/how-to-find-the-stinky-parts-of-your-code-part-i-xqz3evd?embedable=true

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - REFACTORING.

Code Smell 286 - Overlappingen van ouder-kindmethode

About Author

OPMERKINGEN

LABELS

DIT ARTIKEL WERD GEPRESENTEERD IN

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps